Bidirectional Forwarding Detection (BFD)

what does control packet contain in regards to BFD-link failure detection.

Hello Vijay

Take a look at the BFD lesson which explains some of the logic behind the control packets in BFD:

You can also take a look at the detailed structure of the control packets as they are described by the RFC defining BFD at the link below.

https://tools.ietf.org/html/rfc5880#page-7

I hope this has been helpful!

Laz

Hiii Rene & Laz…

can u explain below bfd config.

!
bfd-template single-hop FIBRE
interval microseconds min-tx 50000 min-rx 50000 multiplier 3
!
bfd template FIBRE
isis bfd

Hello Varma

Take a look at this Cisco documentation:

Here you will see that the configuration enters BFD configuration mode for single-hop BFD sessions. This is created for devices that are directly connected. The interval command configures the intervals used for the particular BFD session.

More details about how to create BFD templates and what they actually do can be found at the following link:

I hope this has been helpful!

Laz

hey, need help to understand this,

 bfd interval 50 min_rx 50 multiplier 3
 bfd echo
 bfd all-interfaces

with bfd echo being used, would it be control packets or echo used to monitor the peer status? bfd neigh would go down if it doesn’t hear frm its neigh within 150ms the control packets or echo or both? thanks

Hello Wei Ping

When the echo mode feature is enabled, both control packets and echo packets are sent out at the same time. However, the echo function allows for a reduction in the number of BFD control packets. So yes, both control packets and echo packets are sent out. As stated in the Cisco documentation linked below:

“The echo function and the forwarding engine are responsible for the detection process, therefore the number of BFD control packets that are sent out between two BFD neighbors is reduced.”

A detailed description of this operation can be found at the following Cisco documentation:

I hope this has been helpful!

Laz

Really good article that could come in handy without changing around things.

1 Like

I’m curious to know if anyone has tested this. I have a ebgp peering session with a provider. I’m looking to temporarily remove the BFD configuration. I was wondering if I remove the BFD configuration without notifying the provider will their router eventually detect that there are some missed BFD packets and therefore tear down the BFD session and also the ebgp adjacency? I tested this out in CML 2.0 but the ebgp adjacency did not go down…only the bfd session was torn down. In the past I have ran into some strange scenarios where I test a use case in CML and the behavior is different in production. If anyone has tested this please let me know. Thanks.

Hello VJnetwork

I labbed this up too, to do some more experimentation, and I have replicated your results. It seems that when you remove the BFD configuration, either by removing the bfd interval command from the interface or by removing the neighbor fall-over bfd command from the BGP configuration, the BGP peering and the resulting routing remains intact.

Now I notice the following. When I disable BFD using one of those methods, I take a look at the syslogs on the other router and I see this:

*Oct  7 06:24:00.698: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: RX ADMINDOWN

However, if I shut down the interface instead, the syslog on the other router displays the following:

*Oct  7 06:29:50.303: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: ECHO FAILURE
*Oct  7 06:29:50.309: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:1 neigh proc:BGP, handle:1 act

Notice in the first case, the reason code is RX ADMINDOWN while in the second case, the reason is ECHO FAILURE. We also get an additional syslog in the second case that states that the BFD session is destroyed, something we don’t see in the first case.

From this info, we can conclude that when you disable BFD, the router informs the BFD neighbor that the action taken was an administrative action, and does not constitute a failure. When the interface is shutdown, that is detected as an echo failure, which is interpreted as a failure on the link, so the BGP session fails too.

(Note that the BGP session, in this case, will fail anyway because the interface goes down, but the exercise does demonstrate how BFD handles an administrative change compared to a real network failure.)

Thus, BFD configurations can be safely removed without the fear of causing a failure or a disruption on a production network.

I hope this has been helpful!

Laz

Hi,
Thanks for the good lesson. I was able to get BFD running correctly in lab. Is there a best practice timer interval value to use when setting up BFD with an ISP?

Hello Troy

In general, the smaller the interval the better. There are no detrimental effects to using the lowest possible interval when applying BFD.

I hope this has been helpful!

Laz

HI

How can I configure an IP event dampening on an interface?

Thank you

Hello Giovanni

IP Event dampening is a feature that allows you to configure an exponential decay mechanism to suppress the effects of excessive interface flapping events on routing protocols and routing tables in a network.

For more detailed information about this feature and how to configure it, take a look at this Cisco documentation:

I hope this has been helpful!

Laz

Hello,
In my opinion, BFD is indeed more efficient than hello packets in OSPF or EIGRP.
But when would we use it?
If link failures are sometimes judged simply because of delays or packet loss.
Does it mean that the routing protocol will always converge due to network status?

Hello TE-EN LIN

