Hugo, I think those are all valid potential reasons to use BFD. I use it for some of the same reasons even on direct connect peers. Only time I ever recall actively avoiding it if I had the capability was if I had NSF/SSO, since they didn't used to (still don't?) play very well together. On Tue, Nov 29, 2016 at 1:23 PM, Hugo Slabbert <hugo@slabnet.com> wrote:
Good morning, nanog,
Is there any/sufficient benefit in adding BFD onto BGP sessions between directly-connected routers? If we have intermediate L2 devices such that we can't reliably detect link failures BFD can help us quickly detect peers going away even when link remains up, but what about sessions with:
- eBGP with peering to interface addresses (not loopback) - no multi-hop - direct back-to-back connections (no intermediate devices except patch panels)
Possible failure scenarios where I could see this helping would be fat fingering (filters implemented on one or the other side drops traffic from the peer) or e.g. something catastrophic that causes the control plane to go away without any last gasp to the peer.
Or is adding BFD into the mix in this type of setup getting into increasing effort/complexity (an additional protocol) for dimishing returns?
-- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal