Destroying a router container closes that router's BMP TCP session, and Netom drops the routes that speaker had sent. The stale state is on the routers that stayed up and were peering with it. Their BMP sessions never close.
Those peers are BGP unnumbered (neighbor <interface> interface). The neighbor comes back with a new MAC and a new fe80:: address. FRR on the surviving router does send a BMP Peer Down, but only after bgp_stop() calls bgp_peer_conf_if_to_su_update(). That rewrites connection->su from the interface's current neighbor list. The old link-local is already gone, so the address is cleared, and bmp_per_peer_hdr() puts :: in the per-peer header instead of the fe80:: from Peer Up.
Netom keys the BgpViaBmp ingress by that peer address, so the Peer Down does not match. The old ingress stays Connected with its Adj-RIB-In, and the new link-local is a second ingress on the same BMP session. gc_disconnected_bmp_peers only reclaims ingresses that have been Disconnected, so the old copy is held until that speaker's BMP session ends or the Netom process exits. Numbered peers are unaffected: their configured address is not rewritten before the Peer Down.
Observed on FRR feature/bmp-transport-vrf with Netom 0.6.0. After replacing a spine, each surviving leaf's BGP table had only the new session for 10.0.0.7/32, while show ingress still listed the pre-swap fe80:: peer as Connected next to the new one. Both carried the same BGP identifier.
While FRR might be patched, perhaps Netom could implement a feature to automatically imply a Peer Down message when a new Peer Up is received with a router ID that matches an existing session
Destroying a router container closes that router's BMP TCP session, and Netom drops the routes that speaker had sent. The stale state is on the routers that stayed up and were peering with it. Their BMP sessions never close.
Those peers are BGP unnumbered (
neighbor <interface> interface). The neighbor comes back with a new MAC and a newfe80::address. FRR on the surviving router does send a BMP Peer Down, but only afterbgp_stop()callsbgp_peer_conf_if_to_su_update(). That rewritesconnection->sufrom the interface's current neighbor list. The old link-local is already gone, so the address is cleared, andbmp_per_peer_hdr()puts::in the per-peer header instead of thefe80::from Peer Up.Netom keys the
BgpViaBmpingress by that peer address, so the Peer Down does not match. The old ingress staysConnectedwith its Adj-RIB-In, and the new link-local is a second ingress on the same BMP session.gc_disconnected_bmp_peersonly reclaims ingresses that have beenDisconnected, so the old copy is held until that speaker's BMP session ends or the Netom process exits. Numbered peers are unaffected: their configured address is not rewritten before the Peer Down.Observed on FRR
feature/bmp-transport-vrfwith Netom 0.6.0. After replacing a spine, each surviving leaf's BGP table had only the new session for10.0.0.7/32, whileshow ingressstill listed the pre-swapfe80::peer asConnectednext to the new one. Both carried the same BGP identifier.While FRR might be patched, perhaps Netom could implement a feature to automatically imply a Peer Down message when a new Peer Up is received with a router ID that matches an existing session