No Denying New Switch Vulnerability

Computerworld - Vendors of IT security products frequently release information about vulnerabilities associated with their software and hardware. I receive 15 to 20 such advisories every day and have to examine each one to determine whether it's applicable to our infrastructure. If the advisory pertains to a product we use, I must figure out whether it affects us.
That's not always easy. Before making a decision, I need to know if there have been any reported compromises and if the exploit code actually works.
I also review who released the advisory, the potential effect on my company and what resources I'll need to mitigate the vulnerability. Getting that information requires additional research, but as my recent experience shows, that can be time well spent.
Recently, someone released code that exploits a remote denial-of-service vulnerability in any network device from Cisco Systems Inc. that runs Versions 11.x or 12.x of the vendor's Internetworking Operating System (IOS) (see story).
Researching the Flaw
Since there was a significant amount of information both from Cisco and on message boards, and the advisory pertained to versions of IOS that we run, I needed to do some research about the potential of this vulnerability.
Reconfiguring or upgrading routers to cope with the problem isn't easy, so I decided to find out more about the risks we faced and ways we could protect ourselves without causing too much disruption to our operations.
Just as I started investigating the advisory, a colleague sent me two e-mails that included code exploiting the Cisco IOS weakness. Rather than relying on third-party opinions, I decided to use this code to test the vulnerability myself.
To exploit this vulnerability, the program must send a series of specially formatted IP packets with specific protocol types to the interface of a vulnerable router.
When executed properly, the transmitted packets can cause the router to flag the input queue as full. When this happens, the input queue refuses any more packets, causing the denial-of-service condition.
Network administrators must then reboot the router to reset the device and clear the problem. If the router isn't accessible from the network, someone must go to the data center and manually reboot the device -- which isn't much fun at 3 a.m.
The code I received by e-mail wasn't compiled. I transferred it from my desktop to a Linux workstation I have in the lab and reviewed it for other malicious content.
Once I had it compiled, I needed to find a router to run tests on. I talked one of