BFD should be used wherever super-fast convergence times are necessary. This would definitely be the case at the core of an enterprise network, where even a delay of a few seconds will affect hundreds or even thousands of users. Also, you would want it configured on any network that uses applications that are sensitive to short outages. You wouldn’t care much for email or web users, but for VoIP telephony and videoconferencing, it may cause disruptions that require users to reconnect from scratch, which is not very good. Does that make sense?

I hope this has been helpful!

Laz

Hi,
I have 2 questions related BFD configuration in IOS XR platform.

  1. As BFD is bidirectional protocol, so they need to configured in both side. But with one-arm-echo we can configure only in 1 device which support BFD. as I know this is IEEE standard. How to configure this protocol in IOS XR platform ?

  2. Other vendor they have static BFD for track and binding to static route.
    like below :

bfd for_XXX bind peer-ip 10.10.10.1 vpn-instance OM source-ip 192.168.20.53
 discriminator local 106
 discriminator remote 206
 detect-multiplier 7
 min-tx-interval 200
 min-rx-interval 200

ip route-static vpn-instance OM  X.X.X.X X.X.X.X 192.168.20.54 track bfd-session for_XXX

with this configuration we can control what number discriminator on both side.

is Cisco XR support this features ?

Thank you

Hello Giarto

Indeed BFD one-arm echo is defined by the IEEE standard and doesn’t require both ends of a link to support BFD. It seems that Cisco doesn’t support this feature. I say “it seems” because I have been unable to find it stated explicitly. However, Cisco documentation does state the following about BFD:

Cisco supports the BFD asynchronous mode, in which two routers exchange BFD control packets to activate and maintain BFD neighbor sessions. To create a BFD session, you must configure BFD on both systems (or BFD peers).

This seems to indicate that both ends of the link must support BFD, thus we can come to the conclusion that one-arm echo is not supported.

Cisco supports this feature as well, and you can find out how to apply it at the following Cisco documentation:

I hope this has been helpful!

Laz

Hello Rene,

Hope you are well.

I was testing the below scenario in LAB and faced this issue:

SW Product: ASR9K-x64-iosxr-px-7.3.2.tar
HW Product: ASR-9910

The issue appears when we create multiple static routes with different BFD intervals for the same next hop in a single commit. It throws an error; however, the configuration is committed.
If we create them in two different commits, then 2nd commit should fail and it’s failing as expected.

RP/0/RSP0/CPU0:RCPXY90321#conf t
RP/0/RSP0/CPU0:RCPXY90321(config)#router static
RP/0/RSP0/CPU0:RCPXY90321(config-static)# vrf CUSTNET
RP/0/RSP0/CPU0:RCPXY90321(config-static-vrf)#  address-family ipv4 unicast
RP/0/RSP0/CPU0:RCPXY90321(config-static-vrf-afi)#   10.3.216.113/32 10.3.216.108 bfd fast-detect minimum-interval 1000 multiplier 4 description PXY9-SCM-TEST-0001,VLAN757
RP/0/RSP0/CPU0:RCPXY90321(config-static-vrf-afi)#   10.3.216.114/32 10.3.216.108 bfd fast-detect minimum-interval 300 multiplier 3 description PXY9-SCM-TEST-0001,VLAN757
RP/0/RSP0/CPU0:RCPXY90321(config-static-vrf-afi)#  !
RP/0/RSP0/CPU0:RCPXY90321(config-static-vrf-afi)# !
RP/0/RSP0/CPU0:RCPXY90321(config-static-vrf-afi)#!
RP/0/RSP0/CPU0:RCPXY90321(config-static-vrf-afi)#root
RP/0/RSP0/CPU0:RCPXY90321(config)#sh com ch diff
Fri Jun 23 00:35:08.391 AEST
Building configuration...
!! IOS XR Configuration 7.3.2
   router static
    vrf CUSTNET
     address-family ipv4 unicast
+     10.3.216.113/32 10.3.216.108 bfd fast-detect minimum-interval 1000 multiplier 4 description PXY9-SCM-TEST-0001,VLAN757
+     10.3.216.114/32 10.3.216.108 bfd fast-detect minimum-interval 300 multiplier 3 description PXY9-SCM-TEST-0001,VLAN757
     !
    !
   !
end
RP/0/RSP0/CPU0:RCPXY90321(config)#
RP/0/RSP0/CPU0:RCPXY90321(config)#commit label post_3784517_SR_1_20230622
EndFri Jun 23 00:35:23.745 AEST
 
