Configuring HSRP

Most IP hosts have an IP address of a single router configured as the default gateway. When HSRP is used, the HSRP virtual IP address is configured as the host's default gateway instead of the IP address of the router.

HSRP is useful for hosts that do not support a router discovery protocol (such as ICMP Router Discovery Protocol [IRDP]) and cannot switch to a new router when their selected router reloads or loses power. Because existing TCP sessions can survive the failover, this protocol also provides a more transparent recovery for hosts that dynamically choose a next hop for routing IP traffic.

When HSRP is configured on a network segment, it provides a virtual MAC address and an IP address that is shared among a group of routers running HSRP. The address of this HSRP group is referred to as the virtual IP address . One of these devices is selected by the protocol to be the active router. The active router receives and routes packets destined for the MAC address of the group. For n routers running HSRP, n+ 1 IP and MAC addresses are assigned.

HSRP detects when the designated active router fails, at which point a selected standby router assumes control of the MAC and IP addresses of the Hot Standby group. A new standby router is also selected at that time.

HSRP uses a priority mechanism to determine which HSRP configured router is to be the default active router. To configure a router as the active router, you assign it a priority that is higher than the priority of all the other HSRP-configured routers. The default priority is 100, so if you configure just one router to have a higher priority, that router will be the default active router.

Devices that are running HSRP send and receive multicast User Datagram Protocol (UDP)-based hello messages to detect router failure and to designate active and standby routers. When the active router fails to send a hello message within a configurable period of time, the standby router with the highest priority becomes the active router. The transition of packet forwarding functions between routers is completely transparent to all hosts on the network.

You can configure multiple Hot Standby groups on an interface, thereby making fuller use of redundant routers and load sharing.

The figure below shows a network configured for HSRP. By sharing a virtual MAC address and IP address, two or more routers can act as a single virtual router . The virtual router does not physically exist but represents the common default gateway for routers that are configured to provide backup to each other. You do not need to configure the hosts on the LAN with the IP address of the active router. Instead, you configure them with the IP address (virtual IP address) of the virtual router as their default gateway. If the active router fails to send a hello message within the configurable period of time, the standby router takes over and responds to the virtual addresses and becomes the active router, assuming the active router duties.

Figure 1

HSRP Topology

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 router 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.
• The multicast address 224.0.0.2 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 224.0.0.102 to send hello packets instead of the multicast address of 224.0.0.2, 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 address.

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 router 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 Configuring GLBP document for more information on GLBP.

You can use the CLI to apply group attributes to:

• A single HSRP group--performed in interface configuration mode and applies to a group.
• All groups on the interface--performed in interface configuration mode and applies to all groups on the interface.
• All groups on all interfaces--performed in global configuration mode and applies to all groups on all interfaces.

When a newly reloaded device becomes HSRP active, and there is already an HSRP active device on the network, HSRP preemption may appear to not function. HSRP preemption may appear not function correctly because the new HSRP active device did not receive any hello packets from the current HSRP active device, and the preemption configuration never factored into the new device's decision making.

HSRP may appear to not function on some larger hardware platforms where there can be a delay in an interface receiving packets.

In general, we recommend that all HSRP devices have the following configuration:

standby delay minimum 30 reload 60

The standby delay minimum reload interface configuration command delays HSRP groups from initializing for the specified time after the interface comes up.

This is a different command than the standby preempt delay interface configuration command, which enables HSRP preemption delay.

Preemption enables the HSRP router with the highest priority to immediately become the active router. Priority is determined first by the configured priority value, and then by the IP address. In case of ties, the primary IP addresses are compared, and the higher IP address has priority. In each case, a higher value is of greater priority. If you do not use the standby preempt interface configuration command in the configuration for a router, that router will not become the active router, even if its priority is higher than all other routers.

A standby router with equal priority but a higher IP address will not preempt the active router.

