Bidirectional Forwarding Detection (BFD)

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

Hi @ccnp.manami ,

As @lagapidis mentioned, the way BFD works is that you configure this on an interface level. Static routes, or routing protocols like OSPF, EIGRP, BGP, and IS-IS can use BFD for faster failover.

You would configure BFD once for your BE10 interface. If you have another interface between DC-GW1 and the Telco, you can configure BFD for this interface as well.

For these two interfaces, you can use different BFD intervals if needed.

Rene

Hello, everyone!

I have this network here
obrázok
I’ve issued the following commands on R1 and R2
obrázok
obrázok

Doesn’t this basically mean that the routers should send BFD packets every 9.9 seconds, expect packets every 9.9 seconds and tear down the neighborship after 29.7 seconds?

If so, for some reason, this isn’t working as intended. The routers are constantly sending BFD messages between eachother way more often than just 9.9 seconds.

obrázok
Why does it state here that the Detection Time is 5000ms and the Min TX and RX intervals are 1000 ms?

Also please, what exactly is this message?
obrázok

Is anyone else running into the same problem as I am?

Thank you in advance for your help.

David

Hello David

Hmm that is strange. The first thing I’d like to address is the fact that in the Wireshark capture, your multiplier is 5, and your Tx and Rx intervals are set to 1000 ms, and the Echo Interval is 9000 ms. Those values are different from what you set up in the two routers.

I don’t have an answer for your concerning why these are different, however, I do have some information bout how BFD operates that may shed some light on the discrepancies seen. First of all, looking at RFC 5880 that describes BFD, we see that:

  • Timers are negotiated - BFD will negotiate timers based on what is supported. Now you put in a value of 9999 for the interval, and this appears as 9000 in the capture. It could be that the platform may accept such a value in the command, but may default to a maximum value that the platform supports. This may be IOS specific.
  • The control packets are the ones that would adhere to your interval and min_rx settings. In Echo Mode, however, BFD will send echo packets at a more frequent rate (usually on the order of milliseconds). The intention here is for these echo packets to be “echoed” back by the recipient. The missed echo packets don’t count against the multiplier, but it’s a means to verify the forwarding path without putting the additional load of control mode packet processing on the control plane.
  • When viewing the actual frequency of packets sent, the RFC says that it will differ from the set values by up to 25% based on jitter values and on a level of randomness introduced into the control packets to prevent self-syncrhonization.
  • The RFC also states that some of the timers must be initialized to 1 second (i.e. 1000 ms) before being changed and negotiated.

I suggest you take a look at the configuration of your routers using the show bfd neighbors details command to see what values are actually negotiated and used. Once that’s done, take a look at the steam of BFD packets several dozen seconds into the exchange to see if the values of these timers have changed, and to see if the frequency of their transmission has steadied. Please take a look at these and let us know what you find.

I hope this has been helpful!

Laz

Hi @ReneMolenaar,

Is it mandatory that we need to enable BFD on interfaces along with any protocol.
For example, can i don’t enable BFD on interfaces and just enable under BGP neighbors’ statement?

Hello Annapurna

The configuration of BFD parameters on the interface as well as on the routing protocol are necessary in order for BFD to function correctly.

The BFD configuration on the interfaces is not linked with any particular routing protocol. By issuing the bfd command on the interface, you are simply starting the BFD process, and you are setting the parameters (interval, min_rx, multiplier etc) with which BFD will communicate with the BFD entity on the other end of the link.

Once the BFD process is up and running, there are no entries created in the adjacency database yet, and no BFD control packets are sent or received yet. The adjacency creation takes place only when you configure BFD support for a particular routing protocol. That’s the bfd all-interfaces command in the OSPF router mode configuration or the neighbor fall-over bfd command for BGP.

If you’re running multiple routing protocols on a router, you can enable BFD for multiple routing protocols, and they’ll use the same BFD configuration parameters as they are set out in on the interface configuration.

So in summary, the BFD interface configuration is a generic configuration (regardless of the routing protocol) that simply enables the BFD process and sets the communication parameters that will be used with the BFD entity on the other end. The routing protocol configuration for BFD enables the operation of BFD for the specific routing protocol, and it will use the parameters set on the interfaces in question to perform the BFD mechanisms.

I hope this has been helpful!

Laz