HSRP is a first-hop redundancy protocol (FHRP) that allows a transparent failover of the first-hop IP router. HSRP provides first-hop routing redundancy for IP hosts on Ethernet networks configured with a default router IP address. You use HSRP in a group of routers for selecting an active router and a standby router. In a group of routers, the active router is the router that routes packets; the standby router is the router that takes over when the active router fails or when preset conditions are met.

Many host implementations do not support any dynamic router discovery mechanisms but can be configured with a default router. Running a dynamic router discovery mechanism on every host is not practical for many reasons, including administrative overhead, processing overhead, and security issues. HSRP provides failover services to these hosts.

You can configure an HSRP subnet virtual IP (VIP) address in a different subnet than that of the interface IP address.

Note	You can configure HSRP subnet VIPs for Cisco Nexus 3400-S platform switches with the 16C and 4D line card expansion modules (LEMs).

This feature enables you to conserve public IPv4 addresses by using a VIP as a public IP address and an interface IP as a private IP address. HSRP subnet VIPs are not needed for IPv6 addresses because:

• A larger pool of IPv6 addresses is available.

• Routable IPv6 addresses can be configured on an SVI and used with regular HSRP.

This feature also enables periodic ARP synchronization to vPC peers and allows ARP to source with the VIP when an HSRP subnet VIP is configured for hosts in the VIP subnet.

For more information, see Guidelines and Limitations for HSRP and Configuration Examples for HSRP.

HSRP message digest 5 (MD5) algorithm authentication protects against HSRP-spoofing software and uses the industry-standard MD5 algorithm for improved reliability and security. HSRP includes the IPv4 or IPv6 address in the authentication TLVs.

Routers that are configured with HSRP exchange the following types of multicast messages:

• Hello—The hello message conveys the HSRP priority and state information of the router to other HSRP routers.

• 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.

HSRP allows you to configure multiple groups on an interface. You can configure two overlapping IPv4 HSRP groups to load share traffic from the connected hosts while providing the default router redundancy expected from HSRP. The following figure shows an example of a load-sharing HSRP IPv4 configuration.

This figure shows two routers (A and B) and two HSRP groups. Router A is the active router for group A but is the standby router for group B. Similarly, router B is the active router for group B and the standby router for group A. If both routers remain active, HSRP load balances the traffic from the hosts across both routers. If either router fails, the remaining router continues to process traffic for both hosts.

Note	HSRP for IPv6 load balances by default. If two HSRP IPv6 groups are on the subnet, hosts learn of both groups from their router advertisements and choose to use one so that the load is shared between the advertised routers.

You can use object tracking to modify the priority of an HSRP interface based on the operational state of another interface. Object tracking allows you to route to a standby router if the interface to the main network fails.

Two objects that you can track are the line protocol state of an interface or the reachability of an IP route. If the specified object goes down, Cisco NX-OS reduces the HSRP priority by the configured amount. For more information, see the Configuring HSRP Object Tracking section.

HSRP interoperates with virtual port channels (vPCs). vPCs allow links that are physically connected to two different Cisco Nexus 3400-S platform switches to appear as a single port channel by a third device. See the Cisco Nexus 3400-S NX-OS Layer 2 Switching Configuration Guide for more information on vPCs.

vPC forwards traffic through both the active HSRP router and the standby HSRP router. For more information, see the Configuring the HSRP Priority section and the Configuration Examples for HSRP section.

Note	HSRP active can be distributed on both the primary and secondary vPC peers for different SVIs.

This feature supports bidirectional forwarding detection (BFD). BFD is a detection protocol that provides fast-forwarding and path-failure detection times. BFD provides subsecond failure detection between two adjacent devices and can be less CPU-intensive than protocol hello messages because some of the BFD load can be distributed onto the data plane on supported modules. See the Cisco Nexus 3400-S NX-OS Interfaces Configuration Guide for more information.

HSRP supports stateful restarts and stateful switchovers. A stateful restart occurs when the HSRP process fails and is restarted. A stateful switchover occurs when the active supervisor switches to the standby supervisor. Cisco NX-OS applies the run-time configuration after the switchover.

If HSRP hold timers are configured for short time periods, these timers might expire during a controlled switchover. HSRP supports extended nonstop forwarding (NSF) to temporarily extend these HSRP hold timers during a controlled switchover.

With extended NSF configured, HSRP sends hello messages with the extended timers. HSRP peers update their hold timers with these new values. The extended timers prevent unnecessary HSRP state changes during the switchover. After the switchover, HSRP restores the hold timers to their original configured values. If the switchover fails, HSRP restores the hold timers after the extended hold timer values expire.

See the Configuring Extended Hold Timers for HSRP section for more information.

HSRP supports virtual routing and forwarding (VRF) instances.

• You must enable the HSRP feature in a device before you can configure and enable any HSRP groups.

HSRP has the following configuration guidelines and limitations:

• Configure an IP address for the interface that you configure HSRP on and enable that interface before HSRP becomes active.

• Configure HSRP version 2 when you configure an IPv6 interface for HSRP.

• For IPv4, the virtual IP address must be in the same subnet as the interface IP address.

• We recommend that you do not configure more than one first-hop redundancy protocol on the same interface.