When a router first comes up, it does not have a complete routing table. You can set a preemption delay that allows preemption to be delayed for a configurable time period. This delay period allows the router to populate its routing table before becoming the active router.

If preemption is not enabled, then a router may appear to preempt the active router if it does not receive any Hello messages from the active router.

The priority of a device can change dynamically if it has been configured for object tracking and the object that is being tracked goes down. The tracking process periodically polls the tracked objects and notes any change of value. The changes in the tracked object are communicated to HSRP, either immediately or after a specified delay. The object values are reported as either up or down. Examples of objects that can be tracked are the line protocol state of an interface or the reachability of an IP route. If the specified object goes down, the HSRP priority is reduced. The HSRP device with the higher priority can become the active device if it has the standby preempt command configured.

HSRP routers communicate between each other by exchanging HSRP hello packets. These packets are sent to the destination IP multicast address 224.0.0.2 (reserved multicast address used to communicate to all routers) on UDP port 1985. The active router sources hello packets from its configured IP address and the HSRP virtual MAC address while the standby router sources hellos from its configured IP address and the interface MAC address, which may or may not be the Burned-In MAC address (BIA).

Because hosts are configured with their default gateway as the HSRP virtual IP address, hosts must communicate with the MAC address associated with the HSRP virtual IP address. This MAC address will be a virtual MAC address composed of 0000.0C07.ACxy, where xy is the HSRP group number in hexadecimal based on the respective interface. For example, HSRP group one will use the HSRP virtual MAC address of 0000.0C07.AC01. Hosts on the adjoining LAN segment use the normal Address Resolution Protocol (ARP) process to resolve the associated MAC addresses.

