18 July 2023

BFG, BGP and BFD

By admin@labtinker.net

If you were a Big Friendly Giant and wanted fast BGP convergence,you might well investigate BFD. (OK, now I have justified my alliteration we can move on)

In the previous post, we had a resilient BGP topology which I will remind us of here:

When the FG1 Fortigate was shutdown it took BGP between two and three minutes to re-route traffic through FG2. Popular wisdom suggests the answer to our dilemma is BFD (bidrectional forward detection). This is a separate protocol altogether, not just a BGP option, and it can be used with OSPF or static routes:

https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/771813/bfd

On the Fortigate, it can be enabled in system settings, per VDOM, on the interface and on the BGP neighbor. I found it necessary to enable it on the interfaces and on the BGP neighbor config (on all firewalls), examples of which are shown below:

The improvement was quite startling. When I shutdown the FG1 firewall (the red link lights indicate FG1 is down):

…the convergence instead of taking minutes was short enough that only ping response was missed.

When I turned FG1 back on the transition back wasn’t quite so smooth – probably 30 seconds (I was timing but got distracted !!)

Presumably, the interface/ BGP relationship between FG1 and FG3 recovers before the BGP relationship between R1 and FG1 has been re-established (there was no BFD defined between them ).

I simulated a slightly less catastrophic failure by shutting down the port1 interface on FG1 that faced FG3 , waiting ten seconds and then re-enabling it. In this instance, I saw the missed ping initially but no subsequent dropped traffic and I confirmed the BGP path had re-established through FG1.

The configurations are identifical to the previous post save for the BFD settings as discussed above. No changes on R1: