On the surface Cisco’s HSRP and the IETF’s VRRP appear to be the same thing. They both provide IP next hop redundancy by using an election process to determine which router should host a virtual IP address. The router that wins the election will host the VIP and respond to ARP requests for the VIP. If something happens to the router hosting the VIP such as power loss or the interface going down, another participating router can take over to maintain client connectivity. Both protocols allow configuration of a priority value to determine which router wins the election and both have a tiebreaker if the priority is default. They both exist to solve the same problem but there are a few differences in how they operate.
To dig further into these protocols, I set up the simple topology shown below. My PC is connected to the switch to take packet captures. One convenience is that both protocols use link local multicast, so I didn’t have to configure SPAN. The only configuration on the switch is portfast to speed up convergence.
HSRP Configuration
I’ll start by sharing the configuration and “show standby” output. R3 is expected to be the standby router since preemption is configured and R3 has a lower priority than the default of 100.
RoutingLoop_R2#show run int g0/0
Building configuration…
Current configuration : 138 bytes
!
interface GigabitEthernet0/0
ip address 10.0.0.2 255.255.255.0
standby 1 ip 10.0.0.1
standby 1 preempt
duplex auto
speed auto
RoutingLoop_R3#show run int g0/0
Building configuration…
Current configuration : 161 bytes
!
interface GigabitEthernet0/0
ip address 10.0.0.3 255.255.255.0
standby 1 ip 10.0.0.1
standby 1 priority 90
standby 1 preempt
duplex auto
speed auto
RoutingLoop_R2#show standby
GigabitEthernet0/0 – Group 1
State is Active
2 state changes, last state change 00:00:58
Virtual IP address is 10.0.0.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.192 secs
Preemption enabled
Active router is local
Standby router is 10.0.0.3, priority 90 (expires in 9.312 sec)
Priority 100 (default 100)
Group name is “hsrp-Gi0/0-1” (default)
HSRP Packet Capture
Let’s start by examining the HSRP hello packets during steady state operation. The active and standby routers send hello packets based on the hello timer. In this demo I’m using the default of 3 seconds. In the hello packet the advertising router declares its HSRP state, timers, priority, group number and a few other attributes. I find it interesting that the standby router sends hello packets. I can’t think of anything to gain from this other than network operators being able to use “show” commands on the active router to see which router is standby. If the standby is receiving timely hello packets from the active router everything should work fine. Another notable item is the IP TTL value of 1. This makes enough sense since this is link-local multicast.
Hello packet exchange:
R2 hello packet details:
R3 hello packet details:
After observing the HSRP hello exchanges I shut down the physical interface on R2, the current active router. R2 quickly fired off a Resign message letting the standby router know it should immediately take over the active role. R3 immediately responds to the network with an Advertise message letting any other HSRP routers know that it is now active for group 1. R3 then continues to send hello packets on the normal cadence.
Resign message from R2:
Advertise message from R3:
After observing the Resign and Advertise message I reenabled R2’s interface. R2 announced its presence as an HSRP speaking router with an Advertise packet with state of passive. R3 continues to send hello packets every 3 seconds which are received by R2. R2 realizes that the received priority value of 90 is inferior to the local value of 100 and sends an HSRP Coup message and advertises its local state as Listen. The Coup message is sent to indicate that R2 wants to become the active router. R2 then immediately sends an advertisement and a hello packet claiming to be the active router. R3 sends 5 hello packets with the state of Speak. During this period R3 is listening for hellos from other routers to determine what state it should transition to. Since only two HSRP routers exist on the segment R3 transitions to Standby and announces this in its hello packets.
Coup packet from R2:
VRRP Configuration
Now that we’ve seen some of the interesting bits of HSRP operation we can examine the IETF’s way of next hop redundancy. The configuration and “show vrrp” output are shared below. R3 should be the backup router since it has the lower priority. Something note about the configuration is that preemption does not need to be administratively enabled, it is on by default. Notice the “show” command output. The network was converged when this output was taken but no information about other VRRP routers is displayed. The timers are also notable in this output. The Master Advertisement Interval is the default of 1 second. The Master Down Interval = (3 * Master Advertisement Interval) + skew time. This is a clever way of determining a “dead interval”.
RoutingLoop_R2#show run int g0/0
Building configuration…
Current configuration : 116 bytes
!
interface GigabitEthernet0/0
ip address 10.0.0.2 255.255.255.0
duplex auto
speed auto
vrrp 1 ip 10.0.0.1
RoutingLoop_R3#show run int g0/0
Building configuration…
Current configuration : 136 bytes
!
interface GigabitEthernet0/0
ip address 10.0.0.3 255.255.255.0
duplex auto
speed auto
vrrp 1 ip 10.0.0.1
vrrp 1 priority 90
RoutingLoop_R2#show vrrp
GigabitEthernet0/0 – Group 1
State is Master
Virtual IP address is 10.0.0.1
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Master Router is 10.0.0.2 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec
VRRP Packet Capture
After configuring VRRP and allowing it to converge I started the packet capture. It was immediately obvious that the VRRP backup router does not send any kind of hello or announcement packet. During steady state operation the only VRRP traffic is announcements from the master router every 1 second. The IP Time to Live value of VRRP advertisements is 255. Per rfc3768 “The TTL MUST be set to 255. A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet.”. This offers security benefits by ensuring that a bad actor can’t send “long range” VRRP announcements to attack the network.
Just like with the HSRP demo, I shut down the physical interface of R2. R2 quickly sent a VRRP Announcement with special priority 0, indicating that the Master router is no longer participating in VRRP. This special priority value is also defined in rfc3768. After the priority 0 announcement from R2, R3 becomes the master router and starts advertising its own Announcements.
I then reenabled R2’s interface with the capture still running. Once R2 processed R3’s Announcements it found that R3 has an inferior priority and R2 transitioned to the Master state. R2 receives this superior packet, transitions to the backup state, and stops sending Announcement packets.
Conclusion
Both protocols exist to solve the same problem but have their differences. VRRP is an open standard supported by many vendors, HSRP is Cisco proprietary. HSRP has slower timers by default but more than one router sends protocol packets so it’s hard to argue that one is “chattier” than the other without further analysis. There might be an argument that HSRP is more complex because it has many Op Codes embedded in its protocol packets. They use different IP TTLs with a possible advantage to VRRP with its embedded TTL security.