HSRP version 2 uses the new IP multicast address 224.0.0.102 to send hello packets instead of the multicast address of 224.0.0.2, which is used by version 1. This new multicast address allows Cisco Group Management Protocol (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.

A device automatically generates a virtual MAC address for each HSRP device. However, some network implementations, such as Advanced Peer-to-Peer Networking (APPN), use the MAC address to identify the first hop for routing purposes. In this case, specify the virtual MAC address by using the standby mac-address command in the group; the virtual IP address is unimportant for these protocols.

The standby use-bia command was implemented to overcome the limitations of using a functional address for the HSRP MAC address on Token Ring interfaces. This command allows HSRP groups to use the burned-in MAC address of an interface instead of the HSRP virtual MAC address. When HSRP runs on a multiple-ring, source-routed bridging environment and the HSRP devices reside on different rings, configuring the standby use-bia command can prevent confusion about the routing information field (RFI).

The standby use-bia command is used for an interface and the standby mac-address command is used for an HSRP group.

Each HSRP device maintains three timers that are used for timing hello messages: an active timer, a standby timer, and a hello timer. When a timer expires, the device changes to a new HSRP state. Devices for which timer values are not configured can learn timer values from the active or standby device. The timers configured on the active device always override any other timer settings. All devices in a Hot Standby group should use the same timer values.

For HSRP version 1, nonactive devices learn timer values from the active device, unless millisecond timer values are being used. If millisecond timer values are being used, all devices must be configured with the millisecond timer values. This rule applies if either the hello time or the hold time is specified in milliseconds. This configuration is necessary because the HSRP hello packets advertise the timer values in seconds. HSRP version 2 does not have this limitation; it advertises the timer values in milliseconds.

HSRP ignores unauthenticated HSRP protocol messages. The default authentication type is text authentication.

HSRP authentication protects against false HSRP hello packets causing a denial-of-service attack. For example, Device A has a priority of 120 and is the active device. If a host sends spoof HSRP hello packets with a priority of 130, then Device A stops being the active device. If Device A has authentication configured such that the spoof HSRP hello packets are ignored, Device A will remain the active device

HSRP packets will be rejected in any of the following cases:

• The authentication schemes differ on the device and in the incoming packets.
• Text authentication strings differ on the device and in the incoming packet.

Before the introduction of HSRP MD5 authentication, HSRP authenticated protocol packets with a simple plain text string. HSRP MD5 authentication is an enhancement to generate an MD5 digest for the HSRP portion of the multicast HSRP protocol packet. This functionality provides added security and protects against the threat from HSRP-spoofing software.

MD5 authentication provides greater security than the alternative plain text authentication scheme. MD5 authentication allows each HSRP group member to use a secret key to generate a keyed MD5 hash that is part of the outgoing packet. A keyed hash of an incoming packet is generated and if the hash within the incoming packet does not match the generated hash, the packet is ignored.

The key for the MD5 hash can be either given directly in the configuration using a key string or supplied indirectly through a key chain.

HSRP has two authentication schemes:

• Plain text authentication
• MD5 authentication

HSRP authentication protects against false HSRP hello packets causing a denial-of-service attack. For example, Device A has a priority of 120 and is the active device. If a host sends spoof HSRP hello packets with a priority of 130, then Device A stops being the active device. If Device A has authentication configured such that the spoof HSRP hello packets are ignored, Device A will remain the active device.

HSRP packets will be rejected in any of the following cases:

• The authentication schemes differ on the device and in the incoming packets.
• MD5 digests differ on the device and in the incoming packet.
• Text authentication strings differ on the device and in the incoming packet.

Routers configured with HSRP exchange three types of multicast messages:

• Hello--The hello message conveys to other HSRP routers the HSRP priority and state information of the router.
• Coup--When a standby router wants to assume the function of the active router, it sends a coup message.
• Resign--A router that is the active router sends this message when it is about to shut down or when a router that has a higher priority sends a hello or coup message.

At any time, a router configured with HSRP is in one of the following states:

• Active--The router is performing packet-transfer functions.
• Standby--The router is prepared to assume packet-transfer functions if the active router fails.
• Speak--The router is sending and receiving hello messages.
• Listen--The router is receiving hello messages.
• Init or Disabled--The router is not yet ready or able to participate in HSRP, possibly because the associated interface is not up. HSRP groups configured on other routers on the network that are learned via snooping are displayed as being in the Init state. Locally configured groups with an interface that is down or groups without a specified interface IP address appear in the Init state.

HSRP uses logging level 5 for syslog messages related to HSRP state changes to allow logging of an event without filling up the syslog buffer on the router with low-priority Level 6 messaging.

HSRP works when the hosts are configured for proxy ARP. When the active HSRP device receives an ARP request for a host that is not on the local LAN, the device replies with the MAC address of the virtual router. If the active device becomes unavailable or its connection to the remote LAN goes down, the device that becomes the active device receives packets addressed to the virtual router and transfers them accordingly. If the Hot Standby state of the interface is not active, proxy ARP responses are suppressed.

Object tracking separates the tracking mechanism from HSRP and creates a separate standalone tracking process that can be used by any other process as well as HSRP. The priority of a device can change dynamically when it has been configured for object tracking and the object that is being tracked goes down. Examples of objects that can be tracked are the line protocol state of an interface or the reachability of an IP route. If the specified object goes down, the HSRP priority is reduced.

A client process such as HSRP, Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol (GLBP) can register its interest in tracking objects and then be notified when the tracked object changes state.

For more information about object tracking, see the "Configuring Enhanced Object Tracking" document.

The FHRP--HSRP Group Shutdown feature enables you to configure an HSRP group to become disabled (its state changed to Init) instead of having its priority decremented when a tracked object goes down. Use the standby track command with the shutdown keyword to configure HSRP group shutdown.

If an object is already being tracked by an HSRP group, you cannot change the configuration to use the HSRP Group Shutdown feature. You must first remove the tracking configuration using the no standby track command and then reconfigure it using the standby track command with the shutdown keyword.

By default, HSRP filtering of Internet Control Message Protocol (ICMP) redirect messages is enabled on devices running HSRP.

ICMP is a network layer Internet protocol that provides message packets to report errors and other information relevant to IP processing. ICMP can send error packets to a host and can send redirect packets to a host.

When HSRP is running, preventing hosts from discovering the interface (or real) IP addresses of devices in the HSRP group is important. If a host is redirected by ICMP to the real IP address of a device, and that device later fails, then packets from the host will be lost.

ICMP redirect messages are automatically enabled on interfaces configured with HSRP. This functionality works by filtering outgoing ICMP redirect messages through HSRP, where the next hop IP address may be changed to an HSRP virtual IP address.

The next-hop IP address is compared to the list of active HSRP devices on that network; if a match is found, then the real next-hop IP address is replaced with a corresponding virtual IP address and the redirect message is allowed to continue.

If no match is found, then the ICMP redirect message is sent only if the device corresponding to the new next hop IP address is not running HSRP. Redirects to passive HSRP devices are not allowed (a passive HSRP device is a device running HSRP, but which contains no active HSRP groups on the interface).

For optimal operation, every device in a network that is running HSRP should contain at least one active HSRP group on an interface to that network. Every HSRP device need not be a member of the same group. Each HSRP device will snoop on all HSRP packets on the network to maintain a list of active devices (virtual IP addresses versus real IP addresses).

Consider the network shown in the figure below, which supports the HSRP ICMP redirection filter.

Figure 2

Network Supporting the HSRP ICMP Redirection Filter

If the host wants to send a packet to another host on Net D, then it first sends it to its default gateway, the virtual IP address of HSRP group 1.

The following is the packet received from the host:

dest MAC         = HSRP group 1 virtual MAC
source MAC       = Host MAC
dest IP          = host-on-netD IP
source IP        = Host IP

Device R1 receives this packet and determines that device R4 can provide a better path to Net D, so it prepares to send a redirect message that will redirect the host to the real IP address of device R4 (because only real IP addresses are in its routing table).

The following is the initial ICMP redirect message sent by device R1:

dest MAC         = Host MAC
source MAC       = router R1 MAC
dest IP          = Host IP
source IP        = router R1 IP
gateway to use   = router R4 IP

Before this redirect occurs, the HSRP process of device R1 determines that device R4 is the active HSRP device for group 3, so it changes the next hop in the redirect message from the real IP address of device R4 to the virtual IP address of group 3. Furthermore, it determines from the destination MAC address of the packet that triggered the redirect message that the host used the virtual IP address of group 1 as its gateway, so it changes the source IP address of the redirect message to the virtual IP address of group 1.

The modified ICMP redirect message showing the two modified fields (*) is as follows:

dest MAC         = Host MAC
source MAC       = router R1 MAC
dest IP          = Host IP
source IP*       = HSRP group 1 virtual IP
gateway to use*  = HSRP group 3 virtual IP

This second modification is necessary because hosts compare the source IP address of the ICMP redirect message with their default gateway. If these addresses do not match, the ICMP redirect message is ignored. The routing table of the host now consists of the default gateway, virtual IP address of group 1, and a route to Net D through the virtual IP address of group 3.

ICMP redirects to passive HSRP devices are not permitted. Redundancy may be lost if hosts learn the real IP addresses of HSRP devices.

In the "Network Supporting the HSRP ICMP Redirection Filter" figure, redirection to device R8 is not allowed because R8 is a passive HSRP device. In this case, packets from the host to Net D will first go to device R1 and then be forwarded to device R4; that is, they will traverse the network twice.

A network configuration with passive HSRP devices is considered a misconfiguration. For HSRP ICMP redirection to operate optimally, every device on the network that is running HSRP should contain at least one active HSRP group.

ICMP redirects to devices not running HSRP on their local interface are permitted. No redundancy is lost if hosts learn the real IP address of non-HSRP devices.

In the "Network Supporting the HSRP ICMP Redirection Filter" figure, redirection to device R7 is allowed because R7 is not running HSRP. In this case, the next hop IP address is unchanged. The source IP address is changed dependent upon the destination MAC address of the original packet. You can specify the no standby redirect unknown command to stop these redirects from being sent.

Passive HSRP devices send out HSRP advertisement messages both periodically and when entering or leaving the passive state. Thus, all HSRP devices can determine the HSRP group state of any HSRP device on the network. These advertisements inform other HSRP devices on the network of the HSRP interface state, as follows:

• Active--Interface has at least one active group. A single advertisement is sent out when the first group becomes active.
• Dormant--Interface has no HSRP groups. A single advertisement is sent once when the last group is removed.
• Passive--Interface has at least one nonactive group and no active groups. Advertisements are sent out periodically.

You can adjust the advertisement interval and hold-down time using the standby redirect timers command.

If the HSRP device cannot uniquely determine the IP address used by the host when it sends the packet that caused the redirect, the redirect message will not be sent. The device uses the destination MAC address in the original packet to make this determination. In certain configurations, such as the use of the standby use-bia interface configuration command specified on an interface, redirects cannot be sent. In this case, the HSRP groups use the interface MAC address as their virtual MAC address. The device now cannot determine if the default gateway of the host is the real IP address or one of the HSRP virtual IP addresses that are active on the interface.

The IP source address of an ICMP packet must match the gateway address used by the host in the packet that triggered the ICMP packet, otherwise the host will reject the ICMP redirect packet. An HSRP device uses the destination MAC address to determine the gateway IP address of the host. If the HSRP device is using the same MAC address for multiple IP addresses, uniquely determining the gateway IP address of the host is not possible, and the redirect message is not sent.

The following is sample output from the debug standby events icmp EXEC command if HSRP could not uniquely determine the gateway used by the host:

10:43:08: HSRP: ICMP redirect not sent to 10.0.0.4 for dest 10.0.1.2
10:43:08: HSRP: could not uniquely determine IP address for mac 00d0.bbd3.bc22

HSRP support for a Multiprotocol Label Switching (MPLS) VPN interface is useful when an Ethernet LAN is connected between two provider edge (PE) devices with either of the following conditions:

• A customer edge (CE) device with a default route to the HSRP virtual IP address
• One or more hosts with the HSRP virtual IP address configured as the default gateway

Each VPN is associated with one or more VPN routing and forwarding (VRF) instances. A VRF consists of the following elements:

• IP routing table
• Cisco Express Forwarding table
• Set of interfaces that use the Cisco Express Forwarding forwarding table
• Set of rules and routing protocol parameters to control the information in the routing tables

VPN routing information is stored in the IP routing table and the Cisco Express Forwarding table for each VRF. A separate set of routing and Cisco Express Forwarding tables is maintained for each VRF. These tables prevent information from being forwarded outside a VPN and also prevent packets that are outside a VPN from being forwarded to a device within the VPN.

HSRP adds ARP entries and IP hash table entries (aliases) using the default routing table instance. However, a different routing table instance is used when VRF forwarding is configured on an interface, causing ARP and ICMP echo requests for the HSRP virtual IP address to fail.

HSRP support for MPLS VPNs ensures that the HSRP virtual IP address is added to the correct IP routing table and not to the default routing table.

The configuration of many hundreds of subinterfaces on the same physical interface, with each subinterface having its own HSRP group, can cause the processes of negotiation and maintenance of multiple HSRP groups to have a detrimental impact on network traffic and CPU utilization.

Only one HSRP group is required on a physical interface for the purposes of electing active and standby devices. This group is known as the master group. Other HSRP groups may be created on each subinterface and linked to the master group via the group name. These linked HSRP groups are known as client or slave groups.

The HSRP group state of the client groups follows that of the master group. Client groups do not participate in any sort of device election mechanism.

Client groups send periodic messages in order to refresh their virtual MAC addresses in switches and learning bridges. The refresh message may be sent at a much lower frequency compared with the protocol election messages sent by the master group.

The In Service Software Upgrade (ISSU) process allows Cisco IOS XE software to be updated or otherwise modified while packet forwarding continues. In most networks, planned software upgrades are a significant cause of downtime. ISSU allows Cisco IOS XE software to be modified while packet forwarding continues, which increases network availability and reduces downtime caused by planned software upgrades. This document provides information about ISSU concepts and describes the steps taken to perform ISSU in a system.

For detailed information about ISSU, see the Cisco IOS XE In Service Software Upgrade Process document in the Cisco IOS XE High Availability Configuration Guide.

SSO HSRP alters the behavior of HSRP when a device with redundant Route Processors (RPs) is configured for stateful switchover (SSO) redundancy mode. When an RP is active and the other RP is standby, SSO enables the standby RP to take over if the active RP fails.

With this functionality, HSRP SSO information is synchronized to the standby RP, allowing traffic that is sent using the HSRP virtual IP address to be continuously forwarded during a switchover without a loss of data or a path change. Additionally, if both RPs fail on the active HSRP device, then the standby HSRP device takes over as the active HSRP device.

The feature is enabled by default when the redundancy mode of operation is set to SSO.

• SSO Dual-Route Processors and Cisco Nonstop Forwarding
• HSRP and SSO Working Together

HSRP MIB supports Simple Network Management Protocol (SNMP) Get operations, to allow network devices to get reports about HSRP groups in a network from the network management station.

Enabling HSRP MIB trap support is performed through the CLI, and the MIB is used for getting the reports. A trap notifies the network management station when a device leaves or enters the active or standby state. When an entry is configured from the CLI, the RowStatus for that group in the MIB immediately goes to the active state.

Cisco software supports a read-only version of the MIB, and set operations are not supported.

This functionality supports four MIB tables, as follows:

• cHsrpGrpEntry table defined in CISCO-HSRP-MIB.my
• cHsrpExtIfTrackedEntry, defined in CISCO-HSRP-EXT-MIB.my
• cHsrpExtSecAddrEntry, defined in CISCO-HSRP-EXT-MIB.my
• cHsrpExtIfEntry defined in CISCO-HSRP-EXT-MIB.my

The cHsrpGrpEntry table consists of all the group information defined in RFC 2281, Cisco Hot Standby Router Protocol; the other tables consist of the Cisco extensions to RFC 2281, which are defined in CISCO-HSRP-EXT-MIB.my.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask

5.    standby [group-number] ip [ip-address [secondary]]

6.    end

7.    show standby [all] [brief]

8.    show standby type number [group-number | all] [brief]

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask

5.    standby delay minimum min-seconds reload reload-seconds

6.    standby [group-number ] ip [ip-address [secondary]]

7.    end

8.    show standby delay [typenumber]

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask

5.    standby [group-number] priority priority

6.    standby [group-number] preempt [delay {minimum | reload | sync} seconds]

7.    standby [group-number] ip ip-address [secondary]]

