GNS3-LAB Cisco : Bi-directional Forwarding Detection(BFD) Single-Hop and Multi-Hop

Detecting failure faster is the key for any network these days. Especially all the service providers thriving to offer zero packet loss network to their customer always look for the solutions which can detect failure as quickly as possible.Our traditional protocols were designed decodes ago, at that time not everybody anticipated the kind of need of faster communication networks we have today. So the protocols take their time to detect and converge according to the failure. Hence the protocols like BFD become crucial to trigger faster convergence.

In this article I will be discussing BFD Single-hop and Multi-hop solution. I have done this lab on GNS3, following are the devices used.

Topology and Tool info:

Tool : GNS3 2.2.5
IOSv ROuter : IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.7(3)M3
CSR1000v: 16.9.1 

In the above diagram I have configired ISIS between all three routers. Single-hop BFD is running between R2 and R3 for ISIS neighborship. Multihop ISIS is running between R1 and R3 which are not directly connected, between R1 and R3 we have EBGP configured, here BFD is configured over BGP. Following are the configurations.

Single-Hop BFD configuration Example:

R2 CONFIGURATION: 
!
interface GigabitEthernet2
ip address 10.10.10.5 255.255.255.252
ip router isis CISCO
bfd template ONE-HOP-BFD
!
bfd-template single-hop ONE-HOP-BFD
  interval min-tx 1000 min-rx 1000 multiplier 3
!
router isis CISCO
  net 49.0000.0000.0000.0002.00
  bfd all-interfaces

R3 CONFIGURATION:
!
interface GigabitEthernet1
  ip address 10.10.10.6 255.255.255.252
  ip router isis CISCO
  bfd template ONE-HOP-BFD
!
bfd-template single-hop ONE-HOP-BFD
  interval min-tx 1000 min-rx 1000 multiplier 3
!
router isis CISCO
  net 49.0000.0000.0000.0003.00
  bfd all-interfaces

Verification for Single-Hop BFD :

R2#show isis  neighbors 
 Tag CISCO:
 System Id       Type Interface     IP Address      State Holdtime Circuit Id
 R3              L1L2 Gi2           10.10.10.6      UP    29       01
R2#show bfd neighbors details 
 IPv4 Sessions
 NeighAddr                              LD/RD         RH/RS     State     Int
 10.10.10.6                              1/1          Up        Up        Gi2
 Session state is UP and not using echo function.
 Session Host: Hardware
 OurAddr: 10.10.10.5     
 Handle: 2
 Local Diag: 0, Demand mode: 0, Poll bit: 0
 MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
 Received MinRxInt: 1000000, Received Multiplier: 3
 Holddown (hits): 0(0), Hello (hits): 1000(0)
 Rx Count: 833, Rx Interval (ms) min/max/avg: 593/1100/0
 Tx Count: 853, Tx Interval (ms) min/max/avg: 745/991/0
 Elapsed time watermarks: 0 0 (last: 0)
 Registered protocols: ISIS CEF 
 Template: ONE-HOP-BFD
 Uptime: 00:12:57
 Last packet: Version: 1                  - Diagnostic: 0
              State bit: Up               - Demand bit: 0
              Poll bit: 0                 - Final bit: 0
              C bit: 1                                   
              Multiplier: 3               - Length: 24
              My Discr.: 1                - Your Discr.: 1
              Min tx interval: 1000000    - Min rx interval: 1000000
              Min Echo interval: 0       

Outputs from R3 router :

R3#show isis neighbors 
 Tag CISCO:
 System Id       Type Interface     IP Address      State Holdtime Circuit Id
 R2              L1L2 Gi1           10.10.10.5      UP    25       02

 R3#sh bfd neighbors details 
 IPv4 Sessions
 NeighAddr                              LD/RD         RH/RS     State     Int
 10.10.10.5                              1/1          Up        Up        Gi1
 Session state is UP and not using echo function.
 Session Host: Hardware
 OurAddr: 10.10.10.6     
 Handle: 3
 Local Diag: 0, Demand mode: 0, Poll bit: 0
 MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
 Received MinRxInt: 1000000, Received Multiplier: 3
 Holddown (hits): 0(0), Hello (hits): 1000(0)
 Rx Count: 1005, Rx Interval (ms) min/max/avg: 692/1184/0
 Tx Count: 1005, Tx Interval (ms) min/max/avg: 745/996/0
 Elapsed time watermarks: 0 0 (last: 0)
 Registered protocols: ISIS CEF 
 Template: ONE-HOP-BFD
 Uptime: 00:15:36
 Last packet: Version: 1                  - Diagnostic: 0
              State bit: Up               - Demand bit: 0
              Poll bit: 0                 - Final bit: 0
              C bit: 1                                   
              Multiplier: 3               - Length: 24
              My Discr.: 1                - Your Discr.: 1
              Min tx interval: 1000000    - Min rx interval: 1000000
              Min Echo interval: 0       

