Hello Durga
I’m not sure I understand your question. The state of BFD neighbours is shown with the show bfd neighors command. Initially when BFD is not configured, this information is not available. As soon as it is configured, based on the neighbour adjacency, the state will be Up, as shown in the lesson. When the adjacency fails, it will go down.
I’m not sure I’ve answered your question, but if not, feel free to clarify!
I hope this has been helpful!
Laz
Hi,
When BFD tracking OSPF neighbor goes down, OSPF will be stuck in which state? (Down or Init)
eg : [R1]–[Switch]—[R2]
If R1 interface to switch goes down, in which state OSPF will be stuck in both routers?
And also once the interface is down, If my bfd configuration is “bfd interval 300 min_rx 300 multiplier 3”, how much time it will take for BFD to come down - 300 secs ? & how much time it will take for OSPF to come down?
Regards,
Siji
Hello Siji
The states that OSPF routers go through are the steps that are taken to create a neighbour adjacency. If BFD tracking detects that a neighbour is down, this means that the adjacency is removed completely. So, the state would be Down, which means no OSPF neighbours are detected at this moment.
Take a look at this lesson for more details about states if you like.
Now if you issue the following command: bfd interval 300 min_rx 300 multiplier it should take 0.9 seconds for OSPF to come down. The values here are in milliseconds. The multiplier tells the router that if BDF packets are not received in 3 times the minimum receive interval, which is 900 milliseconds, or 0.9 seconds.
I hope this has been helpful!
Laz
Hello Networklesson
What about if I have a link that is flapping? BFD will detect it and OSPF will remove and establish a neighbor relation repeating this process many times. Is there a mechanism to avoid lose the neighbor relation in a flapping network?
Hello Rodrigo
Yes, there is a feature called BFD Dampening which can be used to introduce a delay mechanism to suppress the excessive notifications to BFD clients creating a more stable network.
You can find out more about this feature at the following link:
I hope this has been helpful!
Laz
Hello all,
With BFD, we only get quicker reconvergence when a link fails, right?
When it recovers, does BFD take any action to speed reconvergence again? I’m assuming it will need to wait for the OSPF normal adjacency process.
Thanks,
LP
Hello Luis
This is an excellent question. I did some research, and I had to actually go into RFC 5880 which describes BFD in order to get any solid answer.
As you suspected, BFD’s strong point is detecting a failure and letting the routing protocol know in an extremely small amount of time, that an alternate path must be found. When the failed link comes back up, BFD doesn’t have any specific mechanisms to speed up reconvergence. The RFC does state that:
BFD can be abstracted as a simple service. The service primitives
provided by BFD are to create, destroy, and modify a session, given
the destination address and other parameters. BFD in return provides
a signal to its clients indicating when the BFD session goes up or
down.
So BFD does indicate when a session goes up, but not at super speeds. In actuality, a BFD session over a particular link will only form after a routing protocol adjacency is formed over that link. So yes, you will need to wait for the OSPF normal process for reconvergence.
This makes sense however, since the recovery of a failed link and the reconvergence time required for any routing protocol will not result in a period of time of loss of connectivity. It is only during a failure that loss of connectivity occurs, and thus a fast reconvergence is necessary.
This is clearly seen when examining the BFD state machine on page 17 of the RFC. This shows how from an UP state BFD reaches a down state, which is the situation in which fast detection is necessary. In order to reestablish a BFD peering, the state machine simply goes through the same initial procedure of establishment going to the INIT state and the UP state, which is not exceptionally fast, AND which requires a routing protocol adjacency to form over that link first as a prerequisite.
I hope this has been helpful!
Laz
It makes sense.
Thanks, Laz.
Regarding the BFD, we have “interval” and “min_rx”. To which timer is “multiplier” associated with?
Hello Aashish
When configuring BFD, you configure two timer intervals. The interval, which is how often the local device will send BFD packets, and the min_rx interval which is how often we expect to receive a BFD packet from the neighbor. So the frequency with which BFD packets are sent can be different for each direction.
For example, for a topology with R1 and R2, we can have the following configuration:
R1 interval 50
R1 min_rx 100
R2 interval 100
R2 min_rx 50
The interval on the local device should correspond with the min_rx on the remote device.
Now when min_rx = interval, then you have the same intervals for both directions, therefore what the multiplier is applied to isn’t readily understandable. But if these values are different, then the multiplier becomes more significant.
According to RFC 5880 the multiplier is applied to the min_rx value, because it determines if the neighbor is down or not, and this depends upon the expected frequency of BFD packets received from that neighbor, which is defined by min_rx.
Actually, these detection times can be negotiated according to the RFC, and according to Cisco’s relevant documentation once the routing protocol has been enabled to use BFD. In such a case, as stated in the RFC:
…the Detection Time calculated in the local system is equal to the value of the multiplier received from the remote system, multiplied by the agreed transmit interval of the remote system… The multiplier value is roughly the number of packets that have to be missed in a row to declare the session to be down.
So beyond the statically assigned values for BFD, once the routing protocol is up and running, these values seem to be renegotiated between the neighbours.
I hope this has been helpful!
Laz
Hello Laz,
I configured ospf protocol on both routers keeping switch in the middle of those routers. I have not touched switch at all.
On R1 & R2 configuration be like:
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
bfd all-interfaces
!
bfd interval 50 min_rx 50 multiplier 3
no mop enabled
no mop sysid
!
BFD Verification commands are not giving any output at all:
sh bfd neighbors -> no output
sh neighbors details -> no output
Kind Regards,
Jimmy
Hello Jimmy
Your configs look correct. The first thing I would suggest is that you get rid of the switch and connect the devices directly. Test OSPF neighbor adjacencies, network connectivity, and routing tables and make sure everything is as it should be. Next, test BFD information using the show commands you shared above. If you still see nothing, then you must troubleshoot the OSPF and BFD configuration.
If everything works, then put the switch back in between the two routers and see the results.
I hope this has been helpful!
Laz
Hello Sirs!
I have a router model 2900 series when I go to on it’s interface Gigabit-Ethernet 0/2, by typing the BFD command it is not working , would you please tell me the reason?
Thanks advance for the help.
Regards
Ajmal
Hello Ajmal
Take a look at Cisco’s Feature Navigator to determine if your platform and IOS combination support BFD. From the looks of it, the specific one you have doesn’t support it.
I hope this has been helpful!
Laz
Thank you Sir!
Regards
Ajmal
Hi Laz,
Have one more question in continuation to BFD.
In the output show bfd neighbors details, we see the following:
Holddown (hits): 0(0), Hello (hits): 1000(617)
How do we read this information?
Does Holddown (hits): 0(0) mean that there has not been a single incidence of Holddown timer triggering (first 0) and there has been no Holddown hits?
Similar is for Hello (hits): 1000 (617) - Does this mean that Hello interval has been set to 1000 ms and we have received 617 Hello packets?
Though in the configuration, you have set the values to 50, 50, 3, why is the output showing 1000?
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Received MinRxInt: 1000000, Received Multiplier: 3
Thanks,
Aashish
I’m looking for a configuration example for configuring BFD on IOS-XE Software.
Thank you…
Hello Aashish
BFD uses various timers in various modes, and it seems that the names used, and the way they are indicated in the output of this command is not clear.
If you take a look at the config of BFD in the running config you’ll find something like the following:
R1#show run all | incl bfd
bfd slow-timers 1000
bfd l2cos 0
bfd interval 50 min_rx 50 multiplier 3
bfd echo
bfd all-interfaces
If you take a Wireshark capture of a BFD message, like this one, you will see the various timers in there, including the following: Echo interval, and Detect Time Multiplier as shown below:
So with the bfd interval 50 min_rx 50 multiplier 3 command, what you are actually configuring is the Detect Time Multiplier and the Echo Interval. The min_rx value that you configure in the command is not included in the BFD control message simply because it is the amount of time within which a router expects to receive a BFD message from the neighbor, something that is not actually included as information in the captured BFD control message. These configuration parameters have to do with the echo packets, not the control packets.
Conversely, in the output the values of MinTxInt and MinRxInt remain at 1000ms which refers to the slow-timers parameter in the router config.
The holddown timer is actually something completely different than what has been described in the lesson. Rene calls the multiplier the holddown timer (which colloquially speaking is correct), but officially in the RFC the result of applying the multiplier gives you the Detection Time. The holddown timer is something completely different. You can find out more about the holddown timer at Appendix A of RFC 5880.
Yes, this is correct. The slow-timer is set to 1000ms and there have been 617 control packets exchanged.
This is an example of how vendors sometimes use their own terminology to name values and variables that are different from the official RFC, and this can create confusion. For example, the RFC never mentions that BFD uses hello packets. It refers to BFD messages as control packets and echo packets. Cisco calls the MinTxInterval the slow-timers variable… It gets confusing… 
In any case, Rene mentioned that he will rewrite this lesson to more clearly describe the process to avoid confusion in the future.
I hope this has been helpful!
Laz
Hello John
For the most part, you will find that configuration of BFD for IOS-XE is the same as that for IOS. Take a look at the following lesson:
If you take a look at the following Cisco documentation about BFD for IOS-XE you will find that the commands are the same:
I hope this has been helpful!
Laz