8.    end

9.    show standby [all] [brief]

10.    show standby type number [group-number | all] [brief]

1.    enable

2.    configure terminal

3.    track object-number interface type number {line-protocol | ip routing}

4.    exit

5.    interface type number

6.    standby [group-number] track object-number [decrement priority-decrement] [shutdown]

7.    standby [group-number] ip [ip-address [secondary]]

8.    end

9.    show track [object-number | brief] [interface [brief] | ip route [brief] | resolution | timers]

Note

Text authentication cannot be combined with MD5 authentication for an HSRP group at any one time. When MD5 authentication is configured, the text authentication field in HSRP hello messages is set to all zeroes on transmit and ignored on receipt, provided the receiving device also has MD5 authentication enabled.

Note

If you are changing a key string in a group of devices, change the active device last to prevent any HSRP state change. The active device should have its key string changed no later than one hold-time period, specified by the standy timers interface configuration command, after the nonactive devices. This procedure ensures that the nonactive devices do not time out the active device.

1.    enable

2.    configure terminal

3.    terminal interface type number

4.    ip address ip-address mask [secondary]

5.    standby [group-number] priority priority

6.    standby [group-number] preempt [delay {minimum | reload | sync} seconds]

7.    standby [group-number] authentication md5 key-string [0 | 7] key [timeout seconds]

