Nachi-A worm consumed all of router's memory?
Unknown
customers.
They had a PC infected with the Nachi-A worm that was mass ICMP
flooding to the 10.0.0.0/8 network. It was also (to a lesser degree)
flooding to Ports 80 and 135. The PC was hanging off of ethernet0/0
on a 26xx router. The 10.0.0.0/8 network had two equal cost paths
going out and the router was load balancing across the paths. The
router was running Fast Switching. Also, the bandwidth on both
outbound links was totally saturated and the router was dropping
outbond packets. This was causing the ISDN back up to periodically
come up.
The router, and the router's upstream neighbor (a 7200) had been
suffering for a week or so from memory allocation errors and at least
one spontaneous reload. This was very puzzling since other sites were
running virtually identical configurations.
Then I found this wonderful newsgroup message:
************************************
>Subject: Regarding Case Number V44290
>
>Hello xxxxx, I've done some testing here with Nmap. I was able to create a
>test bed that can cause problems & symptoms similar to those you reported.
>But in summary, the router is functioning normally & depending on the
>network topology the behavior you experienced would be expected.
>
> >From show processor memory, the ip input process is the process that
>maintains the ip fast switching cache. This fast switching cache is used
>when forwarding packets to avoid interrupting the cpu for repetitive route
>table lookups. The key issue is the behavior of the fast cache and the way
>it gets built.
>
>There are a number of scenarios that will cause the fast cache to install an
>entry that essentially looks like a host route. For instance, with only 1
>path to a destination, we will install an entry into the fast cache that
>covers the entire network. Example: 100.0.0.0/8. However, when multiple
>equal cost paths to a destination exist, we will install an entry into the
>fast cache for each destination. Example: 100.0.0.1/32, 100.1.1.1/32,
>100.2.2.2/32...and so on. This helps ensure load balancing. Additionally,
>depending on whether routes are directly connected, and/or subnetted, or the
>next hop of a static route, the results can vary.
>
>When running Nmap & scanning every address in a class A ip network, if
>conditions warrant the installation of a /32 entry into the fast cache this
>would allow the fast cache to consume a tremendous amount of memory and in
>that scenario all available dram could be consumed. This creates additional
>problems because there isn't enough memory to support other features on the
>router.
>
>Since Nmap isn't a normal application ran on networks, this issue isn't a
>concern in most networking environments. However, if this is a major concern
>you could run CEF (Cisco Express Forwarding). The behavior I just explained
>does not occur when running CEF. But you will need to run 12.0 on the Cat5
>RSM. Other workarounds such as disabling fast switching (no ip route-cache)
>or using max-paths 1 aren't really feasible. CEF is the better solution.
>
>Thanks,
*********************************************************
Sure enough, I put an access-list up blocking the infected PC at the
ethernet port and presto.... No more memory allocation errors, no
more bouncing ISDN line. The router and it's 7200 neighbor have been
running clean for almost 24 hours.
Comments?
duder
shope
Seen this elsewhere - it really seems to hurt 7500 series boxes, but all
routers can suffer (had it on Nortel 8600s as well, until the recent code
upgrades limited ARP table sizes and CPU load).
HP managed to generate ARP scans with a laserjet management tool several
years ago - had exactly the same effect - i suppose that counts as malice
replicating poor programming....
BTW - you may want to check your ISDN rules / floating routes - if packets
to random addresses bring up ISDN then you have a large telephone bill
waiting to happen.
>
>
> duder
--
Regards
Stephen Hope - remove xx from email to reply