HSRP BFD Peering

HSRP BFD Peering combines Hot Standby Router Protocol (HSRP) with Bidirectional Forwarding Detection (BFD) to reduce gateway failover time. By default, HSRP detects a peer failure only after the hold timer expires, which can take a couple of seconds. BFD allows sub-second detection and notifies HSRP immediately when the router on the other end becomes unreachable.

You might wonder whether simply tuning HSRP millisecond timers achieves the same result. It doesn’t. HSRP runs as a software process, and if you use sub-second hello intervals, your CPU load increases. There’s a chance you get false positives when your CPU load is high. BFD was designed to prevent this issue. It’s fast, and on many platforms it runs in hardware, so it doesn’t increase CPU load.

In this lesson, we’ll configure HSRPv2 with BFD on two Cisco Catalyst 8000V routers. You’ll learn how to configure and verify it, and we’ll also look at a debug so you can see it in action.

Key Takeaways

• HSRP BFD peering replaces the default hold-timer-based failure detection with sub-second BFD echo detection, so a peer failure triggers an immediate HSRP state change rather than waiting for the hold timer to expire.
• BFD must be configured in two parts on each router:
  • The echo parameters on the interface with bfd interval 200 min_rx 200 multiplier 3
  • The HSRP-to-BFD registration with standby bfd (per interface) or standby bfd all-interfaces (globally).
• A single BFD session between two routers covers all HSRP groups configured on that interface pair, so adding more groups later doesn’t create additional BFD sessions.
• With interval 200 and multiplier 3, BFD declares a failure after 600 ms of missed echo packets.
• Confirm HSRP has registered as a BFD client by checking for BFD enabled in show standby output and for a Session Count of 1 under HSRP in show bfd clients.
• Use show bfd neighbors details to verify the session is using the echo function at the correct interval and that Registered protocols lists both HSRP and CEF, confirming that both the gateway failover path and the forwarding plane are tied to the BFD session.
• To properly test failover, simulate a silent failure with an ACL instead of shutting down the interface. A shutdown triggers a graceful HSRP Resign packet, which has nothing to do with BFD.

Prerequisites

To follow this lesson, you need to understand HSRP active/standby elections, virtual IP addresses, and hold timers. Start with the HSRP basic configuration. You should also understand BFD (Bidirectional Forwarding Detection) as a sub-second failure-detection mechanism.

Configuration

Here is the topology we’ll use:

This is the same topology I used for most HSRP lessons. R1 and R2 run HSRP on the segment that connects to H1. R1 is the HSRP Active router, and R2 is the Standby. We only need R1 and R2 to test BFD for HSRP, but this topology allows you to send traffic from a host (H1) to a remote device (R3) so you can see it in action.

Both R1 and R2 are Cisco Catalyst 8000V instances running IOS XE 17.13.1a. SW1 is an IOL Layer 2 device.

HSRP BFD Topology

hostname R1
!
interface GigabitEthernet2
 ip address 192.168.12.1 255.255.255.0
 standby 1 ip 192.168.12.254
 standby 1 priority 150
 standby 1 name HSRP_GATEWAY
!
interface GigabitEthernet3
 ip address 192.168.123.1 255.255.255.0
!
router ospf 1
 router-id 1.1.1.1
 passive-interface GigabitEthernet2
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
end

hostname R2
!
interface GigabitEthernet2
 ip address 192.168.12.2 255.255.255.0
 standby 1 ip 192.168.12.254
 standby 1 name HSRP_GATEWAY
!
interface GigabitEthernet3
 ip address 192.168.123.2 255.255.255.0
!
router ospf 1
 router-id 2.2.2.2
 passive-interface GigabitEthernet2
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
ip access-list extended BLOCK_R1
 10 deny ip host 192.168.12.1 any
 20 permit ip any any
!
end

hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface GigabitEthernet2
 ip address 192.168.123.3 255.255.255.0
!
router ospf 1
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.123.0 0.0.0.255 area 0
!
end

hostname H1
!
interface GigabitEthernet2
 ip address 192.168.12.100 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.12.254
!
end

We’ll configure BFD first, starting with R1. There are two things to configure:

• Configure BFD on the interface.
• Combine BFD with HSRP.

Here’s how to do it:

R1(config)#interface GigabitEthernet2
R1(config-if)# bfd interval 200 min_rx 200 multiplier 3
R1(config-if)# standby bfd
R1(config-if)# exit

R2(config)#interface GigabitEthernet2
R2(config-if)# bfd interval 200 min_rx 200 multiplier 3
R2(config-if)# standby bfd
R2(config-if)# exit

Let me explain what we have here:

• bfd interval 200 min_rx 200 multiplier 3 configures BFD on GigabitEthernet2. R1 and R2 send echo packets every 200 ms and expect to receive them every 200 ms. A failure is declared after 3 consecutive missed packets, giving a detection time of 600 ms. That’s much faster than the 10-second HSRP hold time and enough for a lab like this.
• standby bfd tells HSRP to register itself as a BFD client on this interface. Once registered, a BFD down notification triggers an immediate HSRP state change rather than waiting for the hold timer. HSRP continues sending its own hello packets at the configured 3 second hello interval. BFD runs in parallel with the HSRP hello exchange, not instead of it. It’s not a replacement.

