Bidirectional Forwarding Detection (BFD)

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!


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

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.


Hello, everyone!

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

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.

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?

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

Thank you in advance for your help.


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!


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!