LogoENEnglish

First Hop Redundancy Protocols: HSRP, VRRP, and GLBP Explained

Every host on a network relies on a single default gateway, and that gateway becoming a single point of failure would undermine the redundancy carefully built everywhere else in the network. This article explains why first hop redundancy matters, walks through HSRP's active/standby model, compares it against the open-standard VRRP, and covers GLBP's added ability to load-balance traffic across multiple routers simultaneously.

HSRP ConfigurationVRRPGLBP Load Balancing

~6 دقیقه مطالعه · آخرین به‌روزرسانی ۲۰ شهریور ۱۴۰۵

Why the Default Gateway Is a Critical Single Point of Failure

Every host on a subnet is configured with a single default gateway address, discussed earlier in this series regarding IP routing, used to reach any destination outside its local subnet. Even with fully redundant routing protocols like OSPF and EIGRP, discussed earlier in this series, providing multiple paths through the network, if the specific router acting as a host's default gateway fails, that host has no way to reach anything beyond its local subnet — its statically configured gateway address simply stops responding.

The Core Idea: A Shared Virtual Gateway Address

First Hop Redundancy Protocols (FHRPs) solve this by allowing two or more physical routers to share a single Virtual IP Address (and virtual MAC address) that hosts are configured to use as their default gateway, with the protocol determining which physical router actually forwards traffic sent to that virtual address at any given moment.

Conceptual FHRP setup:

Router A (physical IP: 192.168.1.2)
Router B (physical IP: 192.168.1.3)
Virtual IP (shared): 192.168.1.1

Hosts are configured with default gateway
192.168.1.1 -- they never need to know or care
which physical router is currently handling
that address

HSRP: Cisco's Active/Standby Protocol

HSRP (Hot Standby Router Protocol) is a Cisco-proprietary FHRP using a simple active/standby model: one router actively forwards all traffic for the virtual IP, while one or more standby routers wait to take over if the active router fails.

Router A (config)# interface gigabitethernet 0/1
Router A (config-if)# ip address 192.168.1.2 255.255.255.0
Router A (config-if)# standby 1 ip 192.168.1.1
Router A (config-if)# standby 1 priority 110
Router A (config-if)# standby 1 preempt

Router B (config)# interface gigabitethernet 0/1
Router B (config-if)# ip address 192.168.1.3 255.255.255.0
Router B (config-if)# standby 1 ip 192.168.1.1
Router B (config-if)# standby 1 priority 100

The router with the higher priority (Router A at 110, versus Router B's default of 100) becomes the active router. The preempt keyword is essential and easy to forget: without it, if Router A fails and Router B takes over, Router A will not reclaim the active role when it comes back online, even though it has the higher configured priority — traffic would continue flowing through the lower-priority router indefinitely until a manual intervention or another failure.

HSRP States

Initial:  the starting state before HSRP begins
Learn:    the router does not yet know the
          virtual IP address
Listen:   the router knows the virtual IP but is
          neither active nor standby
Speak:    the router participates in the election
          process, sending and receiving hellos
Standby:  the router is the designated backup,
          ready to take over immediately
Active:   the router is currently forwarding
          traffic for the virtual IP

Verifying HSRP Status

Router A# show standby brief

Interface  Grp  Pri P State   Active         Standby        Virtual IP
Gi0/1      1    110 P Active  local          192.168.1.3    192.168.1.1

This output confirms exactly what should be expected: Router A shows itself as Active with the higher priority of 110, and correctly identifies Router B as the current standby — any unexpected state here, such as both routers claiming to be active simultaneously, points directly to a misconfiguration or a connectivity problem between the two routers preventing hello messages from being exchanged.

VRRP: The Open-Standard Alternative

VRRP (Virtual Router Redundancy Protocol) serves the identical purpose as HSRP but is a vendor-neutral open standard, making it the correct choice whenever a redundancy group needs to include non-Cisco equipment — directly analogous to the LACP-versus-PAgP choice discussed earlier in this series regarding EtherChannel.

Router A(config)# interface gigabitethernet 0/1
Router A(config-if)# vrrp 1 ip 192.168.1.1
Router A(config-if)# vrrp 1 priority 110

-- VRRP terminology differs slightly from HSRP:
-- the active router is called "Master" rather
-- than "Active," and standby routers are called
-- "Backup" rather than "Standby" -- functionally
-- nearly identical to HSRP, but this vocabulary
-- distinction matters when reading documentation
-- or troubleshooting output

One meaningful technical distinction: VRRP allows the virtual IP address to actually be one of the physical routers' own real interface addresses, rather than always requiring a separate dedicated virtual address as HSRP does — a subtle difference that occasionally simplifies migration scenarios.

GLBP: Adding Load Balancing to the Mix

Both HSRP and VRRP share a notable inefficiency: only the single active/master router ever forwards traffic, leaving any standby routers' bandwidth capacity completely unused during normal operation. GLBP (Gateway Load Balancing Protocol), another Cisco-proprietary protocol, solves this by allowing multiple routers to simultaneously forward traffic for the same virtual IP.

Router A(config-if)# glbp 1 ip 192.168.1.1
Router A(config-if)# glbp 1 priority 110

-- GLBP elects one "Active Virtual Gateway" (AVG)
-- responsible for responding to ARP requests
-- for the virtual IP, but the AVG can hand out
-- DIFFERENT virtual MAC addresses to different
-- hosts, each pointing to a different physical
-- router -- this is what actually distributes
-- the forwarding load across multiple routers
-- simultaneously, unlike HSRP/VRRP's single
-- active forwarder

The clever mechanism behind GLBP's load balancing is entirely at the ARP response level: when different hosts ARP for the same virtual IP's MAC address, discussed earlier in this series regarding address resolution, the AVG can respond with different virtual MAC addresses to different hosts, transparently spreading which physical router each host's traffic actually flows through, all while every host still believes it is using the exact same single default gateway address.

Comparing the Three Protocols

HSRP:
  - Cisco-proprietary
  - Active/Standby only -- one router forwards at a time
  - Widely deployed, well-understood, simple

VRRP:
  - Open standard, vendor-neutral
  - Active/Backup only -- one router forwards at a time
  - Correct choice for mixed-vendor environments

GLBP:
  - Cisco-proprietary
  - True load balancing -- multiple routers forward
    simultaneously
  - More complex, but makes full use of all
    available router bandwidth rather than
    leaving standby capacity idle

Why FHRPs Are a Standard Requirement in Enterprise Design

First hop redundancy is considered a baseline requirement in virtually every enterprise network design, since a redundant core and distribution layer, discussed throughout this series regarding routing protocols and Spanning Tree, provides little practical benefit if every single host still depends on one specific router as an unprotected single point of failure. Understanding the trade-offs between HSRP's simplicity, VRRP's vendor neutrality, and GLBP's load-balancing capability is essential for selecting the right protocol for a given network's specific redundancy and bandwidth-utilization requirements.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

ادامه

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

ادامه

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

ادامه

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

ادامه

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

ادامه

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

ادامه
مقاله‌ی قبلیمقاله‌ی بعدی