Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
On a Nexus device (n9k/n7k/n5k/n6k), BGP may not withdraw reachability to a prefix to downstream BGP peers, even when all paths to the prefix have been lost. Instead, BGP will continue to advertise reachability to prefixes. This can cause traffic destined to these prefixes to be black-holed. For example, consider the following output: Nexus# show ip bgp 192.0.2.128/25 BGP routing table information for VRF default, address family IPv4 Unicast BGP routing table entry for 192.0.2.128/25, version 2859 Paths: (0 available, best #0) Flags: (0x8010000) on no lists, is not in urib, is not in HW, <<< Path-id 1 (path deleted) advertised to peers: 192.0.2.1 192.0.2.2 192.0.2.3 192.0.2.4 192.0.2.5 192.0.2.6 192.0.2.7 192.0.2.8 Even though BGP explicitly states that there are no paths to the 192.0.2.128/25 prefix in the URIB (Unicast Routing Information Base), the path is still being advertised to a total of eight BGP peers. This may cause the downstream BGP peers to install a route to this prefix through the local Nexus device. Since the local Nexus device does not have a path in the unicast routing table for this prefix, this traffic would be dropped, causing connectivity issues within the network.
+++ Any Nexus device running an affected NX-OS software release +++ The output of `show ip bgp ` shows that a specific prefix is not present in the unicast routing table, but is still being advertised to BGP peers with a "Path-id 1 (path deleted) advertised to peers" message. +++ Downstream BGP peers install a route to this specific prefix with a next-hop of the affected BGP speaker, causing traffic to be discarded when it traverses the affected BGP speaker due to a lack of routes for this prefix in the unicast routing table.
Restarting the BGP process may resolve this issue. This can be done with the `restart bgp ` command. This command is disruptive and will cause a brief network outage while BGP peers re-form adjacencies and process received prefixes. Performing a hard clear of all BGP peers may also resolve this issue. This can be done with the `clear ip bgp *` command. This command is disruptive and will cause a brief network outage while BGP peers re-form adjacencies and process received prefixes.