Jesper Skriver wrote:
ping's to the router will show this, and cannot be used for anything, what about end to end traffic ?
"David McGaugh" <david_mcgaugh@eli.net> writes:
We've brought this concern up to Cisco before and they assured us that everything is performing normally. You will see this when performing router to router pings as well however, we have been told that packet forwarding does not suffer. ICMP replies from the router (not through the router) are given a very low CPU priority.
"Robert E. Seastrom" wrote:
Seconded. Ping response times or lack of ping response from routers signifies *nothing*. Ditto for traceroutes, &c. Ping *through* the router, not *to* the router.
I think we're all in agreement here. Here's what I said Tang after he said what his platform was. The original message didn't have that info, so I sent several possibilities - all off channel. Wasn't on nanog-post at the time (which is why the larger group was not CC'd). -------- Original Message -------- Subject: Re: slowing down every 60 seconds due to BGP scaner Date: Fri, 14 Sep 2001 12:13:46 -0700 From: Chris Konger <ckonger@internap.com> To: tang bing <tang_bing@yahoo.com> tang bing wrote:
We will put more memory and enable CEF on the line cards to see if its better .
If the customer is doing the test from their *router*, the lags are due to the pings being process-switched and thus impacted by the correlated bgp-scanner. The best test is to ping *through* the routers via other src/ dst boxen (some servers hanging off the routers). That way the 'pings from the routers always being process-switched' won't be impacted. Alternatively, you can ping for a long long time and the 60 second spikes will wash out in the average (but will still show up in the max value). Hope this helps! CK PNAP Network Engineer 415-364-2105 direct InterNAP Network Services 415-296-8611 fax 555 Montgomery, Suite 816 415-596-4891 cell San Francisco CA 94111 888-841-2810 pgr