[c-nsp] 1841 suitable for BGP?

Mikael Abrahamsson swmike at swm.pp.se
Tue Aug 29 09:46:54 EDT 2006


On Tue, 29 Aug 2006, Tony Varriale wrote:

> Not to butt in but I could show you real world utilization (ave and peak) for 
> a good handful of software based Cisco platforms.
>
> I'm sure the gear I'm familiar with isn't crashing, but I can show you 50% 
> peak CPU on NPE 400s because of BGP scanner running every 60 seconds (since 
> that's it's run interval).  Also, I can show you how 1 eBGP peer reset will 
> send that NPE400 to 100% CPU.
>
> Since NPEs are software based and the CPU is at 100%, what would you say are 
> happening to the packets that should be going thru the box?  I know for sure 
> based on my monitoring that not all the packets are being forwarded at that 
> time.  Are all being dropped?  No.  But it's very difficult to correlate 
> exact microsecond CPU utilization and actual packet drop.

As far as I understand it, if the BGP scanner is running and a packet 
needs servicing, the BGP scanner will be interrupted and the packet will 
be forwarded, after that, the BGP scanner process will resume.

We have quite detailed jitter and packet loss analysis going, and we have 
plenty of NPE-300 etc that very often peak at 100% cpu util when BGP 
scanner is running, without this noticably affecting packet performance 
thru the box.

That is how we discovered that one some (older) versions of IOS there was 
a bug which caused some ATM interfaces and (very importantly) ISL 
encapsulated packets to not go fast-path on 7200. We had to upgrade (after 
TAC case) IOS and switch away from ISL to .1q to solve the issues.

If BGP scanner noticably affects your packet performance while you're 
running CEF, you should open a TAC case and try to get the issue resolved.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se


More information about the cisco-nsp mailing list