[c-nsp] Quick question regarding BGP route churn & PRP-2

[Mark Tinka]

On Thursday, March 07, 2013 03:20:56 PM Drew Weaver wrote:

> Howdy,
> 
> One of our routers in a smaller facility is still rocking
> a pair of PRP-2s and we've been getting notices lately
> that it has been failing to respond to SNMP queries.

We have a bunch of XR 12000's still running PRP-2's as well, 
and this a real issue of ours.

BGP Router is the offending process, but BGP Scanner comes 
in from time to time as well. It's worse on routers handling 
more full tables, obviously.

We think a software upgrade (we're on 12.0(32)SY12) might 
help, but also removing or reducing the BGP table on the 
worst-affected routers looks like a more reasonable 
approach.

We have cleaned up inactive sessions (either shut them down 
or removed them entirely) wherever we can, as there are 
known issues in IOS that cause memory leakage with enabled 
but inactive sessions. And since the BGP Router process 
suffers more as memory utilization increases, this makes 
sense.

Also, using features like "fall-over" (BGP Fast Peering 
Session Deactivation) would help keep BGP Scanner in check, 
but the code is not as robust as it is on the more advanced 
boxes. Plus, it only supports IPv4 (I don't like the way 
Cisco have introduced "fall-over" support for IPv6 - making 
it require BFD, yuck!).

> This particular router is still running IOS and hasn't
> been upgraded to XR.

We considered the PRP-3, but that only wants IOS XR, which 
introduces other issues with what line cards it can support 
in the chassis, re-doing your configuration, e.t.c.

We're scheduled to do a major hardware upgrade in the coming 
months, which is the ultimate solution to this issue, but 
like you, we need to chug along in the meanwhile.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20130705/829eec7a/attachment.sig>