8.    standby [group-number] ip [ip-address] [secondary]]

9.    Repeat Steps 1 through 8 on each device that will communicate.

10.    end

11.    show standby

1.    enable

2.    configure terminal

3.    key chain name-of-chain

4.    key key-id

5.    key-string string

6.    exit

7.    exit

8.    interface type number

9.    ip address ip-address mask [secondary]

10.    standby [group-number] priority priority

11.    standby [group-number] preempt [delay {minimum | reload | sync} seconds]

12.    standby [group-number] authentication md5 key-chain key-chain-name

13.    standby [group-number] ip [ip-address [secondary]]

14.    Repeat Steps 1 through 12 on each device that will communicate.

15.    end

16.    show standby

1.    enable

2.    debug standby errors

Device# debug standby errors

A:Jun 16 12:14:50.337:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.5, MD5 confgd but no tlv
B:Jun 16 12:16:34.287:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.4, Text auth failed

Device# debug standby errors

A:Jun 16 12:19:26.335:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.5, MD5 auth failed
B:Jun 16 12:18:46.280:HSRP:Et0/1 Grp 0 Auth failed for Hello pkt from 10.21.0.4, MD5 auth failed

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask [secondary]

5.    standby [group-number] priority priority

6.    standby [group-number] preempt [delay {minimum | reload | sync} seconds]

