Basic BFD for all protocols
Last updated
Last updated
Load base.ipv4.and.ipv6.cfg in the INE SPv4 workbook lab topology.
Configure the following neighborships between R4-R6 and R5-R6:
OSPFv2
OSPFv3
ISIS
PIM
BGP (IPv4 and IPv6)
Use BFD with an interval of 750msec and a dead-detection time of 3 seconds.
When enabling BFD for each protocol, use interface commands where possible on R4 and R5, and use global process commands where possible on R6.
BFD (Bidirectional Forwarding Detection) is a standard protocol that allows for fast dead peer detection at layer 2. This is extremely useful for Ethernet, because Ethernet does not rely on some type of end-to-end neogitation to setup the layer 2 link between nodes. It is possible for multiple layer 1 devices to exist in a layer 2 path between two nodes. This makes it possible for one node’s link to go down but the other node to still believe the link is up. It will take that node the full routing protocol’s dead interval time to declare the neighbor unreachable and initiate route convergence.
BFD relies on the routing protocols to register with it before forming neighbor sessions. So for example, when using BFD with OSPF, BFD will wait for OSPF to discover the neighbor and then will initiate the BFD session with the discovered neighbor. If BFD detects that the neighbor goes down some time later, it notifies OSPF which immediately brings down the neighbor. This allows for much faster failure detection that relying on the protocol’s dead interval.
BFD is faster and more scalable that routing protocol Hellos for two reasons. One, a single BFD session is used no matter how many protocol adjacencies exist between the neighbors. In our lab, we have PIM, ISIS, OSPFv2, OSPFv3, and eBGP between each neighbor, but we will see that there is only one BFD session per address-family (IPv4/IPv6) between each node. The BFD session can have multiple protocols registered to it, and can notify all of them when the single session goes down.
Reason two: BFD uses echo packets which allow liveness detection to happen using the dataplane instead of the control plane. BFD echo packets have a source and destination of the originating node itself. This means that a BFD echo packet that R4 sends to R6 has src: 20.4.6.4 dst: 20.4.6.4. (The src MAC is R4 and the dst MAC is R6). This forces R6 to simply loop the packet in the data plane. It doesn’t require R6 to process the packet in CPU because the packet is not destined to R6 itself. This completely offloads BFD to the hardware.
BFD also uses separate control packets. These can run at a much slower timer, even up to once per 30 seconds. By default this is set to once per second though, which is the fastest possible “slow timer.” (BFD control packets are sent using the “slow timer”). The control session negotiates whether echos are used (they don’t have to be), and the interval that the echos will be sent. If echos are not used, then the faster timers (controlled using the interface interval command), will be used for control packets instead. (The configured “slow timers” will be ignored). Usually you’d want to use echo packets, because this is how you achieve hardware offloading. For some reason, as we will see in this lab, using BFD for IPv6 does not have the capability of using echos, so only control packets are used instead. Also note that when using both echos and control packets, a failure of either one will result in the BFD session going down.
One more thing to note about BFD is that when using echos you must disable uRPF, and you should also disable ICMP redirects. If you leave ICMP redirects enabled, the router will know to supress any redirect messages in response to echos. But if you turn on uRPF, the router will drop received echo packets. Admittedly this is a little confusing to me, because the source should pass verification. (The source is reachable out the interface). However, the destination is reachble out the interface as well, which doesn’t make sense. This must be why the uRPF feature drops the packets. I verified this is the case in the lab. You can disable BFD echos on a per-interface basis using no bfd echos. This would allow you to still run BFD while using uRPF. BFD only uses control packets in this case.
On R4 we can verify our BFD sessions using show bfd neighbors. This doesn’t give us much output, but it lists our BFD peers and shows whether they are up:
We can also verify BFD status on a per-protocol basis. These show commands are displayed below:
Notice that OSPFv3 uses a separate BFD session over the link-local IPv6 addresses. We can see more detail about the BFD session using show bgp neighbor detail. Let’s take a look at the IPv6 session:
Notice that the neighbor address and outoing (source) address are the IPv6 link-local addresses. The minTx and minRx intervals are 750msec, which was configured locally on the interface. We also received a minRx interval of 750msec from the peer. These intervals are not the echo intervals, they are actually the slow timer intervals, which is used for the control packets. Notice at the bottom that the last packet shows a min echo interval of 0. This is a special meaning, which means to not use echos at all. When echos are not used, the interval timers on the interface are used for the control packets instead of echo packets. Finally, also notice that OSPFv3 is the only registered protocol (besides CEF).
Let’s now look at the IPv4 BFD session details:
Above, we can see some new fields. We see the echo rx/tx count. If we look at the average values, we can see this is close to our configured interval of 750msec. The minTx and minRx intervals, which we also saw for the IPv6 session, now show 1 second instead of 750msec. Since IPv4 can use the echo, the slow timers (which are by default 1 second) are used for the control packets, and the defined interval on the interface is used for the echo packets. Notice in the last packet we see a min tx and min rx of 1 second. The min echo is now 750msec instead of 0, as we saw for IPv6. Each peer only advertises its min_rx interval in the BFD control packet. The local peer compares its min_tx interval to the received min echo interval from the peer, and uses the slowest time (largest value) as the echo transmit interval. Interestingly, both the tx and rx slow timers are advertised, but these cannot be configured separately. Only one value is configured using the global bfd slow-timers command. Finally, notice all the protocols that have registered with this session (PIM, ISIS, BGP, OSPF).
We can simulate one-side link failure because all nodes are connected to a layer 2 switch in this lab. If we shutdown Gi2.46 on R6, we should see that R4 brings down all protocol neighbors/adjacencies after 4 seconds.
