Hubbry Logo
Hot Standby Router ProtocolHot Standby Router ProtocolMain
Open search
Hot Standby Router Protocol
Community hub
Hot Standby Router Protocol
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Hot Standby Router Protocol
Hot Standby Router Protocol
Hot Standby Router Protocol
View on Wikipedia
from Wikipedia

In computer networking, the Hot Standby Router Protocol (HSRP) is a Cisco proprietary redundancy protocol for establishing a fault-tolerant default gateway. Version 1 of the protocol was described in RFC 2281 in 1998. Version 2 of the protocol includes improvements and supports IPv6 but there is no corresponding RFC published for this version.

The protocol establishes an association between gateways in order to achieve default gateway failover if the primary gateway becomes inaccessible. HSRP gateways send multicast hello messages to other gateways to notify them of their priorities (which gateway is preferred) and current status (active or standby).

Operation

[edit]

The primary router with the highest configured priority will act as a virtual router with a pre-defined gateway IP address and will respond to the ARP or ND request from machines connected to the LAN with a virtual MAC address. If the primary router should fail, the router with the next-highest priority would take over the gateway IP address and answer ARP requests with the same MAC address, thus achieving transparent default gateway failover.

HSRP version IP protocol Group address UDP port Virtual MAC address range
1 IPv4 224.0.0.2 (all routers)[1] 1985 00:00:0c:07:ac:XX
2 IPv4 224.0.0.102 (HSRP)[1] 1985 00:00:0c:9f:fX:XX
IPv6 ff02::66 2029 00:05:73:a0:0X:XX

In the virtual MAC address, Xs represent the group ID in hex.

HSRP is not a routing protocol as it does not advertise IP routes or affect the routing table in any way.[citation needed]

HSRP has the ability to trigger a failover if one or more interfaces on the router go down. This can be useful for dual branch routers each with a single link back to the gateway. If the link of the primary router goes down, the backup router will take over the primary functionality and thus retain connectivity to the gateway.

Version 2

[edit]

Version 2 of the protocol introduces stability, scalability and diagnostic improvements. It is not compatible with version 1 HSRP.[1] There is no RFC for version 2 of the protocol.

  • Provides IPv6 support
  • Increases the number of HSRP groups from 256 to 4096

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Hot Standby Router Protocol

View on Grokipedia
from Grokipedia
The Hot Standby Router Protocol (HSRP) is a proprietary First Hop Redundancy Protocol (FHRP) designed to provide high network availability by enabling transparent of the for IP hosts in the event of a router . It allows multiple routers on a LAN to cooperate as a single virtual router, sharing a common virtual and that hosts use as their , ensuring continuous connectivity without manual intervention. In HSRP operation, routers in a group elect an active router to forward traffic based on priority values (defaulting to 100, with a range of 0-255), while other routers assume standby or listen roles; the active router sends periodic hello messages, and if it fails to do so within the hold time (default 10 seconds for ), the standby router assumes the active role through a process that typically occurs in seconds. This mechanism supports preemption, where a higher-priority router can reclaim the active role after recovery, configurable with delays to avoid instability during network convergence. HSRP groups use addresses for communication—224.0.0.2 for and 224.0.0.102 for version 2—and can be extended for load sharing across multiple groups to distribute traffic among routers. HSRP , described in RFC 2281 as an informational document, supports basic IPv4 with group numbers from 0 to 255 and simple text , while version 2 enhances scalability with millisecond timers, expanded group numbering (0-4095), support, and improved using key chains for enhanced security. Key benefits include rapid recovery from first-hop failures, reduced downtime in enterprise networks, and compatibility with protocols like Object Tracking for interface or route state monitoring to influence priority dynamically. Overall, HSRP remains a foundational for fault-tolerant routing in environments, prioritizing reliability for critical IP traffic.

Introduction

Definition and Purpose

The Hot Standby Router Protocol (HSRP) is a Cisco-proprietary First Hop Redundancy Protocol (FHRP) designed to enable multiple routers on a (LAN) to cooperate and function as a single virtual for end hosts. This protocol allows hosts to maintain a consistent without needing to reconfigure their default routes, even during router failures. The primary purpose of HSRP is to provide and transparent for the first-hop router in IP networks, minimizing by enabling a standby router to assume the role of the active router if the latter fails. In environments such as enterprise LANs with multiple access routers, HSRP ensures continuous connectivity for hosts that rely on static configurations, protecting against single points of failure without disrupting ongoing traffic. While it operates in an active/standby model within each group—limiting true load sharing to configurations using multiple HSRP groups—it supports IPv4 in both versions and extends to in version 2, enhancing redundancy for modern networks. At its core, HSRP achieves this redundancy by assigning a shared and to the routers in a group, which end hosts use as their . The active router in the group responds to ARP requests for the virtual IP using the virtual MAC, forwarding traffic on behalf of the hosts, while the standby router monitors the active one and seamlessly takes over these addresses upon detecting a , ensuring no interruption in gateway services. This mechanism is particularly suited for multi-access LANs like Ethernet, where hosts cannot easily adapt to router changes.

History