7.    standby [group-number] authentication text string

8.    standby [group-number] ip [ip-address [secondary]]

9.    Repeat Steps 1 through 8 on each device that will communicate.

10.    end

11.    show standby

Note	We recommend configuring a minimum hello-time value of 250 milliseconds and a minimum hold-time value of 800 milliseconds.

You can use the standby delay command to allow the interface to come up completely before HSRP initializes.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask [secondary]]

5.    standby [group-number] timers [msec] hellotime [msec] holdtime

6.    standby [group-number] ip [ip-address [secondary]]

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask [secondary]

5.    standby [group-number] priority priority

6.    standby [group-number] preempt [delay {minimum | reload | sync} delay]

7.    standby [group-number] ip [ip-address] secondary]

8.    On the same device, repeat Steps 5 through 7 to configure the device attributes for different standby groups.

9.    exit

10.    Repeat Steps 3 through 9 on another device.

Perform this task to configure multiple HSRP client groups.

The standby follow command configures an HSRP group to become a slave of another HSRP group.

HSRP client groups follow the master HSRP with a slight, random delay so that all client groups do not change at the same time.

Use the standby mac-refresh seconds command to directly change the HSRP client group refresh interval. The default interval is 10 seconds and can be configured to as much as 255 seconds.

Note

