BFD on back-to-back connected BGP-speakers
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
Hugo, I've used this configuration in a past line when I may of had multiple L2 steps between L3 devices. The only concern we had was around load BFD put on _some_ endpoint routers, if was handles on the RouteProcessor vs on line cards. -jim On Tue, Nov 29, 2016 at 2: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
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
On 29 November 2016 at 20:23, Hugo Slabbert <hugo@slabnet.com> wrote: Hey,
- 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?
If you have HW liveliness detection and fast-failover, I think BFD probably will just reduce availability due its failures being more probable than the edge cases in your setup. I personally would not run BFD here. -- ++ytti
participants (4)
-
Hugo Slabbert -
jim deleskie -
Ryan L -
Saku Ytti