Hey Michael, On Mon, 9 Jul 2018 at 17:09, Michael Hare <michael.h...@wisc.edu> wrote:
> When I was a bit greener with our MPLS network I would experience the same > concern as Alexandre when a dual connected customer lost a PE, in that I > would experience loss of service waiting for BGP to timeout. I briefly went > down the wrong path (IMHO) of BFD everywhere, including on directly connected > links (yes, I know BFD can help for control plane issues, but 99%+ of the > time for us it is 'switch-in-the-middle' problem). I even put multihop BFD > on my iBGP sessions, which I later removed. The correct configuration (at > least in my experience) was to invalidate BGP next hops, as Saku points out, > and keep the BGP session up (assuming outage is less than 60s - 90s and > normal timers), so I had no delay in re-estalbishing BGP and repopulating RIB > in the flap was brief. This is highly subjective, but I do not like BFD. I would only consider BFD when L1 liveliness does not work (L2 in between or such). I think issues undetected by L1 liveliness detection is far smaller than issues caused by BFD false positives. I like your solution of limiting resolution, because this is essentially same as making BGP convergence depend entirely on IGP convergence, for ~free. Potentially add ADD-PATH and PIC and you can have redundant route already programmed in HW, requiring no SW convergence to switch to backup path. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