Client or slave groups must be on the same physical interface as the master group. A client group takes its state from the group it is following. Therefore, the client group does not use its timer, priority, or preemption settings. A warning is displayed if these settings are configured on a client group: Device(config-if)# standby 1 priority 110 %Warning: This setting has no effect while following another group. Device(config-if)# standby 1 timers 5 15 % Warning: This setting has no effect while following another group. Device(config-if)# standby 1 preempt delay minimum 300 % Warning: This setting has no effect while following another group.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask [secondary]

5.    standby mac-refresh seconds

6.    standby group-number follow group-name

7.    exit

8.    Repeat Steps 3 through 6 to configure additional HSRP client groups.

1.    enable

2.    configure terminal

3.    interface type number

4.    standby redirect [timers advertisement holddown] [unknown]

5.    end

6.    show standby redirect [ip-address] [interface-type interface-number] [active] [passive] [timers]

Note

You cannot use the standby use-bia and standby mac-address commands in the same configuration; they are mutually exclusive. The standby use-bia command has the following disadvantages: When a device becomes active the virtual IP address is moved to a different MAC address. The newly active device sends a gratuitous ARP response, but not all host implementations handle the gratuitous ARP correctly. Proxy ARP does not function when the standby use-bia command is configured. A standby device cannot cover for the lost proxy ARP database of the failed device.

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask [secondary]