Multi-Hop BFD Configuration Example:

Now moving to the multihop BFD configuration. The only difference between multihop BFD and single hop BFD is that in the multihop bfd we do not have directly connected neighbor and due to this reason we need to do some provision to tell the router about the BFD peer. We do it with the help of BFD maps. Following is the configuration example.

R1 CONFIGURATION:
!
interface GigabitEthernet0/0
  ip address 10.10.10.1 255.255.255.252
  ip router isis CISCO
!
 interface Loopback1
  ip address 1.1.1.1 255.255.255.255
  ip router isis CISCO
!
bfd map ipv4  3.3.3.3/32  1.1.1.1/32 BFD-MH
!
 bfd-template multi-hop BFD-MH
  interval min-tx 3000 min-rx 3000 multiplier 3
!
router isis CISCO
  net 49.0000.0000.0000.0001.00
!
router bgp 100
  bgp log-neighbor-changes
  neighbor 3.3.3.3 remote-as 200
  neighbor 3.3.3.3 ebgp-multihop 5
  neighbor 3.3.3.3 update-source Loopback1
  neighbor 3.3.3.3 fall-over bfd multi-hop
  neighbor 3.3.3.3 next-hop-self

R3 CONFIGURATION:
!
interface GigabitEthernet1
  ip address 10.10.10.6 255.255.255.252
  ip router isis CISCO
!
 interface Loopback1
  ip address 3.3.3.3 255.255.255.255
  ip router isis CISCO
!
bfd map ipv4  1.1.1.1/32  3.3.3.3/32 BFD-MH
!
bfd-template multi-hop BFD-MH
  interval min-tx 3000 min-rx 3000 multiplier 3
!
router isis CISCO
  net 49.0000.0000.0000.0003.00
!
router bgp 200
  bgp log-neighbor-changes
  neighbor 1.1.1.1 remote-as 100
  neighbor 1.1.1.1 ebgp-multihop 5
  neighbor 1.1.1.1 update-source Loopback1
  neighbor 1.1.1.1 fall-over bfd multi-hop
  neighbor 1.1.1.1 next-hop-self

Verification for Multi-Hop BFD:

R1#show ip bgp all summary 
 For address family: IPv4 Unicast
 BGP router identifier 1.1.1.1, local AS number 100
 BGP table version is 1, main routing table version 1
 Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
 3.3.3.3         4          200      49      49        1    0    0 00:41:27        0

R1#show bfd neighbors details 
 IPv4 Multihop Sessions
 NeighAddr[vrf]                                LD/RD         RH/RS     State
 3.3.3.3                                        1/4097       Up        Up       
 Session state is UP and not using echo function.
 Session Host: Software
 OurAddr: 1.1.1.1        
 Handle: 1
 Local Diag: 0, Demand mode: 0, Poll bit: 0
 MinTxInt: 3000000, MinRxInt: 3000000, Multiplier: 3
 Received MinRxInt: 3000000, Received Multiplier: 3
 Holddown (hits): 7513(0), Hello (hits): 3000(970)
 Rx Count: 958, Rx Interval (ms) min/max/avg: 2/2996/2600 last: 1487 ms ago
 Tx Count: 947, Tx Interval (ms) min/max/avg: 4/3004/2630 last: 988 ms ago
 Elapsed time watermarks: 0 0 (last: 0)
 Registered protocols: BGP 
 Map information:
  Destination[vrf]: 3.3.3.3/32
  Source[vrf]: 1.1.1.1/32
  Template: BFD-MH 
  Authentication(Type/Keychain): invalid_type/
 Uptime: 00:41:29
 Last packet: Version: 1                  - Diagnostic: 0
              State bit: Up               - Demand bit: 0
              Poll bit: 0                 - Final bit: 0
              C bit: 0                                   
              Multiplier: 3               - Length: 24
              My Discr.: 4097             - Your Discr.: 1
              Min tx interval: 3000000    - Min rx interval: 3000000
              Min Echo interval: 0       

Conclusion:

Although very handy but BFD failures are very common in network due to aggressive timers. BFD sessions are like first line of infantry soldiers and they fall first if anything wrong happens and their falling down tell everyone else that something wrong has been detected. I have seen other failure detection protocols but BFD seems to be most widely used and it has been proven totally worthy( True value to money 🙂 ).

Leave a Reply