The Hot Standby Router Protocol (HSRP) was introduced by in 1998 as a designed to provide gateway redundancy in IP networks, enabling multiple routers to share a virtual and failover seamlessly in the event of a router . Initially developed to address single points of in enterprise LANs, HSRP allowed hosts to use a single while ensuring through an active-standby router election mechanism. The initial specification for HSRP Version 1 was documented in RFC 2281, published in March 1998 as an informational RFC by the (IETF), focusing on IPv4 support and basic capabilities without native integration or advanced authentication. This marked a partial transition from a fully proprietary implementation to a more openly documented standard, though it remained Cisco-specific and did not achieve full IETF standards-track status. HSRP Version 1 quickly gained traction in IOS-based networks for its simplicity in providing first-hop redundancy. HSRP Version 2 was developed in the early and first integrated into Release 12.3(4)T in 2004, introducing enhancements such as support, authentication for improved security, and multicast addressing to replace broadcast hellos, along with expanded scalability through support for up to 4096 group numbers. Unlike , has no corresponding IETF RFC and remains , but it addressed limitations in authentication and network efficiency, facilitating broader adoption in evolving enterprise environments. No major new protocol versions have been released since Version 2, though ongoing enhancements in authentication methods and scalability features have been incorporated into subsequent releases. Subsequent enhancements, such as support for stateful failover and integration with in IOS XE 17.x releases through 2025, have maintained its relevance without introducing new protocol versions. HSRP has been widely adopted in enterprise networks since its inception, integrated deeply into Cisco IOS and IOS-XE platforms to support redundant gateway configurations in data centers and campus environments. Its relevance persists into modern architectures, including software-defined wide area networks (SD-WAN), where Cisco IOS-XE Release 17.x enables HSRP Version 2 configuration and authentication via CLI templates on Catalyst SD-WAN platforms, with support continuing in releases as of 2025.

Protocol Fundamentals

Key Components

The Hot Standby Router Protocol (HSRP) relies on several core components to provide first-hop redundancy in IP networks. The active router is the device responsible for forwarding packets on behalf of the HSRP group, serving as the for hosts until a occurs. The standby router acts as the backup, monitoring the active router and assuming its role if the active fails, ensuring minimal disruption to traffic flow. Together, these form part of the virtual router, a logical entity that shares a and across group members, allowing transparent without host reconfiguration. HSRP groups are identified by a group number, which distinguishes multiple instances on the same interface; in , this ranges from 0 to 255, while version 2 extends it to 0 to 4095. Each router in the group is assigned a priority value, a configurable from 0 to 255 with a default of 100, that influences the election of the active router—the highest priority wins. Preemption is a mechanism that enables a router with a higher priority to reclaim the active after recovering from a , though it is disabled by default to avoid instability during recovery periods. Communication within the HSRP group depends on hello and hold-down timers for heartbeat detection. The hello timer sets the interval for sending multicast hello messages, defaulting to 3 seconds, while the hold-down timer defines the period before declaring the active router unavailable, defaulting to 10 seconds (typically the hello interval). These timers incorporate —up to 20% variation—to prevent synchronization issues in multi-router environments. HSRP hello messages are sent to the multicast address 224.0.0.2 (for HSRP version 1) or 224.0.0.102 (for HSRP version 2). In Cisco hierarchical campus networks, where distribution layer switches often lack direct Layer 2 connectivity (e.g., connected only via Layer 3 links), these multicast hello packets are flooded within the VLAN and traverse trunk links through access layer switches to enable HSRP negotiation between peers. This is expected behavior in such topologies, although it can result in multicast traffic on access ports connected to end devices, particularly with aggressive timers or on older switches without effective multicast filtering.

Virtual Router Concept

In the Hot Standby Router Protocol (HSRP), the virtual router serves as a logical that enables multiple physical routers to function collectively as a single, resilient entity visible to the local area network (LAN). This concept allows end hosts to configure the virtual router's addresses as their , ensuring uninterrupted connectivity without awareness of the underlying physical infrastructure. By emulating a unified router, HSRP masks individual router failures from the network, providing first-hop redundancy at Layer 3. The is a key element of this abstraction, representing a shared gateway IP that is statically configured on hosts within the LAN segment. This address is dynamically "owned" by the active router in the HSRP group, which responds to traffic directed to it, while all group members continuously monitor its availability through protocol messages. In the event of a , the virtual IP seamlessly transfers to the standby router, maintaining consistent routing without requiring host reconfiguration. Complementing the virtual IP, the virtual MAC address follows a standardized format of 0000.0c07.acXX for HSRP version 1, where XX denotes the representation of the HSRP group number (e.g., 0000.0c07.ac01 for group 1). This address is used by the active router to respond to (ARP) requests from hosts and to forward Ethernet frames destined for the virtual IP, ensuring Layer 2 continuity. The tight coupling between the virtual IP and virtual MAC addresses is essential for preserving both Layer 3 and Layer 2 addressing integrity during events. When the active router assumes control, it binds both addresses to its interface, allowing to continue flowing without disruption or the need for ARP table updates on end devices. This integration presents the virtual router as an indivisible single to , effectively concealing physical router outages or maintenance from hosts and upstream devices. However, HSRP's design prioritizes redundancy over load distribution, as only the active router processes for the virtual addresses at any given time, unlike protocols such as Gateway Load Balancing Protocol (GLBP) that enable concurrent utilization of multiple routers for sharing.

