> For the complete documentation index, see [llms.txt](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/bfd/basic-bfd-for-all-protocols.md).
# Basic BFD for all protocols
Load **base.ipv4.and.ipv6.cfg** in the INE SPv4 workbook lab topology.
```
#IOS-XE
config replace flash:base.ipv4.and.ipv6.cfg
#IOS-XR
configure
load bootflash:base.ipv4.and.ipv6.cfg
commit replace
y
```
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.
## Answer
```
#R4
int gi2.46
ip ospf 1 area 0
ospfv3 1 ipv6 area 0
ip router isis
ip pim sparse-mode
!
bfd interval 750 min_rx 750 multiplier 4
!
ip ospf bfd
ospfv3 bfd
isis bfd
ip pim bfd
!
router isis
net 49.0001.0000.0000.0004.00
!
router bgp 4
neighbor 20.4.6.6 remote-as 6
neighbor 20.4.6.6 fall-over bfd
#R5
int gi2.56
ip ospf 1 area 0
ospfv3 1 ipv6 area 0
ip router isis
ip pim sparse-mode
!
bfd interval 750 min_rx 750 multiplier 4
!
ip ospf bfd
ospfv3 bfd
isis bfd
ip pim bfd
!
router isis
net 49.0001.0000.0000.0005.00
!
router bgp 5
neighbor 20.5.6.6 remote-as 6
neighbor 20.5.6.6 fall-over bfd
#R6
int gi2.46
ip ospf 1 area 0
ospfv3 1 ipv6 area 0
ip router isis
ip pim sparse-mode
!
bfd interval 750 min_rx 750 multiplier 4
!
ip pim bfd
!
int gi2.56
ip ospf 1 area 0
ospfv3 1 ipv6 area 0
ip router isis
ip pim sparse-mode
!
bfd interval 750 min_rx 750 multiplier 4
!
ip pim bfd
!
router isis
net 49.0001.0000.0000.0006.00
bfd all-interfaces
!
router ospf 1
bfd all-interfaces
!
router ospfv3 1
bfd all-interfaces
!
router bgp 6
neighbor 20.4.6.4 remote-as 4
neighbor 20.4.6.4 fall-over bfd
neighbor 20.5.6.5 remote-as 5
neighbor 20.5.6.5 fall-over bfd
```
## Explanation
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.
## Verification
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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/bfd/basic-bfd-for-all-protocols.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.