December 2008 Archives

Many folks are likely practicing for certifications and have trouble being able to get thier hands ahold of real equipment to praactice on.  GNS3 is a great tool for basic emulation of routers, switches (with some tricks) and firewalls!

Most folks want to emulate an ASA, which I am not currently aware of any product thaat will do this, but for the moment, the PIX code is virtually identical!  The primry differences what most people will notice (from an emulation perspective anyway) is that the interfaces have slight differences (Ethernet0-5 vs. Ethernet0/0-3 & Management0/0) and the SSM modules are not present and the IPS and Content inspection commands for the service policies won't exist.

But what aabout licensing?  This is where the real trouble happens, your emulated PIX by default won't have an activation key or serial number.  Ooops!  This means no VPN, not even DES!  No failover either!  Therefore you can't test any config that requires these features.  What you need to do is to locate a valid PIX somewhere.  In my case, I have a PIX 515E at work in our lab. 

I pulled a show ver from that PIX and made note of the Serial Number and Activation Key.  Once I had these, I go into GNS3 and right click on my PIX (from the network topology window) and select configure.  Obviously you need to select your PIX code file here, but you can also paste in the activation key.  You will get an error if you just paste it in though.  You must change the spaces in the activation key into commas ",".  The serial number field requires the information to be entered in hex.  So open your handy calculator and enter the decimal serial number from the real unit or from the show ver and convert it to hex.  You can then past this number into the field in GNS3 with a "0x" in front of it.  Depending on the code you choose, the activation key may or may not work at this point.  If it doesn't simply enter config mode on your virtual PIX and enter the activation-key command.  after a save and reboot the PIX should accept the key and work with the same license as the real one.

Just as an important note: This is NOT intended as a way to bypass Cisco's licensing.  You should not even think about using a GNS3/PEMU emulated firewall for production security purposes.  If you have a production need, eBay a PIX or better yet, buy a shiney new ASA 5505.  Only use this information in a lab.  Also, don't even think about asking me for activation keys or serial numbers. 

As a followup to my previous entry with the same subject (Part 1), We have discovered more information.  It turns out that the router alert packets weren't the cause of the high utilization, but instead mearly a piece of the larger puzzle.

The CPU utilization issue became so unbearable that something had to be done, and unfortunately, modifying all Macintosh systems on the network to stop using mDNS wasn't an option.  A few of the systems were changed with no noticable impact, but that could be because the number of systems changed constituted less than 1% of the systems at that campus.  Instead something else would have to be tried... Somthing on the network...

Being confident that the previous troubleshooting was accurate, and with assurances that nothing production other than GhostCast was using multicast, multicast routing was turned off on the switch.  This was a bold and rather drastic move, but it should solve the problem, right?  Wrong.  The number of packets hitting the CPU with the router alert option set remained constant, and CPU usage continued to behave as it had before.  If I had thought thiss through a bit more, I would have realized that traffic to the 224.0.0.x/24 multicast address range are meant to stay local, therefore the traffic would continue. 

The next step was to create an access list that blocks the mDNS group address destination address.  After that is created, it is added as a Port ACL on each client facing switch port.  Suddenly, we now have a real change in status.  CPU Usage dropped from 100% to 21% as soon as the interface range command was completed.

The big question here is why did this work, and what caused the switches poor performance?  The 4500 is capable of handling much higher volumes of multicast traffic, and it has distributed hardware processing of multicast.  It turns out that the 224.0.0.0/24 range is reserved for L2 local multicast, such as routing protocols, All routers, All hosts, etc.  Because of this fact, the 4500 was designed to send all multicast traffic destined to any address in this range directly to the CPU weather it was needed/subscribed, or not.  I think an inbound 224.0.0.0/24 multicast filter should be considered a basic security requirement for every network in order to prevent inadvertant or intentional DoS against the switched infrastructure regardless of weather multicast is officially in use on the network!