General

BGP NSR Scoped-sync for BGP sessions may failed and ios-msgs similar to the ones below may be seen. RP/0/4/CPU0:Jan 14 08:48:56.467 : bgp[1046]: %ROUTING-BGP-5-NBR_NSR_DISABLED_STANDBY : NSR disabled on neighbor 194.25.5.234 on standby due to Scoped sync failed and need retry (VRF: default) RP/0/RP0/CPU0:Jul 22 07:54:52.692 JST: bgp[1035]: %ROUTING-BGP-3-INITSYNC_PFX_MISMATCH : Neighbor: 10.208.0.2 State: Established Flags: 0x3140e0 vrf: default AFI: IPv4 Unicast Pfx accepted: 24 synced: 20 - finished retry The BGP peer is not NSR Ready in show bgp sessions output

Symptom

BGP NSR Scoped-sync for BGP sessions may failed and ios-msgs similar to the ones below may be seen. RP/0/4/CPU0:Jan 14 08:48:56.467 : bgp[1046]: %ROUTING-BGP-5-NBR_NSR_DISABLED_STANDBY : NSR disabled on neighbor 194.25.5.234 on standby due to Scoped sync failed and need retry (VRF: default) RP/0/RP0/CPU0:Jul 22 07:54:52.692 JST: bgp[1035]: %ROUTING-BGP-3-INITSYNC_PFX_MISMATCH : Neighbor: 10.208.0.2 State: Established Flags: 0x3140e0 vrf: default AFI: IPv4 Unicast Pfx accepted: 24 synced: 20 - finished retry The BGP peer is not NSR Ready in show bgp sessions output

Conditions

BGP scoped-sync is suspended due to excess amount of data to be synced from BGP on Active RP to BGP on Standby RP. When the sync is resumed it doesn't resume at the exact point where it stopped. Due to this, some prefixes don't get synced to Standby BGP process. This results into mismatch in # prefixes synced and # prefixes expected.

Workaround

There is no workaround guaranteed to fix the issue without any disruption. However, if we flap the BGP session with the affected peer after BGP is globally NSR-Ready, the scoped-sync is skipped and both Active BGP and Standby BGP process will get the full update from the peer. This would make the peer NSR Ready

Further Problem Description