% Failed to commit one or more configuration items. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RSP0/CPU0:RCPXY90321(config)#  
RP/0/RSP0/CPU0:RCPXY90321(config)#sh configuration failed
Fri Jun 23 00:35:40.253 AEST
!! APPLY ERRORS: This configuration was accepted by the system,
!! but errors occurred when the system attempted to make the
!! configuration operational. The individual errors for each
!! failed configuration command can be found below. These errors
!! will cause an inconsistency between the system's running
!! configuration and its operational state, which may be addressed
!! by using the 'no' form of the command to remove it from the
!! running configuration.
 
 
router static
vrf CUSTNET
  address-family ipv4 unicast
   10.3.216.114/32 10.3.216.108 bfd fast-detect minimum-interval 300 multiplier 3 description PXY9-SCM-TEST-0001,VLAN757
!!% 'ip-static' detected the 'warning' condition 'Nexthop is already configured with different interval or multiplier or multihop'
  !
!
!
End
 
 
P/0/RSP0/CPU0:RCPXY90321#show running-config router static vrf CUSTNET address-family ipv4 unicast
Fri Jun 23 00:36:13.855 AEST
router static
vrf CUSTNET
  address-family ipv4 unicast
   10.3.216.113/32 10.3.216.108 bfd fast-detect minimum-interval 1000 multiplier 4 description PXY9-SCM-TEST-0001,VLAN757
   10.3.216.114/32 10.3.216.108 bfd fast-detect minimum-interval 300 multiplier 3 description PXY9-SCM-TEST-0001,VLAN757
  
  !
!
!
 
RP/0/RSP0/CPU0:RCPXY90321#sh configuration commit list 5
Fri Jun 23 00:37:54.348 AEST
SNo. Label/ID              User      Line                Client      Time Stamp
~~~~ ~~~~~~~~              ~~~~      ~~~~                ~~~~~~      ~~~~~~~~~~
1    post_3784517_SR_1_20  d950235   vty25:node0_RSP0_C  CLI         Fri Jun 23 00:35:23 2023
2    del_SR_230623003056   n113009   vty27:node0_RSP0_C  CLI         Fri Jun 23 00:31:01 2023
3    del_HSRP_20230623003  n113009   vty27:node0_RSP0_C  CLI         Fri Jun 23 00:30:46 2023
4    SR_230623001739       n113009   vty25:node0_RSP0_C  CLI         Fri Jun 23 00:17:43 2023
5    HSRP_757_20230623001  n113009   vty25:node0_RSP0_C  CLI         Fri Jun 23 00:16:59 2023
 
RP/0/RSP0/CPU0:RCPXY90321#sh configuration commit changes post_3784517_SR_1_20
Fri Jun 23 00:38:30.037 AEST
Building configuration...
!! IOS XR Configuration 7.3.2
router static
vrf CUSTNET
  address-family ipv4 unicast
   10.3.216.113/32 10.3.216.108 bfd fast-detect minimum-interval 1000 multiplier 4 description PXY9-SCM-TEST-0001,VLAN757
   10.3.216.114/32 10.3.216.108 bfd fast-detect minimum-interval 300 multiplier 3 description PXY9-SCM-TEST-0001,VLAN757
  !
!
!
End

Logs:
logs_Static route BFD issue.txt (1.1 MB)

show tech files:
untitled folder.zip (1.5 MB)

Thanks in Advance
Manami

Hello Manami

Cisco devices allow you to configure BFD at either a global level, or at an interface level. However, BFD configuration is generally linked with the interface and not with individual routes. Therefore, while you can create multiple static routes to the same next-hop IP, each with their own metrics, you would not typically configure different BFD intervals for each of those routes if they are using the same outgoing interface.

The ASR in your case is not “happy” with the different BFD intervals for two different routes that have the same next hop IP. This is seen in the error message below:

!!% 'ip-static' detected the 'warning' condition 'Nexthop is already configured with different interval or multiplier or multihop'

Although the commands were accepted, the error message does state that the running config and the operational state will indeed be inconsistent. So whether you commit them together or separately, the operational state will remain the same, the error messages are simply different.

I hope this has been helpful!

Laz

To implement diverse BFD intervals for the same next-hop IP, you’d likely need to utilize different outgoing interfaces, each configured with its respective BFD interval.

In any case, it’s important to consider that setting a different BFD interval per route to the same next hop might not be the best practice due to additional complexities and potential for configuration errors. It’s generally more advisable to apply a uniform BFD configuration to all routes to the same next hop, thereby simplifying troubleshooting and network operations.

Hi Laz,

Thank you for your response.

For below scenario, where DC-GW1 is the ASR9K using BE10 to reach Telco Cloud A.
Can we have setup here in this topology we can create two outgoing interface to create two different static route with different BFD minimal-interval value to reach Telco Cloud A?

Thanks in Advance
Manami