HSRP version 2 is
designed to address the following restrictions in HSRP version 1:
In HSRP version
1, millisecond timer values are not advertised or learned. HSRP version 2
advertises and learns millisecond timer values. This change ensures stability
of the HSRP groups in all cases.
In HSRP version
1, group numbers are restricted to the range from 0 to 255. HSRP version 2
expands the group number range from 0 to 4095.
HSRP version 2
provides improved management and troubleshooting. With HSRP version 1, you
cannot use HSRP active hello messages to identify which physical device sent
the message because the source MAC address is the HSRP virtual MAC address. The
HSRP version 2 packet format includes a 6-byte identifier field that is used to
uniquely identify the sender of the message. Typically, this field is populated
with the interface MAC address.
address 220.127.116.11 is used to send HSRP hello messages. This address can
conflict with Cisco Group Management Protocol (CGMP) leave processing.
Version 1 is the
default version of HSRP.
HSRP version 2 uses
the new IP multicast address 18.104.22.168 to send hello packets instead of the
multicast address of 22.214.171.124, used by HSRP version 1. This new multicast
address allows CGMP leave processing to be enabled at the same time as HSRP.
HSRP version 2
permits an expanded group number range, 0 to 4095, and consequently uses a new
MAC address range 0000.0C9F.F000 to 0000.0C9F.FFFF. The increased group number
range does not imply that an interface can, or should, support that many HSRP
groups. The expanded group number range was changed to allow the group number
to match the VLAN number on subinterfaces.
When the HSRP version
is changed, each group will reinitialize because it now has a new virtual MAC
HSRP version 2 has a
different packet format than HSRP version 1. The packet format uses a
type-length-value (TLV) format. HSRP version 2 packets received by an HSRP
version 1 device will have the type field mapped to the version field by HSRP
version 1 and subsequently ignored.
The Gateway Load
Balancing Protocol (GLBP) also addresses the same restrictions relative to HSRP
version 1 that HSRP version 2 does. See the
document for more information on GLBP.
Jitter timers are used in HSRP. They are recommended for timers
running on services that work realtime and scale. Jitter timers are intended to
significantly improve the reliability of HSRP, and other FHRP protocols, by
reducing the chance of bunching of HSRP groups operations, and thus help reduce
CPU and network traffic spikes. In the case of HSRP, a given device may have up
to 4000 operational groups configured. In order to distribute the load on the
device and network, the HSRP timers use a jitter. A given timer instance may
take up to 20% more than the configured value. For example, for a hold time set
to 15 seconds, the actual hold time may take 18 seconds.
In HSRP, the Hello timer (which sends the Hello Packet) has a negative
Jitter, while the Holddown timer (which checks for failure of a peer) has a