• HSRP version 2 does 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 router.

• You cannot change from version 2 to version 1 if you have configured groups above the allowed group number range for version 1 (0 to 255).

• HSRP for IPv4 is supported with BFD. HSRP for IPv6 is not supported with BFD.

• If HSRP IPv4 and IPv6 use the same virtual MAC address on an SVI, the HSRP state must be the same for both HSRP IPv4 and IPv6. The priority and preemption should be configured to result in the same state after failovers.

• Cisco NX-OS removes all Layer 3 configurations on an interface when you change the interface VRF membership, port channel membership, or the port mode to Layer 2.

• If you configure virtual MAC addresses with vPC, you must configure the same virtual MAC address on both vPC peers.

• You cannot use the HSRP MAC address burned-in option on a VLAN interface that is a vPC member.

• Cisco NX-OS supports having the same HSRP groups on all nodes in a double-sided vPC.

• If you have not configured authentication, the show hsrp command displays the following string:

  Authentication text "cisco"

  The default behavior of HSRP is as defined in RFC 2281:

  If no authentication data is configured, the RECOMMENDED default
  value is 0x63 0x69 0x73 0x63 0x6F 0x00 0x00 0x00.

• The HSRP subnet VIP feature has the following guidelines and limitations:

  • This feature is supported only for IPv4 addresses and only in a vPC topology.

  • Primary or secondary VIPs can be subnet VIPs, but subnet VIPs must not overlap any interface subnet.

  • Regular host VIPs use a mask length of 0 or 32. If you specify a mask length for a subnet VIP, it must be greater than 0 and less than 32.

  • URPF is not supported with this feature.

  • DHCP sourcing with VIPs is also not supported.

  • This feature does not support using a DHCP relay agent to relay DHCP packets with a VIP as the source.

  • VIP direct routes must be explicitly advertised to routing protocols using redistribute commands and route maps.

  • Supervisor-generated traffic (pings, trace routes, and so on) destined for VIP subnets continues to source with SVI IP addresses and not with the VIP.

  • If the subnet VIP is configured with /32 as the length, you must use the no command with /32 to remove the IP address (for example, no ip ip-address/32).

• The following are configuration guidelines to enforce the pre-empt reload timer. The guidelines are listed in order of decreasing preference.

  1. In triangle topologies, we recommend that the HSRP peers are configured within a single VPC domain. This configuration prevents the Spanning-Tree root bridge from changing on the HSRP peer when the Cisco Nexus 3400-S platform switches configuration is reloaded.

  2. Make sure the Spanning Tree root bridge for all VLANs is not on the Cisco Nexus 3400-S platform switches that is being reloaded.

  3. If 1 and 2 are not possible, make sure that the switch has an enabled link for all the SVI VLANs that is connected to another switch that is not the HSRP peer.

The following example shows how to enable HSRP on an interface with MD5 authentication and interface tracking:

key chain hsrp-keys
key 0
key-string 7 zqdest
accept-lifetime 00:00:00 Jun 01 2013 23:59:59 Sep 12 2013
send-lifetime 00:00:00 Jun 01 2013 23:59:59 Aug 12 2013
key 1
key-string 7 uaeqdyito
accept-lifetime 00:00:00 Aug 12 2013 23:59:59 Nov 12 2013
send-lifetime 00:00:00 Sep 12 2013 23:59:59 Nov 12 2013

feature hsrp
track 2 interface ethernet 2/2 ip
interface ethernet 1/2
ip address 192.0.2.2/8
hsrp 1
authenticate md5 key-chain hsrp-keys
priority 90
track 2 decrement 20
ip 192.0.2.10
no shutdown

The following example shows how to configure the HSRP priority on an interface:

interface vlan 1
hsrp 0
preempt
priority 100 forwarding-threshold lower 80 upper 90
ip 192.0.2.2
track 1 decrement 30

This example shows how to configure an HSRP subnet VIP address, which is configured in a different subnet than that of the interface IP address.

sswitch# configure terminal
switch(config)# feature hsrp
switch(config)# feature interface-vlan
switch(config)# interface vlan 2
switch(config-if)# ip address 192.0.2.1/24
switch(config-if)# hsrp 2
switch(config-if-hsrp)# ip 209.165.201.1/24

This example shows how to configure an HSRP subnet VIP address, which is configured in a different subnet than that of the interface IP address.

switch# configure terminal
switch(config)# feature hsrp
switch(config)# feature interface-vlan
switch(config)# interface vlan 2
switch(config-if)# ip address 192.0.2.1/24
switch(config-if)# hsrp 2
switch(config-if-hsrp)# ip 209.165.201.1
!ERROR: VIP subnet mismatch with interface IP!

This example shows a VIP mismatch error when the HSRP subnet VIP address is configured in the same subnet as the interface IP address.

switch# configure terminal
switch(config)# feature hsrp
switch(config)# feature interface-vlan
switch(config)# interface vlan 2
switch(config-if)# ip address 192.0.2.1/24
switch(config-if)# hsrp 2
switch(config-if-hsrp)# ip 192.0.2.10/24
!ERROR: Subnet VIP cannot be in same subnet as interface IP!

For more information related to implementing HSRP, see the following sections: