BFD support

[pavel-odintsov]

Hello!

Thank you for progress on developing GoBGP!

Do you have any plans about implementing BFD? It may be quite useful for multihop sessions established over non so reliable channels.

[fujita]

A project such as the following notify GoBGP via gRPC API? https://github.com/jthurman42/go-bfd

[pavel-odintsov]

Yes, like this one but bundled in GoBGP.

[thoro]

I have developed a BFD server in Go, see here: https://github.com/Thoro/bfd

It provides also a GRPC streaming api, so the only thing missing is a small utility that would actually take down the bgp session. But I am not sure if AdminDown would be the correct approach (suggestions?)

Still have todo a README and a release, but it's already running since the 24th of Feburary without a problem on one of my servers.

[fujita]

I guess that AdminDown/Up should work. All you need to shut down a peer after the failure and then make the peer up after the recovery.

[ecbaldwin]

tl;dr: you might want to be careful relying on a BFD implementation that is embedded with the BGP control plane.

As I was experimenting myself with embedding BFD in gobgp, it occurred to me that this will automatically couple BFD with the control plane. This means that if the gobgp service gets restarted for an upgrade or goes down for some other reason, then the BFD service also gets restarted. This will likely cause a disruption in the forwarding plane.

I considered using BFD with graceful restart (GR) but I found that this is not really a way to avoid the disruption. First off, I found the following blurb in rfc4724. I didn't much else in the RFCs about how BFD should interact with BGP.

A BGP speaker could have some way of determining whether its peer's
forwarding state is still viable, for example through Bidirectional
Forwarding Detection [BFD] or through monitoring layer two
information.  Specifics of such mechanisms are beyond the scope of
this document.  In the event that it determines that its peer's
forwarding state is not viable prior to the re-establishment of the
session, the speaker MAY delete all the stale routes from the peer
that it is retaining.

This tells me that if BFD goes down during GR, then all of the routes held by GR may be removed. I couldn't find any mention of a mechanism to make an exception for this because BFD is known to be coupled with the control plane.

Beyond this, I was directed by a colleague to the following blurb from Juniper. He told me that other vendors like Cisco have something similar.

NOTE: Configuring both BFD and graceful restart for BGP on the same device is counterproductive.
When an interface goes down, BFD detects this instantly, stops traffic forwarding and the BGP 
session goes down whereas graceful restart forwards traffic despite the interface failure, this 
behavior might cause network issues. Hence we do not recommend configuring both BFD and 
graceful restart on the same device.

My hosts are leaf devices, commodity servers, which will have L3 connectivity over two independent links to two ToRs. I want to use BFD for fast detection of link failures but I also may need the ability to upgrade some of my software without downtime. I'm still working out the best way to accomplish this but I suspect that decoupling gobgp, bfd, and our forwarding plane integration into multiple coordinating processes may be the best thing to do to minimize disruption if one piece of it needs to be restarted.

[ramonss]

Hi, could anyone confirm whether goBGP works (e.g., (de-)register to destinations) with BFDd (from FRR) via Zebra API?

I see something related to _bfd in the zebra api of goBGP => https://github.com/osrg/gobgp/blob/master/internal/pkg/zebra/zapi.go

Thank you in advance.

[Slepwin]

Hi GoBGP team,

There are any plans to add BFD support in GoBGP bundle?