Travis,
Thanks for the response, we are running 11.2. I would also agree with the
allocation of memory issues that you mention. One other note, it was told
to me yesterday a 2500 series in the same time frame over 5 hops away had
the same problem. Although this router has much less mem (4Meg) so if the
scope of received packets was smaller it, could still be enough to take down
a 2500 (providing the allocation algorithm is the same for 11.1.7).
Thanks for your help
Andrew
-----Original Message-----
From: Travis Pugh [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 02, 1999 4:58 AM
To: 'Lancashire, Andrew'; [EMAIL PROTECTED]
Subject: RE: Cisco and Nmap Dos
I just finished running CyberCop and nmap against a smaller range
(192.168.0.0) on a cat 5500 w/RSM and didn't notice any memory issues on the
RSM. Perhaps it is just the traffic generated by scanning the entire /8 at
once. The Cisco engineer is correct about the small packet issue, though, as
Cisco doesn't dynamically free memory. If you manage to allocate all of the
memory in small (64-128k) chunks, as I have seen before when there is a lot
of route flapping and the rtr is constantly allocating small chunks to
update the route table, the box has no mechanism to take all of the freed
memory space once it's done with it and turn it into a larger contiguous
(sp?) block. This can crash the box. The whole thing 40+Mbps thing should be
discounted, though, as the RSM should be able to handle much more traffic
than that.
Also, do you know what version of IOS the RSM is running?
> -----Original Message-----
> From: Lancashire, Andrew [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, August 31, 1999 8:02 PM
> To: [EMAIL PROTECTED]
> Subject: Cisco and Nmap Dos
>
> I don't know if you've ever seen this before. We ran nmap with ICMP
> discover and standard tcp scan. We ran the scan against the entire
> 10.0.0.0
> network range. Although we were only looking for 2 ports, we found that
> the
> RSM in our 5500 series (our default route) was running out of memory and
> had to be rebooted by our Network Services group multiple times in the 18
> hour stretch it took to complete. One of the interesting things is that we
> were only generating about 3-5 Mbs and the 5500 can pass Gigabits. I
> have
> not heard of this problem before. We contacted Cisco and sent them the
> details. Below is the response to one of our engineers.
>
> Andrew
>
> -----Original Message-----
> From: khollis [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, August 31, 1999 7:59 AM
> To: [EMAIL PROTECTED]
> Subject: Regarding Case Number V44290
>
> Hi Dave, as I recall, the symptom we had to work/troubleshoot with was the
> router consumed lots of memory. Never heard about packets being dropped.
> So
> it seems like we forwarded everything nmap sent to us. The thing to keep
> in
> mind is that the router will dynamically allocate memory as necessary so
> that it can keep up with the load provided to it. Although we did not know
> nmap was running at the time, we noticed the memory consumed by the IP
> Input
> process dropped from 40M+ to an acceptable level of (4-5M) after nmap was
> shut down. This proves that the router need this much memory to process
> the
> entire load generated by nmap.
>
> I suspect nmap was doing much more than you've been able to calculate.
> It's
> obvious that running nmap continuously for 18-19 hours caused this
> problem.
> One possible explaination is constantly flooding the router w/64 byte
> packets for this timeframe could have caused the router's memory to become
> seriously fragmented. Also, I guess we can't tell, but another question
> would be how many tcp sessions were requested/open on the router after
> this
> timeframe?
>
> Port scanners have a reputation of helping identify potential security
> problems. However, they are also known to cause problems...
>
> Hope this helps,
> KennyH.