Operation

Election Process

In the Hot Standby Router Protocol (HSRP), the election process determines the active and standby routers within a group to ensure redundant first-hop routing. Routers participating in an HSRP group exchange hello packets to advertise their availability and priorities, allowing the group to dynamically select the router best suited to forward traffic. The process begins with an initial election upon group formation or router startup, where the router with the highest priority value—ranging from 0 to 255 with a default of 100—becomes the active router. If multiple routers have equal priorities, the tiebreaker is the highest IP address among the candidates. Hello packets are sent periodically by active and standby routers to maintain group membership and roles, using multicast address 224.0.0.2 in HSRP or 224.0.0.102 in version 2, with a default interval of 3 seconds. These advertisements include the sender's priority and current , enabling other routers to monitor the active router's status. If the active router stops sending hellos, the standby router detects this after the hold timer expires—defaulting to 10 seconds—and assumes the active to trigger , minimizing downtime. In a single-router scenario, that router automatically assumes the active without election, as no competitors exist. In Cisco hierarchical campus networks, access layer switches commonly receive HSRP hello packets from distribution layer switches. HSRP uses multicast packets (destination 224.0.0.2 for version 1 or 224.0.0.102 for version 2) that are flooded within the VLAN for peer communication. In designs where distribution switches lack direct Layer 2 connectivity (e.g., only Layer 3 links between them), these hello packets traverse trunk links through access layer switches to allow HSRP negotiation. This is expected behavior, as HSRP requires Layer 2 connectivity for multicast hello exchange. However, these addresses are in the reserved 224.0.0.0/24 range, so IGMP snooping does not filter them, resulting in multicast flooding on access ports connected to end devices, especially with aggressive timers or on older switches without effective multicast filtering. Preemption allows a router with a higher priority to take over the active from the current active router, provided preemption is explicitly enabled in the configuration. Without preemption, even a higher-priority router joining the group will not displace the active router unless the active fails. In multi-router groups, the election repeats as needed—such as when a new router joins or priorities change—with the highest-priority router becoming active and the next-highest becoming standby; equal-priority scenarios again resolve via comparison during initial election but do not trigger preemption afterward unless priorities differ. This mechanism ensures stable assignment while supporting rapid recovery in dynamic network environments.

State Machine

The Hot Standby Router Protocol (HSRP) employs a to manage the operational lifecycle of routers within a redundancy group, ensuring coordinated and traffic forwarding. This model consists of six distinct states: , Learn, Listen, Speak, Active, and Standby. Each state defines specific behaviors and interactions via periodic advertisements, with transitions triggered by events such as timer expirations or receipt of control messages. In the Initial state, a router enters upon startup, configuration changes, or interface activation, where HSRP is not yet operational and no group information is available. The router remains in this state until it receives sufficient details to progress, such as the virtual IP address, typically learned from hellos. From Initial, it transitions to Learn if the virtual IP is unknown or directly to Listen if the virtual IP is already configured. The Learn state occurs when the router lacks the virtual IP address for the group and awaits an authenticated hello message from the active router to acquire this information. Upon learning the virtual IP, it moves to the Listen state. If no hellos are received within the hold time, it may revert or remain pending. In the Listen state, the router has the virtual IP but is neither active nor standby; it passively monitors hello messages from the active and standby routers without transmitting its own, allowing it to track the group's status. A transition from Listen to Speak happens upon active timer expiration, prompting the router to begin advertising and participate in role election. The Speak state is entered when a router begins sending periodic hello messages to announce its presence and priority, actively participating in the active/standby process while knowing the virtual IP. Routers in Speak continue advertising until the election resolves, at which point the highest-priority router (with ties broken by ) becomes Active, and the next highest becomes Standby; others revert to Listen. The Standby state positions the router as the to the active router, where it sends periodic hellos, monitors the active router via its active , and prepares to assume the active role if needed. If the active router fails, the standby transitions to Active by assuming the virtual IP and MAC addresses for forwarding. The Active state is the operational mode where the router forwards packets destined for the virtual , responds to ARP requests using the virtual IP, and sends periodic hellos to maintain group awareness. Only one router per group can be active, and it relinquishes this role via a resign if preempted by a higher-priority router or upon detecting its own . Transitions out of Active, such as to Speak on hold timer expiration or preemption, trigger the state machine to reevaluate roles among remaining routers. State transitions are governed by key timers that ensure timely detection of changes and prevent instability. The hello timer, defaulting to 3 seconds, prompts routers in Speak, Standby, and Active states to transmit advertisement messages containing the sender's state, priority, and timer values. The hold timer, defaulting to 10 seconds (typically three times the hello interval), sets the active and standby timers to monitor the respective routers; expiration of these timers signals failure and initiates failover transitions, such as from Standby to Active. Additional events like coup messages (for preemption) or resign messages further drive state changes. Recovery paths in the state machine emphasize rapid and restoration. Upon or major disruption, a router restarts in the state and progresses through Learn and Listen as it reacquires group details from ongoing hellos. If the active router fails (detected via hold timer expiration), the standby immediately becomes active, sends a coup message if necessary, and begins forwarding traffic using the virtual addresses, minimizing to the hold timer duration. Preemption allows a higher-priority router entering Speak to transition to Active by sending a coup, forcing the current active to Listen or Standby as appropriate. These mechanisms ensure that post-election roles are dynamically maintained without manual intervention.

