Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
after upgrading to nxos 7.0(3)I7(6) from 7.0(3)i7(3) it was noticed that bgp routes were being refreshed after 60 second. . in the lab route 8.8.8.8 is being originated via ebgp and adervtised across the network. in the workng state the rib shows that there is a next hop going out a physical interface toward the destination. After the upgrade the same route shows up with a valid next hop that is two hops away and is recursed several times before recursing to the same physical interface. It is observed that this route stays in the rib for 60 seconds and reset. in the bgp table the route changes from valid to invalid due to an unreachable nhr. this changes between valid and invalid every 60 second. The condition is reproducible in the lab. NXOS codes that were tested were 7.0(3)I7(3),7.0(3)I7(4),7.0(3)I7(5), and 9.2.2. All of these version work. the customer upgraded from 7.0(3)i7(3) directlly to I7(6).
ISSU upgrade from 7.0(3)I7(3) to 7.0(3)I7(6)
A next hop address was indicated in the ip route table that was two hops away.. The bgp peer that owns that next hop was shut down. This caused the recursive routes to be deleted and only the next hop ip address that was directly connected was seen in the table. The flapping ceased.
ROUTER# sh ip bgp BGP routing table information for VRF default, address family IPv4 Unicast BGP table version is 2892, Local Router ID is 20.20.20.20 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-i njected Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup Network Next Hop Metric LocPrf Weight Path * i8.8.8.8/32 1.1.1.1 0 100 0 1i *>i 1.1.1.1 0 100 0 1 i this shows both entries with the same address here is the example of the route in the code that works. *>i8.8.8.8/32 10.10.10.10 0 100 0 1i * i 1.1.1.1 0 100 0 1i