Symptom

BGP routes are not advertised towards a peer after we after we shut/no shut the interface that connects to the peer .Connectivity :6500-1 (10.1.127.9)---------e1/6--N9K --e1/10 ----- 6500-2 (199.87.76.9) Issue : When we flap interface e1/10 and the interface comes up , BFD and BGP peering comes up , however no routes are getting advertised to this peer: Nexus9K(config)# int e1/10 Nexus9K(config-if)# sh Nexus9K(config-if)# no sh Nexus9K(config-if)# sh ip bgp neighbors 199.87.76.10 advertised-routes Peer 199.87.76.10 routes for address family IPv4 Unicast: BGP table version is 29, local router ID is 10.1.127.9 Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist, I-injected Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup Network Next Hop Metric LocPrf Weight PathDuring this state : Nexus9K# sh ip bgp 199.87.78.0/24 BGP routing table information for VRF default, address family IPv4 Unicast BGP routing table entry for 199.87.78.0/24, version 19 Paths: (2 available, best #2) Flags: (0x000018) on no lists, is in urib, is best urib route, is not in HW Path type: local, path is invalid(not in urib), no labeled nexthop AS-Path: NONE, path locally originated 0.0.0.0 (metric 0) from 0.0.0.0 (10.1.127.9) Origin IGP, MED not set, localpref 100, weight 32768 Advertised path-id 1 Path type: external, path is valid, is best path, no labeled nexthop, in rib AS-Path: 13607 , path sourced external to AS 10.1.127.10 (metric 0) from 10.1.127.10 (161.244.15.10) Origin IGP, MED 0, localpref 150, weight 0 Path-id 1 not advertised to any peer------------It stays in this state till we manually recover. Path-id 1 scheduled to be advertised to peers: 199.87.76.10

Conditions

BGP has the same prefix in network command and as incoming route from a bgp peer Have observed this issue after Shut/no shut of interface connecting to the peer. The issue happens only intermittently and not always observed

Workaround

Clearing BGP neigh towards 6500-1 (10.1.127.9 - the peer that originated this prefix ) fixes this issue . Also, the network command is actually redundant - BGP will simply advertise incoming eBGP routes to other eBGP or iBGP neighbors without it. Removing it avoids the problem.

Further Problem Description