Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[MX] BFD timers explanation of "show bfd session" output

1

0

Article ID: KB36632 KB Last Updated: 31 Mar 2021Version: 1.0
Summary:

This article attempts to clear any confusion that may exist in the user understanding of the Bidirectional Forwarding Detection (BFD) timers that are seen in the show bfd session output, including transmit interval, detect time, and the multiplier value.

Symptoms:

How do we interpret transmit interval, detect time, and the multiplier BFD timer values that are seen in the show bfd session output?

Solution:

Consider the following topology where we run BFD for the client open shortest path first (OSPF) protocol. The BFD minimum-interval value and the multiplier value are configured to be the same on both ends. 

R1(ge-0/0/0)--------R2(ge-0/0/0)
lab@R1# set protocols ospf area 0 interface ge-0/0/0 bfd-liveness-detection minimum-interval 300 

[edit]
lab@R1# set protocols ospf area 0 interface ge-0/0/0 bfd-liveness-detection multiplier 3    

lab@R2# set protocols ospf area 0 interface ge-0/0/0 bfd-liveness-detection minimum-interval 300 

[edit]
lab@R2# set protocols ospf area 0 interface ge-0/0/0 bfd-liveness-detection multiplier 3 

lab@R1> show bfd session 
                                                  Detect   Transmit
Address           State     Interface      Time     Interval  Multiplier
10.1.1.2          Up        ge-0/0/0.0     0.900     0.300        3   >> Detect time = 300ms minimum-interval x 3 multiplier

1 sessions, 1 clients
Cumulative transmit rate 3.3 pps, cumulative receive rate 3.3 pps

lab@R2> show bfd session 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.1.1.1                 Up        ge-0/0/0.0     0.900     0.300        3   

1 sessions, 1 clients
Cumulative transmit rate 3.3 pps, cumulative receive rate 3.3 pps

If you change the timer and the multiplier on either end, the timers will get adjusted gracefully and the BFD session will not tear down.

Both devices can have different BFD timer values in which case they would agree to send BFD to each other by using the longer, that is the slower timer.

For instance, let's change the minimum-interval to 400 and the multiplier to 4 on R1 because R1 wants to receive the BFD packet a bit slower. R2 would therefore also change the transmit-interval value accordingly.

lab@R1# show | compare 
[edit protocols ospf area 0.0.0.0 interface ge-0/0/0.0 bfd-liveness-detection]
-      minimum-interval 300;
+      minimum-interval 400;
-      multiplier 3;
+      multiplier 4;

lab@R1> show bfd session    
Mar 15 01:20:49
                                                  Detect   Transmit
Address         State   Interface    Time     Interval  Multiplier
10.1.1.2        Up      ge-0/0/0.0   1.200     0.400        4   >>> Multiplier changed to 4; however, detect time shows 1.200 

1 sessions, 1 clients
Cumulative transmit rate 2.5 pps, cumulative receive rate 2.5 pps

lab@R2> show bfd session detail    
Mar 15 01:20:54
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.1.1.1                 Up        ge-0/0/0.0     1.600     0.400        3   
 Client OSPF realm ospf-v2 Area 0.0.0.0, TX interval 0.300, RX interval 0.300
 Session up time 00:06:03
 Local diagnostic None, remote diagnostic None
 Remote state Up, version 1
 Session type: Single hop BFD

1 sessions, 1 clients
Cumulative transmit rate 2.5 pps, cumulative receive rate 2.5 pps

On R1, we see that the hold timer changed to 1.200; that is, 400ms x 3. This is because R2 indicates to R1 to send BFD packets with a multiplier of 3, which makes R1 wait for 1200ms before it declares an adjacency down. Similarly, R1 indicates to R2 to use a multiplier of 4, which makes R2 wait for 1600ms before it tears things down.

There might be some confusion upon seeing the output on R1 where it shows multiplier 4, whereas the detect time is 1200ms instead of 1600ms. This is because the multiplier value seen is not what it is using, it is the multiplier it is sending.

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search