Re: slowing down every 60 seconds due to BGP scaner

Thank you for all your replys ! Sorry for the lack of more info . There are 12000s, with 12.0+ IOS , has one or more EBGP peers and 10+ IBGP . Customer gave us continuous ping and pinpoint this 60s thing . I think Chris Konger is right . We will put more memory and enable CEF on the line cards to see if its better . Ben --- Chris Konger <ckonger@internap.com> wrote:
tang bing wrote:
I found all of my backbone routers slow down every 60 seconds, it will last 5 seconds . While this happens , the CPU may get more than 70% utilization and BGP scaner is the process that chewing the CPU (50%). Customer with video stream noticed that. Cisco said it's normal. Any idea ?
The 60 second lags will be observed with any packets that are *process* switched. Fast/CEF switching aren't impacted by the minute processes. So the more traffic you can get off the CPU, the better.
BTW, if you are doing pings/traces from the routers to check this you will always observe the 60 second lags. This is because these commands are *always* process switched when executed on the router.
Chris Konger
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
__________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/

On Fri, Sep 14, 2001 at 11:50:40AM -0700, tang bing wrote:
Thank you for all your replys ! Sorry for the lack of more info . There are 12000s, with 12.0+ IOS , has one or more EBGP peers and 10+ IBGP . Customer gave us continuous ping and pinpoint this 60s thing .
ping's to the router will show this, and cannot be used for anything, what about end to end traffic ?
I think Chris Konger is right . We will put more memory and enable CEF on the line cards to see if its better .
The 12000's cannot run without CEF, so you have that enabled, and the amount of memory on the LineCards doesn't affect this. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.

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
participants (3)
-
Chris Konger
-
Jesper Skriver
-
tang bing