BFD Multi-Hop
Last updated
Last updated
Load base.ipv4.and.ipv6.cfg
Configure eBGP between R3 and R5 using their loopbacks. R3 is in AS3 and R5 is in AS5. Use BFD to bring the eBGP session down quickly upon failure.
Let’s first examine the default behavior for the eBGP multi-hop session before configuring BFD. We’ll bring down Lo0 on R3:
It ends up taking the full holdtime (3 minutes) for the neighborship to go down!
Of course, one way to speed this up is to just adjust the BGP timers. Personally, I think this is an easier option than using multi-hop BFD. Multi-hop BFD also does not allow for the echo functionality, so either way the keepalives are processed in the control plane anyways.
When using multi-hop BFD, we must use a BFD template. We must also use the bfd map command to associate a BFD neighbor with the tempalte. The syntax of the bfd map command is <destination>/mask <source>/mask <template name>.
Since the BFD session is multi-hop, you don’t apply the commands to a particular interface. Instead, the session exists in the control plane of the router itself. So you need to tell the router what the source/destination of the BFD session should be. For this reason, you cannot use echos with a multi-hop BFD session. (It wouldn’t make sense anyways, because you cannot send a packet both sourced and destinated to yourself and somehow cause a router multiple hops away to loop this back to you).
Now if we bring down Lo0 on R3, we should see that R5 brings down the eBGP session within just a few seconds.
Interestingly, the route is first lost via OSPF, which causes R5’s BFD mapping statement to not be resolvable. Then, BGP states that there is no route to the peer. We did not see this before we configured multi-hop BFD.
Using the show bfd nei detail command that we are familiar with, we can see some new output. We see the details of the mapping, and we see that this is a multihop session which is not using the echo function.
Notice above that in the last packet, we see a “C bit” which is set to 0. The purpose of this is to inform the peer whether it is running BFD in hardware or software.
A value of 0 means that BFD is running in software.
If BFD fails, the dataplane might still be up. So if GR is running, we should keep the peer up even if BFD fails.
A value of 1 means that BFD is running in hardware.
If BFD fails, then the dataplane has failed. GR cannot operate anyways, so we should immediately bring the peer down whether or not GR is enabled.
There is a knob on the BGP fall-over command which instructs the router to act on this value:
This setting is also available for normal single-hop sessions.
There is also a knob called “strict-mode.” This requires that BFD is up before the BGP session will come up. By default, if one side does not have BFD enabled, the BGP session will come up, but without BFD. With the strict-mode knob, BGP will not come up unless BFD is enabled on both sides.
I have removed BFD from R3. When I clear bgp, and debug ip bgp on R5, I see the following debug message on R5:
R3 is now stuck in OpenSent.