A single BFD session between two routers serves all HSRP groups configured on both routers. If you later add group 2 or group 3 on the same interface pair, they all share the same BFD session instead of each creating their own. This scales well because you have one lightweight BFD session for all HSRP groups.

The BFD parameters should match on both peers. If R1 advertises a minimum receive interval of 200 ms and R2 advertises 200 ms, they negotiate 200 ms echo intervals in both directions. A mismatch won’t prevent the session from forming, but it will affect the negotiated detection time.

Verification

Everything is in place, so let’s verify our work. We’ll look at both BFD and HSRP.

BFD

Let’s check how many BFD sessions exist and how many are up versus down:

R1# show bfd summary
                    Session          Up          Down

Total                     1           1             0

R2# show bfd summary
                    Session          Up          Down

Total                     1           1             0

Both routers report exactly 1 BFD session, and that session is up with 0 sessions down. This confirms that the BFD echo exchange between R1 and R2 is working correctly. Let’s check our BFD neighbors:

R1# show bfd neighbors

IPv4 Sessions
NeighAddr                              LD/RD         RH/RS     State     Int
192.168.12.2                         4098/4098       Up        Up        Gi2

R2# show bfd neighbors

IPv4 Sessions
NeighAddr                              LD/RD         RH/RS     State     Int
192.168.12.1                         4098/4098       Up        Up        Gi2

R1 sees R2 (192.168.12.2) as a BFD neighbor on Gi2 with state up. R2 sees R1 (192.168.12.1) as a BFD neighbor on Gi2 with state up. The RH/RS column shows Up, meaning the remote router’s BFD session is fully established. The local discriminator (LD) and remote discriminator (RD) are both 4098, confirming the session identifiers have been negotiated and matched.

We can take a more detailed look at our neighbors:

R1# show bfd neighbors details

IPv4 Sessions
NeighAddr                              LD/RD         RH/RS     State     Int
192.168.12.2                         4098/4098       Up        Up        Gi2
Session state is UP and using echo function with 200 ms interval.
Session Host: Software
OurAddr: 192.168.12.1   
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(71)
Rx Count: 72, Rx Interval (ms) min/max/avg: 2/996/868 last: 536 ms ago
Tx Count: 73, Tx Interval (ms) min/max/avg: 2/993/855 last: 623 ms ago
Echo Rx Count: 350, Echo Rx Interval (ms) min/max/avg: 152/209/177 last: 100 ms ago
Echo Tx Count: 350, Echo Tx Interval (ms) min/max/avg: 152/209/177 last: 102 ms ago
Elapsed time watermarks: 0 0 (last: 0)
Registered protocols: HSRP CEF
Uptime: 00:01:02
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.: 4098             - Your Discr.: 4098
             Min tx interval: 1000000    - Min rx interval: 1000000
             Min Echo interval: 200000  

R2# show bfd neighbors details

IPv4 Sessions
NeighAddr                              LD/RD         RH/RS     State     Int
192.168.12.1                         4098/4098       Up        Up        Gi2
Session state is UP and using echo function with 200 ms interval.
Session Host: Software
OurAddr: 192.168.12.2   
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(70)
Rx Count: 74, Rx Interval (ms) min/max/avg: 1/993/843 last: 732 ms ago
Tx Count: 72, Tx Interval (ms) min/max/avg: 2/996/868 last: 646 ms ago
Echo Rx Count: 354, Echo Rx Interval (ms) min/max/avg: 152/211/175 last: 147 ms ago
Echo Tx Count: 354, Echo Tx Interval (ms) min/max/avg: 152/201/175 last: 147 ms ago
Elapsed time watermarks: 0 0 (last: 0)
Registered protocols: HSRP CEF
Uptime: 00:01:02
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.: 4098             - Your Discr.: 4098
             Min tx interval: 1000000    - Min rx interval: 1000000
             Min Echo interval: 200000  

There is quite some information here. We can see that the session is UP and that we use a 200 ms interval. This output also tells us that HSRP has registered as a client of this BFD session. When this BFD session goes down, BFD immediately notifies both HSRP and CEF.

The last command tells us which protocols have registered as BFD clients on this router, along with how many BFD sessions each protocol owns:

R1# show bfd clients
Client        ClientID     Subtype      Session Count
VRRPv3        23          0           0         
FRR           7           0           0         
CEF           15          0           1         
PIM           22          0           0         
RG Protocol   18          0           0         
OSPF          10          0           0         
IPv4 Static   12          0           0         
RIP           20          0           0         
OSPFv3        11          0           0         
Xconnect      17          0           0         
HSRP          8           0           1         

R2# show bfd clients
Client        ClientID     Subtype      Session Count
VRRPv3        23          0           0         
FRR           7           0           0         
CEF           15          0           1         
PIM           22          0           0         
RG Protocol   18          0           0         
OSPF          10          0           0         
IPv4 Static   12          0           0         
RIP           20          0           0         
OSPFv3        11          0           0         
Xconnect      17          0           0         
HSRP          8           0           1         

HSRP shows a session count of 1 on both routers. All other protocols show 0 because we haven’t configured BFD for them. This confirms HSRP is a properly registered BFD client with an active session.

HSRP

Now let’s look at HSRP. The show standby command shows whether BFD is enabled or not: