Re: [c-nsp] Best Practices for quickly removing routes when BGP peer drops

Gert Doering via cisco-nsp <[email protected]> Wed, 10 Dec 2025 20:06:03 +0100
Newsgroups gmane.network.nsp.cisco
Message-ID <[email protected]>
--===============5912864396769468250==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="cszzJ7Z/96Pvmbbw"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit


--cszzJ7Z/96Pvmbbw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Dec 10, 2025 at 07:12:25PM +0100, Lukas Tribus via cisco-nsp wrote:
> I don't understand.
>=20
> How is this supposed to work without transient loops and without
> tunneling (label unicast/vpnv4), when your core has yet to converge?
>=20
> For this to work the internal routers you cross all would have to
> converge their FIB at the same time at the same speed and in the same
> order?
>=20
> What am I missing here?

Without labels ("any sort of tunnels") you would see transient loops,
but convergence would still be faster if the edge already has a candidate
backup path - as compared to "send withdraw, wait for the other side(s)
to process the withdraw, and send the new-best path back".  So it will
be converged after "process withdraw, select new path".

gert
--=20
"If was one thing all people took for granted, was conviction that if you=
=20
 feed honest figures into a computer, honest figures come out. Never doubte=
d=20
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistre=
ss

Gert Doering - Munich, Germany                             [email protected]=
=2Ede

--cszzJ7Z/96Pvmbbw
Content-Type: application/pgp-signature; name=signature.asc
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCAAdFiEEti5qK05WVwt73GvgHYKe/spWKBIFAmk5xJoACgkQHYKe/spW
KBK6gwv+IpLvHG+JYxdj9FEe+2R1/Z4H6zdhie5pAlGdAVsTfyznjeDOG+H6zWJ2
ygQlEqpvghdNWgK2Itfz0AHmHPOA+Lug0ScnUrwjtaIuJrL0Wx2nGxsSzZCg+WFz
GWhem1eYx8c3rxJBJHsyBF7btHIBGnWZ6pXNokwPmZ1ov/PbE7K3HB60lq6ZJgN9
ESMfpGB6NDwiS2ojYmVG9UDgd4N8m4vxVhuhCPHQbEZnzIarTpq2EGlaRY/T+phW
2+ZORvLfiw0h1/b+JC43ZZt8McQTSCYWQOeTA9byhvaTY7uFeZKAyATqTPPOFmWm
lHtYVErXh+z2PrTcuJ3l47bxGWrdRIOfBJV/INKTO+fk60YG2NLRhWJb1oq5OIM8
8erlZZhhz97RY5hlcWvT3wDyy23RaBmCpVpAvolL0u7VPhfmDZ6vwtUuOmOIMUjm
fpORpqRzAq8DP61rHQ5+DpGnIhcGOLBjB5vzKd24FBWV1duxscgKom8ibyLtiMux
lVZot804
=rl49
-----END PGP SIGNATURE-----

--cszzJ7Z/96Pvmbbw--

--===============5912864396769468250==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2lzY28tbnNw
IG1haWxpbmcgbGlzdCAgY2lzY28tbnNwQHB1Y2submV0aGVyLm5ldApodHRwczovL3B1Y2submV0
aGVyLm5ldC9tYWlsbWFuL2xpc3RpbmZvL2Npc2NvLW5zcAphcmNoaXZlIGF0IGh0dHA6Ly9wdWNr
Lm5ldGhlci5uZXQvcGlwZXJtYWlsL2Npc2NvLW5zcC8K

--===============5912864396769468250==--