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 🙂 ).