# BFD Multi-Hop
Load **base.ipv4.and.ipv6.cfg**
```
#IOS-XE
config replace flash:ospfv2.cfg
#IOS-XR
configure
load bootflash:ospfv2.cfg
commit replace
```
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.
## Answer
```
#R3
bfd-template multi-hop BGP_MH
interval min-tx 750 min-rx 750 multiplier 3
!
bfd map ipv4 5.5.5.5/32 3.3.3.3/32 BGP_MH
!
router bgp 3
neighbor 5.5.5.5 remote-as 5
neighbor 5.5.5.5 ebgp-multihop 2
neighbor 5.5.5.5 update-source Loopback0
neighbor 5.5.5.5 fall-over bfd multi-hop
#R5
bfd-template multi-hop BGP_MH
interval min-tx 750 min-rx 750 multiplier 3
!
bfd map ipv4 3.3.3.3/32 5.5.5.5/32 BGP_MH
!
router bgp 5
neighbor 3.3.3.3 remote-as 3
neighbor 3.3.3.3 ebgp-multihop 2
neighbor 3.3.3.3 update-source Loopback0
neighbor 3.3.3.3 fall-over bfd multi-hop
```
## Explanation
Let’s first examine the default behavior for the eBGP multi-hop session before configuring BFD. We’ll bring down Lo0 on R3:
```
#R3
int lo0
shut
```
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 \/mask \/mask \.
```
#R3
bfd-template multi-hop BGP_MH
interval min-tx 750 min-rx 750 multiplier 3
!
bfd map ipv4 5.5.5.5/32 3.3.3.3/32 BGP_MH
```
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).
## Verification
Now if we bring down Lo0 on R3, we should see that R5 brings down the eBGP session within just a few seconds.
```
#R3
int lo0
shut
```
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.
### Control bit
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:
```
router bgp 5
neighbor 3.3.3.3 fall-over bfd multi-hop check-control-plane-failure
```
This setting is also available for normal single-hop sessions.
### Strict-mode
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.
```
#R5
router bgp 5
neighbor 3.3.3.3 fall-over bfd multi-hop strict-mode
```
I have removed BFD from R3. When I clear bgp, and **debug ip bgp** on R5, I see the following debug message on R5:
```
#R5
BGP: ses global 3.3.3.3 (0x7F7CFCAF7AC0:0) pas Not send OPEN, BFD not up
```
R3 is now stuck in OpenSent.
---
# Agent Instructions: 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/bfd-multi-hop.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.