We use a PRTG server that's connected to a cisco 6500, which feeds a large network of about 1200 switches and radios in a router-on-a-stick topology. In PRTG I'm able to set a 'ping burst' sensor on a device, and I can set the ping size, count, timeout, and delay(between each count).
I have all my ping burst sensors to 32 bytes in size, a timeout of 5 seconds, a count of 100, with a delay of 100ms. So each minute 100 32 byte pings are sent with a 100ms delay between each.
I have more than several of these sensors set throughout the network, and one on the 6500. My problem is that the 6500 shows 5-8% loss spikes occasionally and almost consistent 1-2% loss, even though it's one 10 gig switch away. Is there a way to tell if the router is dropping these out of DOS suspicion?
I also have some scenarios where A feeds B and B feeds C, all 3 have the sensor, but sometimes A and C will show the same loss spike, but it will be missing from B. I'm having trouble understanding how that's possible. Would SNMP be more accurate than ping bursts?
Best Answer
I would use 'debug ip packet' and trace the ICMP packets at the time you send the bursts. That would give you an idea of what was happening.
More info here: Cisco Debugging
And, I'll reprint the warnings from that site here:
Enabling debugging can disrupt operation of the router when internetworks are experiencing high load conditions. Hence, if logging is enabled, the access server can intermittently freeze as soon as the console port gets overloaded with log messages.
You'll need to disable fast-switching to see the packets so:
Disabling fast-switching on a router that handles a large number of packets can cause CPU utilization to spike so that the box hangs or loses its connection to its peers.
Do not disable fast-switching on a router running Multi Protocol Label Switching (MPLS). MPLS is used in conjunction with CEF. Therefore, disabling fast-switching on the interface can have disastrous effect.