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==--