Message Formats

HSRP messages are encapsulated in User Datagram Protocol (UDP) datagrams for communication between routers within a standby group. In HSRP version 1, these packets use UDP port 1985 and are sent to the IPv4 multicast address 224.0.0.2 with a time-to-live (TTL) value of 1, ensuring they remain on the local subnet. For HSRP version 2, the IPv4 multicast address changes to 224.0.0.102, while IPv6 support employs UDP port 2029 and link-local multicast addressing with a hop limit of 1. The primary HSRP message type is the Hello packet, which serves as the advertisement for periodic status updates from active and standby routers. In , the fixed-format Hello packet ( 0) includes fields for version, state, timers, priority, group identification, , and the . Its structure is depicted below:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |[Version (1](/page/Version_1) octet)| Op Code (1) | State (1) | Hellotime (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holdtime (1) | Priority (1) | Group (1) | Reserved (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Virtual IP Address](/page/Virtual_IP_address) (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |[Version (1](/page/Version_1) octet)| Op Code (1) | State (1) | Hellotime (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holdtime (1) | Priority (1) | Group (1) | Reserved (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Virtual IP Address](/page/Virtual_IP_address) (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Version field (1 octet) is set to 0 for HSRP version 1. The Op Code field (1 octet) specifies the message type, with 0 indicating a Hello/advertisement, 1 a Coup for preemption attempts, and 2 a Resign for graceful handover. The State field (1 octet) conveys the sender's operational state, such as 16 (Active) or 8 (Standby). Hellotime (1 octet) and Holdtime (1 octet) define the hello interval (default 3 seconds) and hold period (default 10 seconds) in seconds. The Priority field (1 octet) influences active router election, favoring higher values (default 100). The Group field (1 octet) identifies the HSRP group (0-255). The Reserved field (1 octet) is unused and set to 0. Authentication Data (8 octets) provides simple text-based authentication, defaulting to the string "cisco" padded with zeros. The Virtual IP Address field (4 octets) holds the shared IP address for the virtual router. Advertisement messages consist of periodic Hello packets transmitted by the active and standby routers every Hellotime interval, including the and state flags to inform group members of availability and role. The Coup message ( 1) carries the same fields as a Hello but signals a higher-priority router's intent to assume the active role. The Resign message ( 2) uses an identical format to notify the group of the active router's voluntary relinquishment, often with priority set to 0. In HSRP version 2, the message format adopts a Type-Length-Value (TLV) structure for extensibility, incorporating a 6-byte identifier field (typically the sender's interface MAC address) to uniquely identify the originator. Authentication shifts to for enhanced , replacing the simple text method of version 1. Reserved flags are included for potential future extensions, and the format supports virtual addresses.

Versions

HSRP Version 1

HSRP Version 1, defined in RFC 2281 published in March 1998, establishes the foundational implementation of the protocol for providing router redundancy using IPv4 addresses. It enables multiple routers to share a , with one acting as the active router and others in standby roles, through a basic election mechanism based on priority values (default 100, range 0-255) and IP address tiebreakers. The protocol defines six states—Initial, Learn, Listen, Speak, Standby, and Active—and three message types: Hello for advertisements, Coup for priority claims, and Resign for yielding active status. Key features of HSRP Version 1 include exclusive support for IPv4, with hello messages transmitted as multicast packets to the address 224.0.0.2 on UDP port 1985 at 3-second intervals by default, enabling group members to maintain synchronization. Authentication is limited to a simple clear-text 8-character string, padded with nulls if shorter, which is included in all HSRP messages to verify group membership. Group numbers range from 0 to 255, corresponding to the virtual MAC address format 0000.0c07.acXX, where XX is the hexadecimal representation of the group number, ensuring unique identification across Ethernet and other media types. Despite its foundational role, HSRP Version 1 has notable limitations, including no support for addressing and absence of authentication, relying instead on vulnerable plain-text strings that expose the protocol to spoofing attacks. It uses the fixed 224.0.0.2, which can lead to issues in environments with multiple HSRP groups or , as hardware platforms often restrict the number of supported instances—such as a maximum of 32 HSRP groups on or routing interfaces in certain Industrial Ethernet switches. These constraints can hinder scalability in large deployments. Although still widely deployed in legacy IPv4 networks, HSRP Version 1 is recommended for upgrade to Version 2 due to enhanced security features like and broader capabilities, addressing vulnerabilities in the original text-based method.

HSRP Version 2

HSRP Version 2, introduced in Release 12.3(4)T in 2004, introduces several enhancements over Version 1 to improve scalability, security, and compatibility with modern networks. It supports through link-local addressing, enabling the protocol to operate seamlessly in IPv6 environments by using the FF02::66 for hello packets, while retaining IPv4 support via the new 224.0.0.102. Additionally, HSRP Version 2 incorporates , which generates a keyed hash for HSRP packets to protect against unauthorized access and spoofing, a significant upgrade from the plain-text authentication in Version 1. To address scalability limitations in , HSRP Version 2 expands the group number range from 0-255 to 0-4095, allowing for more virtual routers in complex deployments. The virtual format is also updated to 0000.0C9F.FXXX, where XXX represents the group number in , providing a larger and avoiding conflicts with Version 1's 0000.0C07.ACXX format. This redesign ensures better support for large-scale networks without requiring group reconfiguration during version upgrades, as changing versions reinitializes groups due to the new addressing scheme. HSRP Version 2 includes enhancements for finer detection, such as the ability to advertise and learn timer values dynamically, allowing sub-second hello intervals and reducing convergence time compared to static configurations in Version 1. Object tracking, which integrates with HSRP (in both versions) to dynamically adjust router priorities based on the state of monitored objects like interfaces or routes, enables preemptive when issues are detected. Similarly, integration with IP SLA for proactive monitoring of end-to-end connectivity—where SLA probes can trigger priority decrements or failovers upon threshold violations—is a general HSRP capability that enhances reliability in dynamic environments. In contemporary deployments, HSRP Version 2 is integrated into platforms running IOS XE (since Release 17.7.x in 2021), supporting configuration via CLI templates on Catalyst devices and improving interoperability in hybrid and branch networks. This evolution maintains within v2 implementations while addressing Version 1's constraints in diverse, high-availability scenarios.

Configuration

Basic Configuration

The Hot Standby Router Protocol (HSRP) is configured on devices using interface-level commands to enable redundancy for IPv4 traffic. To set up a basic HSRP group, enter interface configuration mode and specify the standby group number and , which acts as the shared for connected hosts. The command standby [group-number] ip [virtual-ip-address] enables HSRP version 1 by default on the interface and assigns the virtual IP; the group number (0 to 255) identifies the HSRP group, and omitting it defaults to group 0. By default, HSRP uses a priority of 100 for all routers in the group, with the highest priority router becoming active; ties are broken by the highest . To influence the active router , configure standby [group-number] priority [value] (1 to 255) on the desired router. Preemption is disabled by default, meaning a higher-priority router will not automatically take over if it joins after the active router is elected; hello timers default to 3 seconds, and hold timers to 10 seconds. defaults to text mode with the string "cisco," providing basic protection against misconfiguration. For verification, use the show standby command to display group details, including the local and virtual IP addresses, current state (e.g., Active or Standby), priority, and timers. The show standby [interface] variant provides interface-specific output, confirming the active router and virtual IP assignment. In a simple lab setup with two routers connected via a LAN (e.g., GigabitEthernet0/0 on each), configure HSRP group 1 sharing virtual IP 192.168.1.1/24. On Router1 (intended active, IP 192.168.1.2/24):

interface GigabitEthernet0/0 ip address 192.168.1.2 255.255.255.0 standby 1 ip 192.168.1.1 standby 1 priority 110

interface GigabitEthernet0/0 ip address 192.168.1.2 255.255.255.0 standby 1 ip 192.168.1.1 standby 1 priority 110

On Router2 (standby, IP 192.168.1.3/24):

interface GigabitEthernet0/0 [ip address](/page/IP_address) 192.168.1.3 255.255.255.0 standby 1 ip 192.168.1.1

interface GigabitEthernet0/0 [ip address](/page/IP_address) 192.168.1.3 255.255.255.0 standby 1 ip 192.168.1.1

After configuration, show standby on Router1 should show it as Active with virtual IP 192.168.1.1, while Router2 appears as Standby.

Advanced Configuration

Advanced HSRP configurations enhance reliability and flexibility by incorporating features such as to secure group communications, interface tracking for dynamic priority adjustments, customizable timers for fine-tuned timing, preemption to ensure the highest-priority router assumes the active role, support for modern networks, and integration with IP (IP SLA) for proactive monitoring and . Authentication in HSRP prevents unauthorized routers from joining the group; for HSRP version 1, simple text-based authentication is configured using the command standby [group] authentication [text], where the text string (up to eight characters) is sent unencrypted in hello messages. In HSRP version 2, more secure MD5 authentication is supported via standby [group] authentication md5 key-string [0 | 7] [key] [timeout seconds] for a static key or standby [group] authentication md5 key-chain [key-chain-name] for rotating keys defined in a key chain. Interface tracking allows HSRP to respond to upstream link failures by monitoring interface states and adjusting the priority accordingly; the command track [object-number] interface [type] [number] {line-protocol | ip routing} creates a tracked object, followed by standby [group] track [object-number] [decrement priority-decrement] to reduce the priority (e.g., by 20) if the tracked interface goes down. For example:

track 100 interface GigabitEthernet0/0/0 line-protocol standby 1 track 100 decrement 20

track 100 interface GigabitEthernet0/0/0 line-protocol standby 1 track 100 decrement 20

This setup ensures the router with a failed upstream interface yields active status to the standby router. Timer adjustments optimize convergence by setting custom hello and hold intervals; the command standby [group] timers [msec] [hello] [msec] [hold] allows specification in seconds or milliseconds (the latter supported in version 2), with defaults of 3 seconds for hello and 10 seconds for hold. A typical configuration for faster detection might be:

standby 1 timers msec 200 msec 700

standby 1 timers msec 200 msec 700

This reduces hello to 200 ms and hold to 700 ms, enabling quicker while avoiding excessive CPU usage. ensures the router with the highest priority becomes active after recovery; it is enabled with standby [group] preempt [delay {minimum | reload | sync} seconds], where the optional delay (default 0 seconds) prevents immediate preemption during unstable periods, such as after a reload. For instance:

standby 1 preempt delay minimum 30

standby 1 preempt delay minimum 30

This delays preemption by 30 seconds minimum, allowing the network to stabilize. HSRP version 2 extends support to IPv6 networks by providing a virtual IPv6 link-local address; configuration begins with standby version 2 on the interface, followed by standby [group] ipv6 autoconfig for automatic configuration of a virtual link-local address, or standby [group] ipv6 [ipv6-address] to specify a virtual IPv6 address (link-local or global). An example for autoconfiguration of the virtual address is:

interface GigabitEthernet0/0 ipv6 address 2001:DB8:1::1/64 standby version 2 standby 1 ipv6 autoconfig standby 1 priority 110 standby 1 preempt

interface GigabitEthernet0/0 ipv6 address 2001:DB8:1::1/64 standby version 2 standby 1 ipv6 autoconfig standby 1 priority 110 standby 1 preempt

This setup uses the same priority and preemption mechanisms as IPv4, with the virtual MAC address in the range 0005.73A0.0000 to 0005.73A0.0FFF. For proactive failover beyond local interfaces, HSRP integrates with IP SLA through enhanced object tracking; first, define an IP SLA operation (e.g., ICMP echo) with ip sla [monitor] [number] and schedule it via ip sla schedule [number] life forever start-time now, then create a track object with track [number] ip sla [sla-number] reachability, and link it to HSRP using standby [group] track [track-number] decrement [value]. This allows HSRP to decrement priority if remote reachability fails, triggering failover without waiting for local detection.

Comparisons with Other Protocols

HSRP vs. VRRP

The Hot Standby Router Protocol (HSRP) and (VRRP) are both first-hop redundancy protocols designed to provide gateway redundancy in IP networks, but they differ significantly in their origins, implementation, and applicability. HSRP is a Cisco-proprietary protocol, while VRRP is an developed by the IETF. These differences influence their use in various network environments, particularly regarding vendor compatibility and feature sets.
AspectHSRPVRRP
StandardsCisco proprietary; versions 1 and 2 defined in Cisco documentation.IETF standard; VRRPv2 in RFC 3768, VRRPv3 in RFC 5798 (obsoleted by RFC 9568).
Election and RolesUses priority (default 100, range 0-255 in v1, 0-4095 in v2) and IP address tiebreaker; roles include Active (forwards traffic), Standby (takes over on failure), and Listen (monitors). Both Active and Standby send hello messages. Preemption is disabled by default.Uses priority (default 100, range 1-254 for backups, 255 for address owner) and IP address tiebreaker; roles are Master (forwards traffic, sends advertisements) and (monitors, takes over on failure). Only Master sends advertisements; no dedicated "Standby" role. Preemption is enabled by default.
Virtual MAC Addressv1: 0000.0C07.ACxx (xx = group number in hexadecimal); v2: 0000.0C9F.Fxxx (xxx = group number in hexadecimal).0000.5E00.01XX for IPv4 (XX = VRID in hexadecimal); 0000.5E00.02XX for IPv6.
Authenticationv1 supports plain-text; v2 supports (using key string or key chain) for enhanced security against spoofing.v2 supports plain-text or ; v3 does not support authentication (fields set to zero). Relies on TTL=255 for basic protection.
InteroperabilityLimited to devices; no native support for non- routers.Vendor-agnostic with multi-vendor support, enabling deployment across diverse hardware.
In terms of election and roles, both protocols elect the forwarding router based on the highest priority value, with ties broken by the highest of the router interface. However, HSRP's inclusion of a dedicated Standby role allows for more explicit hot standby behavior, where the Standby router is ready to immediately assume the Active role upon failure detection via hello timeouts (default 3 seconds hello, 10 seconds hold). In contrast, VRRP's routers remain passive until the Master fails, with only the Master advertising its presence (default 1 second interval), which can lead to faster convergence in some scenarios but requires careful timer synchronization across all participants. The virtual MAC addressing schemes further highlight their distinct designs: HSRP's Cisco-specific formats ensure seamless integration within Cisco ecosystems but limit portability, while VRRP's standardized IANA-assigned prefixes (from the 00-00-5E range) facilitate consistent behavior across bridges and switches from different vendors. Authentication in HSRP v2 provides robust protection for protocol messages, making it suitable for environments requiring strong integrity checks, whereas VRRP's authentication is legacy in v2 implementations and absent in v3, emphasizing its focus on simplicity and standards compliance over proprietary security extensions. Interoperability is a key differentiator, as HSRP's nature restricts it to Cisco-only deployments, potentially complicating expansions in mixed environments. VRRP, being an open protocol, supports seamless operation among routers from multiple vendors, such as , , and others, making it the preferred choice for heterogeneous networks. For use cases, HSRP excels in all- infrastructures where advanced features like object tracking and timers enhance reliability without concerns. VRRP is ideal for multi-vendor setups requiring standardized redundancy, such as in or enterprise networks prioritizing broad compatibility over Cisco-specific optimizations.

HSRP vs. GLBP

The Hot Standby Router Protocol (HSRP) and Gateway Load Balancing Protocol (GLBP) are both Cisco-proprietary first-hop redundancy protocols designed to provide gateway redundancy in IP networks, but they differ significantly in their approach to traffic handling and resource utilization. HSRP operates on an active/standby model, where a single active router forwards all traffic for the virtual IP address while standby routers remain idle until failover occurs, offering no inherent load sharing across multiple routers. In contrast, GLBP employs an active/active model through its Active Virtual Gateway (AVG) and Active Virtual Forwarder (AVF) roles, enabling load balancing by distributing traffic across multiple routers using a single virtual IP address. A key distinction lies in how each protocol elects and weights gateways for traffic distribution. HSRP relies solely on priority values (ranging from 0 to 255) to determine the active router, with no mechanism for fine-tuning load distribution beyond creating multiple HSRP groups for manual load sharing. GLBP, however, incorporates a weighting system (default 100, adjustable from 1 to 255) for AVFs, which influences the proportion of traffic each forwarder handles based on interface or tracked object capacity, allowing for more dynamic and efficient utilization of available routers. Additionally, HSRP uses a single virtual MAC address per group (prefixed with 0000.0c07.ac), shared among all routers, whereas GLBP generates multiple virtual MAC addresses (up to four per group, prefixed with 0007.b400) to assign unique forwarders to clients via ARP replies, facilitating true load balancing. Both protocols support rapid , with default hello intervals of 3 seconds and hold times of 10 seconds, but timers can be tuned (e.g., to 50 ms hello and 150 ms hold) for sub-second convergence in either case; however, GLBP's design ensures better overall utilization by keeping multiple routers active, reducing the impact of a single failure on traffic throughput. Introduced in Release 12.2(14)S and 12.2(15)T around 2003, GLBP is often viewed as an of HSRP, extending with load-balancing capabilities while maintaining compatibility in environments.
AspectHSRPGLBP
Core FunctionalityActive/standby ; no native load sharing.Active/active with load balancing via AVG/AVF roles.
Election MechanismPriority (0-255) for active router selection.Priority for AVG; weighting (1-255) for AVF traffic distribution.
Virtual MACsSingle shared MAC per group.Multiple MACs (up to 4) per group for client distribution.
FailoverStandby assumes role; sub-second possible with tuned timers.AVF reassignment or standby VG ; sub-second possible, better multi-router utilization.
Use CasesSimple in low-traffic networks.Load distribution in high-traffic LANs with multiple gateways.
HSRP suits environments requiring straightforward without the complexity of load balancing, such as small with minimal gateway demands, while GLBP is preferable for larger, high-traffic LANs where maximizing router efficiency and even traffic distribution enhance and .

Security Considerations

Vulnerabilities

HSRP Version 1 employs clear-text , which exposes the authentication string in within protocol packets, making it susceptible to sniffing attacks where an eavesdropper on the same LAN segment can capture and replay the credentials to spoof legitimate routers. This weakness allows unauthorized devices to join the HSRP group and disrupt operations, as the protocol lacks robust verification mechanisms in its initial implementation. Even HSRP Version 2, which upgrades to MD5-based , remains vulnerable to offline brute-force attacks if weak or predictable keys are used, given MD5's known cryptographic flaws that enable rapid dictionary or assaults on captured packets. Rogue router attacks exploit HSRP's priority-based election mechanism, where an attacker on the local can transmit forged Hello messages with a higher priority value than legitimate routers, causing the malicious device to be elected as the active router and redirecting all through it for potential or blackholing. This vector leverages the protocol's nature on group address 224.0.0.2, allowing easy injection of packets without initial in unsecured deployments. Denial-of-service (DoS) attacks can be mounted by flooding the network with excessive HSRP Hello packets, overwhelming router CPU resources as devices process the traffic and potentially triggering repeated failovers that destabilize the virtual IP assignment. Such floods exploit the protocol's default three-second Hello interval, amplifying impact in shared LAN environments where propagation is uncontrolled. Man-in-the-middle (MITM) attacks on HSRP often involve ARP poisoning targeted at the protocol's virtual MAC address (0000.0c07.acXX, where XX is the group number), enabling an attacker to associate their own MAC with the virtual IP and intercept traffic destined for the active router. This technique subverts host ARP caches, allowing unauthorized access to routed packets without altering HSRP state directly. Several (CVEs) highlight HSRP's risks, including CVE-2014-3295, where malformed HSRP packets in allow authentication bypass and subsequent DoS by crashing the authentication process on affected series devices running versions prior to 6.2(6). Similarly, CVE-2019-1761 affects and IOS XE Software in versions such as 15.1(3)S through 15.9(3)M, where uninitialized in HSRPv2 packets allows adjacent attackers to obtain sensitive configuration data due to improper memory handling.

Best Practices

To ensure secure and reliable operation of the Hot Standby Router Protocol (HSRP), authentication must always be enabled on all groups. For HSRP version 2, MD5 authentication is recommended, utilizing strong keys that are regularly rotated to protect against spoofing attacks. HSRP version 1 should be avoided in production environments due to its limited security features compared to version 2. Network segmentation plays a critical role in securing HSRP deployments by isolating traffic. Access Control Lists (ACLs) should be applied to HSRP interfaces to restrict hellos and other protocol packets to authorized devices only, preventing unauthorized access or interference from external sources. Effective monitoring and logging are essential for maintaining HSRP availability. Configure SNMP traps to alert on state changes, such as transitions to active or standby, enabling proactive issue detection through network management systems. Regularly execute the "show standby" command during routine checks to verify group status, priorities, and timers across interfaces. In redundancy design, deploying multiple HSRP groups per allows for load balancing while maintaining capabilities, ensuring more efficient utilization of router resources. Enable preemption on the preferred active router, incorporating a delay to avoid unnecessary during network convergence. Integrate HSRP with IP SLA for enhanced reliability, where SLA probes trigger priority adjustments or failovers based on upstream link health. For upgrades, migrate to HSRP version 2 to support addressing and improved security mechanisms, including extended group numbering and separation. Always test scenarios in a laboratory environment prior to production deployment to validate configuration and recovery times. As of 2025, align HSRP implementations with best practices for environments integrating services, where HSRP provides first-hop alongside SD-WAN overlays for seamless in hybrid networks.

References

  1. https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/system-interface/ios-xe-17/systems-interfaces-book-xe-sdwan/m-hot-standby-router-protocol.html
  2. https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/9234-hsrpguidetoc.html
  3. https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/9281-3.html
  4. https://www.rfc-editor.org/rfc/rfc2281
  5. https://datatracker.ietf.org/doc/html/rfc2281
  6. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/software/release/17-12/configuration_guide/ip/b_1712_ip_9400_cg/configuring___hsrp.html
  7. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-16/fhp-xe-16-book/fhp-hsrp-v2.html
  8. https://datatracker.ietf.org/doc/html/rfc2281#section-6.1
  9. https://datatracker.ietf.org/doc/html/rfc2281#section-1
  10. https://www.rfc-editor.org/rfc/rfc2281.html
  11. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhp-hsrp-v2.html
  12. https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_fhp-hsrp-0.html
  13. https://packetpushers.net/blog/ccnp-studies-configuring-hsrp-part-two/
  14. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhp-hsrp-v2.pdf
  15. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/unicast/503_u1_2/nexus3000_unicast_config_gd_503_u1_2/l3_hsrp.html
  16. https://www.cisco.com/c/en/us/td/docs/switches/metro/me3400e/software/release/12-2_58_ez/configuration/guide/Book_ME3400e/swhsrp.pdf
  17. https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10559-22.html
  18. https://community.cisco.com/t5/switching/hsrp-multicasts-are-flooding-my-switchports/td-p/2348311
  19. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-sy/fhp-15-sy-book/HSRP-for-IPv6.pdf
  20. https://www.kb.cert.org/vuls/id/228186
  21. https://www.cisco.com/c/en/us/td/docs/switches/connectedgrid/cg-switch-sw-master/software/configuration/guide/availability/Availability/red_hsrp.html
  22. https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_fhp-hsrp-md5.html
  23. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/unicast/521_N11/cisco_n5k_layer3_ucast_cfg_rel_521_N1_1/l3_hsrp.pdf
  24. https://arshamblog.ir/hsrp-v1-vs-hsrp-v2/
  25. https://networklessons.com/ip-services/hsrp-hot-standby-routing-protocol
  26. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-sy/fhp-15-sy-book/fhp-hsrp.html
  27. https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/113216-ipv6-hsrp-00.html
  28. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-16/fhp-xe-16-book/fhp-hsrp.html
  29. https://datatracker.ietf.org/doc/html/rfc5798
  30. https://datatracker.ietf.org/doc/html/rfc9568
  31. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-16/fhp-xe-16-book/fhp-hsrp-md5.html
  32. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/fhrp-vrrpv3.pdf
  33. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-mt/fhp-15-mt-book/Configuring-GLBP.html
  34. https://www.giac.org/paper/gcih/239/security-ip-routing-protocols/102313
  35. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/15-sy/fhp-15-sy-book/fhp-hsrp-md5.pdf
  36. https://isc.sans.edu/diary/10120
  37. https://www.exploit-db.com/exploits/20821
  38. https://quickview.cloudapps.cisco.com/quickview/bug/CSCup11309
  39. https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html
  40. https://www.cisco.com/c/en/us/support/docs/csa/Cisco-SA-20140611-CVE-2014-3295.html
  41. https://nvd.nist.gov/vuln/detail/CVE-2019-1761
  42. https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/104x/unicast-routing-configuration/cisco-nexus-9000-series-nx-os-unicast-routing-configuration-guide/m_configuring_hsrp.html
  43. https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/10583-62.html
  44. https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/13506-snmp-traps.html
  45. https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_fhp-hsrp-mib.html
  46. https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_fhp-hsrp-mgo.html
  47. https://community.cisco.com/t5/routing/hsrp-to-provide-redundancy-in-a-multihomed-bgp-network-with-ip/td-p/5016106
  48. https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ntw-servs/b-network-services/m_ip6-fhrp-hsrp-xe.html
  49. https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie3X00/software/17_4/b_redundancy_17-4_iot_switch_cg/m-ip-hsrp-cg.html
Add your contribution
Related Hubs
User Avatar
No comments yet.