5.   Enter one of the following commands:

6.    standby [group-number] ip [ip-address [secondary]]

HSRP version 2 was introduced to prepare for further enhancements and to expand the capabilities beyond what is possible with HSRP version 1. HSRP version 2 has a different packet format than HSRP version 1.

Note

HSRP version 2 is not available for ATM interfaces running LAN emulation. HSRP version 2 will not interoperate with HSRP version 1. An interface cannot operate both version 1 and version 2 because both versions are mutually exclusive. However, the different versions can be run on different physical interfaces of the same device. You cannot change from version 2 to version 1 if you have configured groups above the group number range allowed for version 1 (0 to 255).

1.    enable

2.    configure terminal

3.    interface type number

4.    ip address ip-address mask

5.    standby version {1 | 2}

6.    standby [group-number] ip [ip-address [secondary]]

7.    end

8.    show standby

The SSO aware HSRP is enabled by default when the redundancy mode is set to SSO. Perform this task to reenable HSRP to be SSO aware if it has been disabled.

Note	You may want to disable SSO HSRP by using the no standby sso command if you have LAN segments that should switch HSRP traffic to a redundant device while SSO maintains traffic flow for other connections.

1.    enable

2.    configure terminal

3.    redundancy

4.    mode sso

5.    exit

6.    no standby sso

7.    standby sso

8.    end

1.    show standby

2.    debug standby events ha

Device# show standby 

GigabitEthernet0/0/0 - Group 1
 State is Active (standby RP)
 Virtual IP address is 10.1.0.7
 Active virtual MAC address is unknown
  Local virtual MAC address is 000a.f3fd.5001 (bia)
 Hello time 1 sec, hold time 3 sec
 Authentication text "authword"
 Preemption enabled
 Active router is unknown
 Standby router is unknown
 Priority 110 (configured 120)
  Track object 1 state Down decrement 10
 Group name is "name1" (cfgd)

Device# debug standby events ha

!Active RP
*Apr 27 04:13:47.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Listen into sync buffer
*Apr 27 04:13:47.855: HSRP: CF Sync send ok
*Apr 27 04:13:57.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Speak into sync buffer
*Apr 27 04:13:57.855: HSRP: CF Sync send ok
*Apr 27 04:14:07.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Standby into sync buffer
*Apr 27 04:14:07.755: HSRP: Gi0/0/1 Grp 101 RF Encode state Active into sync buffer
*Apr 27 04:14:07.863: HSRP: CF Sync send ok
*Apr 27 04:14:07.867: HSRP: CF Sync send ok
!Standby RP
*Apr 27 04:11:21.011: HSRP: RF CF client 32, entity 0 got msg len 24
*Apr 27 04:11:21.011: HSRP: Gi0/0/1 Grp 101 RF sync state Init -> Listen
*Apr 27 04:11:31.011: HSRP: RF CF client 32, entity 0 got msg len 24
*Apr 27 04:11:31.011: HSRP: Gi0/0/1 Grp 101 RF sync state Listen -> Speak
*Apr 27 04:11:41.071: HSRP: RF CF client 32, entity 0 got msg len 24
*Apr 27 04:11:41.071: HSRP: RF CF client 32, entity 0 got msg len 24
*Apr 27 04:11:41.071: HSRP: Gi0/0/1 Grp 101 RF sync state Speak -> Standby
*Apr 27 04:11:41.071: HSRP: Gi0/0/1 Grp 101 RF sync state Standby -> Active

1.    enable

2.    configure terminal

3.    snmp-server enable traps hsrp

4.    snmp-server host host community-string hsrp