Symptom

There are several symptoms that may be seen for this bug. 1. BGP process may crash , on new active/old standby, after a RP failover. 2. BGP routes may be missing from neighbors after the session is restarted 3. BGP process on the standby RP could consume higher than normal CPU utilization 4. BGP process may consume more than average memory on the standby RP 5. NSR may stay in "not NSR-ready" state after the bug is triggered until BGP is restarted on the standby RP.

Conditions

This problem is seen after a peer where we're receiving > 10,000 prefixes goes oper_down AND BGP NSR is enabled. TCP sends a oper_down notification, to BGP, when it has missed keepalives from that peer for approximately half the hold time. Note, if the peer misses keepalives for the full holdtime and BGP tears the session down this will not trigger CSCtk82229. You can identified you have hit this bug by issuing "show bgp all all nsr" and look for

Scoped sync state: Batch is syncing.

+++ example from Cisco lab where the bug was reproduced ++++ RP/0/0/CPU0:ios#sho bgp all all nsr ### snip to interesting info #### Current BGP NSR state - NSR Ready achieved at: Apr 4 08:58:35 NSR State NOT READY notified to Redcon at: Apr 4 09:09:12 Last NSR reset reason: TCP notified active bgp about NSR Operation down

Scoped sync state: Batch is synncing

<============== +++++ end +++++++++++

Workaround

: There is no known workaround.

Recovery

: If symptom #1 is seen where BGP is crashing on the active then you need to restart BGP process on the active RP. If symptom #2 - 5 is seen then you should perform a restart of the standby BGP process.

Workaround

Further Problem Description