FHRP Comparison — HSRP vs VRRP vs GLBP: Configuration, Load Balancing & Failover

Every host on a subnet needs a default gateway — a single IP address it sends all off-subnet traffic to. If that gateway router fails, all hosts on the segment lose connectivity until they are manually reconfigured or the router recovers. This single point of failure is unacceptable in any network that requires high availability. First Hop Redundancy Protocols (FHRPs) solve this by allowing two or more physical routers to collectively present a single virtual IP address and virtual MAC address to hosts. The hosts configure the virtual IP as their default gateway and are completely unaware of which physical router is currently serving requests. When one router fails, another takes over the virtual IP and virtual MAC within seconds — hosts continue forwarding traffic without any reconfiguration.

Three protocols dominate this space on Cisco networks, each with distinct design philosophies and capabilities. HSRP (Hot Standby Router Protocol) is Cisco proprietary, battle-tested, and simple — one active router handles all traffic while standby routers wait idle. VRRP (Virtual Router Redundancy Protocol) is the open-standard equivalent of HSRP, supported by all vendors, with the added ability to use the physical interface IP as the virtual IP when the router is the owner. GLBP (Gateway Load Balancing Protocol) is Cisco proprietary and the most sophisticated of the three — it actively load-balances traffic across all routers simultaneously, making full use of all available bandwidth rather than leaving standby routers idle. For an overview of all three, see VRRP and GLBP and HSRP.

For the switching infrastructure that FHRPs operate over see VLAN and Trunking Configuration and Private VLAN Configuration. For IP SLA-based tracking that drives FHRP preemption decisions see IP SLA Configuration & Tracking. For the routing protocols that FHRPs work alongside see OSPF Configuration.

1. HSRP vs VRRP vs GLBP — Side-by-Side Comparison

Feature	HSRP (v1 / v2)	VRRP (v2 / v3)	GLBP
Standard	Cisco proprietary	Open standard (RFC 2338 / RFC 5798)	Cisco proprietary
Terminology	Active / Standby / Listen	Master / Backup	AVG (Active Virtual Gateway) / AVF (Active Virtual Forwarder)
Virtual IP	Separate from all physical IPs — must not match any interface IP	Can be the same as the Master router's physical interface IP (IP owner)	Separate virtual IP managed by AVG; each AVF has its own virtual MAC
Virtual MAC format	HSRPv1: 0000.0c07.acXX (XX = group); HSRPv2: 0000.0c9f.fXXX	0000.5e00.01XX (XX = VRID in hex)	0007.b400.XXYY (XX = group, YY = forwarder number 01–04)
Group number range	HSRPv1: 0–255; HSRPv2: 0–4095	VRID 1–255 (both v2 and v3)	0–1023
Load balancing	No — only the Active router forwards. Standby is idle. Load balancing requires multiple groups with different active routers per group.	No — only the Master forwards. Same approach as HSRP for load balancing (multiple VRIDs).	Yes — native. All AVF routers forward traffic simultaneously. Hosts receive different virtual MACs from the AVG via ARP, distributing load across routers.
Load-balancing methods (GLBP)	N/A	N/A	Round-robin (default), Weighted (by configured weight), Host-dependent (same host always gets same AVF)
Election criterion	Highest priority (default 100); tie-break: highest interface IP	Highest priority (default 100); tie-break: highest interface IP. IP owner always wins (priority 255).	AVG: highest priority (default 100), tie-break: highest IP. AVFs: all routers become AVFs after AVG election.
Preemption	Disabled by default — must enable with `standby [grp] preempt`	Enabled by default — a higher-priority router automatically takes over as Master	AVG preemption disabled by default (same as HSRP). AVF preemption configurable.
Hello / Hold timers	Hello: 3s, Hold: 10s (default). Configurable in seconds or milliseconds.	Advertisement interval: 1s, Master down interval: 3× advertisement + skew. Configurable.	Hello: 3s, Hold: 10s (default). Same as HSRP.
Multicast address	HSRPv1: 224.0.0.2; HSRPv2: 224.0.0.102	224.0.0.18	224.0.0.102
Authentication	Plain text or MD5	Plain text (v2); MD5 / SHA (v3)	Plain text or MD5
IPv6 support	HSRPv2 only	VRRPv3 (RFC 5798)	Yes (extended with additional config)
Max routers per group	Unlimited (1 active, 1 standby, rest listen)	Unlimited (1 master, rest backup)	Up to 4 AVFs per group (practical limit)
Best use case	Simple redundancy, Cisco-only environments, widespread compatibility	Multi-vendor environments, open-standard requirement, IPv6 deployment	Maximum bandwidth utilisation — all routers active simultaneously, true load balancing without multiple groups

FHRP State Machines

  HSRP STATES:
  Initial → Learn → Listen → Speak → Standby → Active
    Initial:  HSRP not yet started on the interface
    Learn:    Waiting to hear virtual IP from active router
    Listen:   Knows virtual IP; not active or standby
    Speak:    Sending Hello messages, participating in election
    Standby:  Ready to take over if Active fails
    Active:   Forwarding traffic for the virtual IP/MAC

  VRRP STATES (simpler):
  Initialize → Backup → Master
    Initialize: VRRP not running (interface down or config incomplete)
    Backup:     Monitoring Master; ready to take over
    Master:     Forwarding traffic; sending advertisements

  GLBP STATES (per role):
  AVG states: Initial → Listen → Speak → Standby → Active
  AVF states: Disabled → Initial → Listen → Active
    AVG Active:     Managing virtual IP; responding to ARP; assigning virtual MACs
    AVF Active:     Forwarding traffic for its assigned virtual MAC
    AVF Listen:     Elected AVF but waiting — will take over if current AVF fails

The key GLBP insight: In HSRP and VRRP, the virtual group has one virtual MAC — all traffic goes to the single active/master router. Load balancing requires configuring multiple groups with different active routers per group (and configuring different default gateways on hosts, or using DHCP to assign different gateways per subnet). GLBP achieves true load balancing with a single virtual IP: the AVG responds to ARP requests with different virtual MACs (one per AVF) in round-robin or weighted order. Each host gets a different MAC and therefore sends traffic to a different physical router. No multiple groups, no multiple virtual IPs needed.

2. Lab Topology

                              INTERNET / CORE
                         ┌────────────┬────────────┐
                         │            │            │
                    Gi0/1│       Gi0/1│       Gi0/1│
               ┌─────────┴──┐ ┌──────┴─────┐ ┌───┴──────────┐
               │ NetsTuts_R1│ │NetsTuts_R2 │ │ NetsTuts_R3  │
               │ 10.0.0.1   │ │ 10.0.0.2   │ │ 10.0.0.3     │
               └────┬────────┘ └──────┬─────┘ └───┬──────────┘
                    │  Gi0/0          │ Gi0/0      │ Gi0/0
                    └────────────┬────┴────────────┘
                                 │
                    ┌────────────┴───────────────────┐
                    │        LAN Segment              │
                    │    10.0.0.0/24                  │
                    │                                 │
                    │  HSRP Group 1:  VIP 10.0.0.10   │
                    │  VRRP Group 1:  VIP 10.0.0.20   │
                    │  GLBP Group 1:  VIP 10.0.0.30   │
                    │                                 │
                    ├──────────────┬──────────────────┤
               PC-A (10.0.0.101)  PC-B (10.0.0.102)  PC-C (10.0.0.103)
               GW: 10.0.0.10      GW: 10.0.0.20      GW: 10.0.0.30
               (HSRP)             (VRRP)              (GLBP)

  FHRP PRIORITIES:
    R1: HSRP priority 110 (Active), VRRP priority 110 (Master), GLBP priority 110 (AVG)
    R2: HSRP priority 100 (Standby), VRRP priority 100 (Backup), GLBP priority 100 (AVF)
    R3: HSRP priority 90 (Listen), VRRP priority 90 (Backup), GLBP priority 90 (AVF)

3. Step 1 — HSRP Configuration (Reference Baseline)

HSRP is configured first as the reference protocol — its syntax and behaviour forms the baseline for comparing VRRP and GLBP. HSRP is configured under the interface using the standby keyword.

R1 — HSRP Active Router (Priority 110)

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ip address 10.0.0.1 255.255.255.0
NetsTuts_R1(config-if)#no shutdown

! ── HSRP Group 1 configuration ───────────────────────────────────
NetsTuts_R1(config-if)#standby version 2
!                       ^^^^^^^^^^^^^^^^
!                  Use HSRPv2 (group 0–4095, millisecond timers,
!                  IPv6 support, better MAC range)

NetsTuts_R1(config-if)#standby 1 ip 10.0.0.10
!                                ^ ^^^^^^^^^^
!                           group  virtual IP

NetsTuts_R1(config-if)#standby 1 priority 110
!                                          ^^^
!                         R1 highest priority → becomes Active

NetsTuts_R1(config-if)#standby 1 preempt
!                                ^^^^^^^
!                         R1 reclaims Active role if it recovers
!                         after a failure (preemption disabled by default)

NetsTuts_R1(config-if)#standby 1 preempt delay minimum 15
!                                                ^^^^^^^^
!                         Wait 15s after interface comes up before
!                         preempting — allows routing protocols to
!                         converge before HSRP takes over

! ── Tune timers (optional — faster failover) ─────────────────────
NetsTuts_R1(config-if)#standby 1 timers msec 200 msec 700
!                                       ^^^^       ^^^^
!                           hello 200ms  hold 700ms
!                           (default: 3s hello, 10s hold)

! ── MD5 authentication ───────────────────────────────────────────
NetsTuts_R1(config-if)#standby 1 authentication md5 key-string NetsTuts-HSRP
NetsTuts_R1(config-if)#exit

R2 — HSRP Standby Router (Priority 100)

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#ip address 10.0.0.2 255.255.255.0
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#standby version 2
NetsTuts_R2(config-if)#standby 1 ip 10.0.0.10
NetsTuts_R2(config-if)#standby 1 priority 100
!                                          ^^^  default — shown for clarity
NetsTuts_R2(config-if)#standby 1 preempt
NetsTuts_R2(config-if)#standby 1 timers msec 200 msec 700
NetsTuts_R2(config-if)#standby 1 authentication md5 key-string NetsTuts-HSRP
NetsTuts_R2(config-if)#exit

R3 — HSRP Listen Router (Priority 90)

NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#ip address 10.0.0.3 255.255.255.0
NetsTuts_R3(config-if)#no shutdown
NetsTuts_R3(config-if)#standby version 2
NetsTuts_R3(config-if)#standby 1 ip 10.0.0.10
NetsTuts_R3(config-if)#standby 1 priority 90
NetsTuts_R3(config-if)#standby 1 preempt
NetsTuts_R3(config-if)#standby 1 timers msec 200 msec 700
NetsTuts_R3(config-if)#standby 1 authentication md5 key-string NetsTuts-HSRP
NetsTuts_R3(config-if)#exit

HSRP Interface Tracking — Track Uplink, Decrement Priority

! ── Scenario: R1 is Active for HSRP but its uplink (Gi0/1) fails.
! ── Without tracking, R1 stays Active but has no internet path. ───
! ── Tracking decrements R1's HSRP priority when the uplink fails,
! ── allowing R2 (priority 100) to become Active instead. ─────────

! ── Method 1: Track interface directly (legacy) ──────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#standby 1 track GigabitEthernet0/1 20
!                                  ^^^^ ^^^^^^^^^^^^^^^^^^^ ^^
!                             group  track this interface   decrement by 20
!                  If Gi0/1 goes down: R1 priority = 110 - 20 = 90
!                  R2 (priority 100) > R1 (priority 90) → R2 preempts
NetsTuts_R1(config-if)#exit

! ── Method 2: Track object with IP SLA (modern — recommended) ────
NetsTuts_R1(config)#ip sla 10
NetsTuts_R1(config-ip-sla)#icmp-echo 8.8.8.8 source-interface GigabitEthernet0/1
NetsTuts_R1(config-ip-sla-echo)#frequency 5
NetsTuts_R1(config-ip-sla-echo)#exit
NetsTuts_R1(config)#ip sla schedule 10 life forever start-time now
NetsTuts_R1(config)#track 10 ip sla 10 reachability

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#standby 1 track 10 decrement 20
!                               ^^^ ^^ ^^^^^^^^^^^^^^^^^^
!                          group  obj  decrement 20 when track goes Down
NetsTuts_R1(config-if)#exit

Interface tracking without IP SLA only detects a physical link failure (interface goes down). If the upstream router fails while R1's Gi0/1 link remains physically up (common in fibre and managed Ethernet environments), HSRP never triggers the decrement. IP SLA tracking with ICMP probes detects end-to-end reachability failures — a much more reliable indicator of actual path loss. Always prefer IP SLA tracking in production deployments.

4. Step 2 — VRRP Configuration

VRRP (RFC 5798) uses the vrrp keyword instead of standby. The group identifier is called a VRID (Virtual Router ID). The key VRRP distinction from HSRP: preemption is enabled by default, and the Master router can use its physical interface IP as the virtual IP (making it the IP owner with an automatic priority of 255).

R1 — VRRP Master (Priority 110)

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#vrrp 1 ip 10.0.0.20
!                        ^ ^^ ^^^^^^^^^^
!                    VRID group  virtual IP (must not be R1's own IP
!                                unless R1 is the IP owner)

NetsTuts_R1(config-if)#vrrp 1 priority 110
!                              ^^^^^^^^ ^^^
!                              R1 highest → becomes Master

! ── VRRP preemption is ON by default — but can be tuned ──────────
NetsTuts_R1(config-if)#vrrp 1 preempt delay minimum 15
!                                          ^^^^^^^^^^^^
!                         15s delay before preempting
!                         (syntax same as HSRP preempt delay)

! ── VRRP timers ──────────────────────────────────────────────────
NetsTuts_R1(config-if)#vrrp 1 timers advertise msec 200
!                                    ^^^^^^^^^^^^^^^^^^
!                         Master advertisement interval = 200ms
!                         (Backup calculates hold: 3 × 200ms + skew)

! ── VRRP authentication (plain text — no MD5 in VRRPv2) ──────────
NetsTuts_R1(config-if)#vrrp 1 authentication text NetsTuts-VRRP
NetsTuts_R1(config-if)#exit

R2 — VRRP Backup (Priority 100)

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#vrrp 1 ip 10.0.0.20
NetsTuts_R2(config-if)#vrrp 1 priority 100
NetsTuts_R2(config-if)#vrrp 1 preempt delay minimum 15
NetsTuts_R2(config-if)#vrrp 1 timers advertise msec 200
NetsTuts_R2(config-if)#vrrp 1 authentication text NetsTuts-VRRP
NetsTuts_R2(config-if)#exit

R3 — VRRP Backup (Priority 90)

NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#vrrp 1 ip 10.0.0.20
NetsTuts_R3(config-if)#vrrp 1 priority 90
NetsTuts_R3(config-if)#vrrp 1 preempt delay minimum 15
NetsTuts_R3(config-if)#vrrp 1 timers advertise msec 200
NetsTuts_R3(config-if)#vrrp 1 authentication text NetsTuts-VRRP
NetsTuts_R3(config-if)#exit

VRRP IP Owner — Special Case

! ── SPECIAL CASE: VRRP IP Owner ──────────────────────────────────
! ── If the virtual IP = a router's physical interface IP, that
! ── router is the "IP owner" and has automatic priority 255. ─────
! ── No other router can preempt it while it is running. ──────────

! ── Example: R1's Gi0/0 = 10.0.0.20 (same as virtual IP) ─────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ip address 10.0.0.20 255.255.255.0   ! R1 owns the VIP
NetsTuts_R1(config-if)#vrrp 1 ip 10.0.0.20
!                                 ^^^^^^^^
!                   VIP = R1's IP → R1 is IP owner, priority = 255 (automatic)
!                   'vrrp 1 priority' command has no effect on IP owner

! ── Verify IP owner status ───────────────────────────────────────
NetsTuts_R1#show vrrp brief
Interface          Grp  A-Prio  P-Prio  State    Master_addr     Group_addr
Gi0/0              1    255     255     Master   10.0.0.20       10.0.0.20
!                       ^^^
!                  A-Prio = 255 → confirmed IP owner

! ── This HSRP-equivalent does NOT exist — HSRP virtual IP must
!    always be different from all physical interface IPs ─────────

The IP owner concept is VRRP-only and has no HSRP equivalent. In HSRP, the virtual IP must always be a separate address from any router's physical IP. In VRRP, configuring the virtual IP equal to one router's interface IP makes that router the permanent owner — it always becomes Master when running, regardless of configured priorities on other routers. This simplifies addressing (no need to allocate a separate virtual IP) but means the standby routers can never take the Master role while the IP owner is up. Only when the IP owner is completely down do backup routers elect a new Master.

VRRP Object Tracking

! ── Track uplink reachability and decrement VRRP priority ────────
NetsTuts_R1(config)#track 11 interface GigabitEthernet0/1 line-protocol
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#vrrp 1 track 11 decrement 20
!                              ^^^^^^^^^^^^^^^^^^^^^^^^^
!                        same syntax as HSRP tracking
NetsTuts_R1(config-if)#exit

5. Step 3 — GLBP Configuration

GLBP uses a two-tier role structure: one AVG (Active Virtual Gateway) manages the group, responds to ARP requests, and assigns virtual MACs to each AVF (Active Virtual Forwarder). Every router in the group is an AVF and actively forwards traffic. The AVG distributes different virtual MACs to different hosts, spreading load across all routers simultaneously.

Understanding GLBP Virtual MACs

  GLBP MAC FORMAT: 0007.b400.XXYY
    XX = GLBP group number in hex (e.g., group 1 → 01)
    YY = AVF forwarder number (01, 02, 03, or 04)

  In this lab (group 1):
    R1 = AVF 1 → virtual MAC 0007.b400.0101
    R2 = AVF 2 → virtual MAC 0007.b400.0102
    R3 = AVF 3 → virtual MAC 0007.b400.0103

  HOW LOAD BALANCING WORKS:
    PC-A ARPs for 10.0.0.30 → AVG (R1) responds with 0007.b400.0101 (R1's MAC)
    PC-B ARPs for 10.0.0.30 → AVG (R1) responds with 0007.b400.0102 (R2's MAC)
    PC-C ARPs for 10.0.0.30 → AVG (R1) responds with 0007.b400.0103 (R3's MAC)
    PC-D ARPs for 10.0.0.30 → AVG (R1) responds with 0007.b400.0101 (R1's MAC again - round robin)

    PC-A sends default-route traffic → R1 (AVF1) forwards it
    PC-B sends default-route traffic → R2 (AVF2) forwards it
    PC-C sends default-route traffic → R3 (AVF3) forwards it

    All three routers are simultaneously forwarding for different hosts!
    No router is sitting idle.

R1 — GLBP AVG + AVF1 (Priority 110)

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#glbp 1 ip 10.0.0.30
!                        ^ ^^ ^^^^^^^^^^
!                   group  cmd  virtual IP (single VIP for all AVFs)

NetsTuts_R1(config-if)#glbp 1 priority 110
!                              ^^^^^^^^ ^^^
!                         R1 highest priority → wins AVG election

NetsTuts_R1(config-if)#glbp 1 preempt
!                              ^^^^^^^
!                         R1 reclaims AVG role on recovery
!                         (preemption disabled by default in GLBP)

NetsTuts_R1(config-if)#glbp 1 preempt delay minimum 15

! ── GLBP load-balancing method ───────────────────────────────────
NetsTuts_R1(config-if)#glbp 1 load-balancing round-robin
!                                              ^^^^^^^^^^^
!                         Default: round-robin (each ARP gets next AVF MAC)
!                         Alternatives: weighted | host-dependent

! ── GLBP timers ──────────────────────────────────────────────────
NetsTuts_R1(config-if)#glbp 1 timers msec 200 msec 700
!                                   hello=200ms, hold=700ms

! ── MD5 authentication ───────────────────────────────────────────
NetsTuts_R1(config-if)#glbp 1 authentication md5 key-string NetsTuts-GLBP
NetsTuts_R1(config-if)#exit

R2 — GLBP AVF2 (Priority 100)

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#glbp 1 ip 10.0.0.30
NetsTuts_R2(config-if)#glbp 1 priority 100
NetsTuts_R2(config-if)#glbp 1 preempt
NetsTuts_R2(config-if)#glbp 1 preempt delay minimum 15
NetsTuts_R2(config-if)#glbp 1 load-balancing round-robin
NetsTuts_R2(config-if)#glbp 1 timers msec 200 msec 700
NetsTuts_R2(config-if)#glbp 1 authentication md5 key-string NetsTuts-GLBP
NetsTuts_R2(config-if)#exit

R3 — GLBP AVF3 (Priority 90)

NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#glbp 1 ip 10.0.0.30
NetsTuts_R3(config-if)#glbp 1 priority 90
NetsTuts_R3(config-if)#glbp 1 preempt
NetsTuts_R3(config-if)#glbp 1 preempt delay minimum 15
NetsTuts_R3(config-if)#glbp 1 load-balancing round-robin
NetsTuts_R3(config-if)#glbp 1 timers msec 200 msec 700
NetsTuts_R3(config-if)#glbp 1 authentication md5 key-string NetsTuts-GLBP
NetsTuts_R3(config-if)#exit

GLBP Weighted Load Balancing

! ── Weighted load balancing — distribute proportionally by weight ─
! ── Use when routers have different forwarding capacities ─────────
! ── (e.g., R1 is a high-end 4451, R2/R3 are smaller ISR 1100s) ───

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#glbp 1 load-balancing weighted
NetsTuts_R1(config-if)#glbp 1 weighting 200
!                                        ^^^
!                  R1 weight = 200 (default = 100, range 1–254)
!                  R1 handles 200/(200+100+100) = 50% of traffic
NetsTuts_R1(config-if)#exit

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#glbp 1 load-balancing weighted
NetsTuts_R2(config-if)#glbp 1 weighting 100   ! R2 = 100/(200+100+100) = 25%
NetsTuts_R2(config-if)#exit

NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#glbp 1 load-balancing weighted
NetsTuts_R3(config-if)#glbp 1 weighting 100   ! R3 = 100/(200+100+100) = 25%
NetsTuts_R3(config-if)#exit

! ── GLBP weighting with tracking (remove AVF from load balancing
!    when its uplink fails) ────────────────────────────────────────
NetsTuts_R1(config)#track 20 interface GigabitEthernet0/1 line-protocol
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#glbp 1 weighting 200 lower 150 upper 180
!                                         ^^^  ^^^^^    ^^^^^
!                               max weight  lower threshold  upper threshold
!                  Weight starts at 200.
!                  When track goes Down: weight decrements (by track config).
!                  If weight drops below 150 (lower): R1 exits AVF Active state.
!                  When weight recovers above 180 (upper): R1 re-enters AVF Active.
NetsTuts_R1(config-if)#glbp 1 weighting track 20 decrement 60
!                                         ^^^^^^^^^^^^^^^^
!                      When track 20 (Gi0/1) goes Down: weight 200 - 60 = 140
!                      140 < 150 (lower threshold) → R1 removed from AVF rotation
NetsTuts_R1(config-if)#exit

GLBP weighted tracking is more sophisticated than HSRP/VRRP tracking because GLBP must decide whether to remove a router from the active forwarding pool entirely (not just trigger a priority-based role change). The lower/upper threshold mechanism provides hysteresis: a router exits the AVF role when weight drops below the lower threshold and only re-enters when weight recovers above the upper threshold. This prevents a flapping uplink from causing rapid enter/exit cycling.

GLBP Host-Dependent Load Balancing

! ── Host-dependent: same host always gets same AVF ───────────────
! ── Ensures session persistence — important for stateful firewalls,
! ── NAT devices, or applications sensitive to gateway changes ─────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#glbp 1 load-balancing host-dependent
!                                              ^^^^^^^^^^^^^^
!                  Host's MAC address hashed to select an AVF.
!                  Same host always hits the same AVF — consistent path.
!                  Load may not be perfectly even (depends on host count).
NetsTuts_R1(config-if)#exit

6. Step 4 — Failover Behaviour and Simulation

HSRP Failover Sequence

  NORMAL STATE (steady state):
    R1: Active  (priority 110, forwarding all traffic for VIP 10.0.0.10)
    R2: Standby (priority 100, monitoring R1's Hellos)
    R3: Listen  (priority 90, monitoring but not standby)

  FAILURE EVENT — R1's Gi0/0 goes down:
    1. R1 stops sending HSRP Hellos on the segment
    2. R2 misses 3 consecutive Hellos (hold timer = 700ms)
       → R2 declares R1 dead after 700ms
    3. R2 transitions: Standby → Speak → Active
    4. R2 sends 3 gratuitous ARPs: "VIP 10.0.0.10 is now at R2's MAC"
       (or HSRPv2: "virtual MAC 0000.0c9f.f001 is now at R2's physical port")
    5. Hosts and switches update their ARP and CAM tables
    6. R3 transitions: Listen → Speak → Standby
    7. Total failover time with 200ms hello / 700ms hold ≈ 700ms–1s

  RECOVERY — R1 comes back up (preempt configured):
    1. R1 comes up, waits preempt delay minimum 15s
    2. After 15s: R1 priority (110) > R2 priority (100)
    3. R1 sends coup message: "I'm taking over as Active"
    4. R2 transitions: Active → Standby
    5. R1 transitions: Speak → Active
    6. R1 sends gratuitous ARPs to update CAM/ARP tables

Simulate HSRP Failover

! ── Verify initial state ─────────────────────────────────────────
NetsTuts_R1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State    Active          Standby         Virtual IP
Gi0/0       1    110 P Active   local           10.0.0.2        10.0.0.10

NetsTuts_R2#show standby brief
Interface   Grp  Pri P State    Active          Standby         Virtual IP
Gi0/0       1    100 P Standby  10.0.0.1        local           10.0.0.10

! ── Simulate R1 failure ──────────────────────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#shutdown

! ── Within ~700ms, R2 becomes Active ─────────────────────────────
! ── Console on R2: ───────────────────────────────────────────────
*Mar  8 2026 10:15:22.501: %HSRP-5-STATECHANGE: GigabitEthernet0/0
  Grp 1 state Standby -> Active

NetsTuts_R2#show standby brief
Interface   Grp  Pri P State    Active          Standby         Virtual IP
Gi0/0       1    100 P Active   local           10.0.0.3        10.0.0.10
! ── R2 is now Active; R3 promoted to Standby ─────────────────────

! ── Verify virtual MAC moved ─────────────────────────────────────
NetsTuts_SW1#show mac address-table | include 0000.0c9f
0000.0c9f.f001   Gi0/2   DYNAMIC   ← previously on Gi0/1 (R1's port)
!                 ^^^^
!           Now on Gi0/2 (R2's port) — switch updated MAC table

Use show mac address-table on the switch to confirm the virtual MAC has moved to R2's port after failover. The switch's CAM table is updated when R2 sends gratuitous ARPs claiming the virtual MAC. See also show interfaces to verify interface status on both routers during the failover test.

VRRP Failover Sequence

  VRRP FAILOVER (same concept, different terminology):
    R1: Master  (priority 110, sending VRRP Advertisements every 200ms)
    R2: Backup  (priority 100, monitoring Advertisements)
    R3: Backup  (priority 90, monitoring Advertisements)

  Master down interval (how long Backup waits before taking over):
    Master_Down_Interval = 3 × Advertisement_Interval + Skew_Time
    Skew_Time = (256 - priority) / 256 seconds
    For R2 (priority 100): Skew = (256-100)/256 = 0.609s
    Master_Down_Interval = 3 × 0.2 + 0.609 = 1.209s

  WHY THE SKEW? — Prevents simultaneous takeover when all backups
  detect the master failing at the same time. Lower-priority
  backups wait longer (higher skew), giving higher-priority
  backups time to take over first.

  VRRP PREEMPTION IS ON BY DEFAULT — when R1 recovers, it
  immediately takes back the Master role (after preempt delay
  if configured). This is the opposite of HSRP where preemption
  must be explicitly enabled.

GLBP Failover — AVG and AVF Failure Cases

  GLBP has TWO types of failure to handle:

  CASE 1: AVF FAILURE (e.g., R2/AVF2 fails):
    R2 stops sending GLBP Hellos.
    After hold timer expires, AVG (R1) detects R2 failure.
    AVG reassigns R2's virtual MAC (0007.b400.0102) to another router
    (typically R3 as the next available AVF).
    R3 now has TWO virtual MACs: 0007.b400.0103 (its own) +
    0007.b400.0102 (R2's redirected MAC).
    R3 forwards traffic for BOTH virtual MACs.
    Hosts that had R2's MAC as their gateway now reach R3 instead.
    ─ Traffic is redistributed; no host reconfiguration needed. ─

  CASE 2: AVG FAILURE (e.g., R1/AVG fails):
    R1 stops sending GLBP Hellos.
    Hold timer expires; R2 (next highest priority) becomes AVG.
    R2 is now both AVG and AVF2.
    R2 takes over responding to ARP requests for 10.0.0.30.
    R2 also continues forwarding for its own virtual MAC.
    GLBP group continues operating; load balancing continues.

  CASE 3: AVG + AVF1 FAILURE SIMULTANEOUSLY:
    Same as Case 2 — R2 becomes AVG + AVF2.
    R3 remains AVF3.
    Two routers continue forwarding; recovery is automatic.

Simulate GLBP AVF Failure

! ── Verify GLBP state before failure ─────────────────────────────
NetsTuts_R1#show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Gi0/0       1    -   110 Active   10.0.0.30       local           10.0.0.2
Gi0/0       1    1   -   Active   0007.b400.0101  local           -
Gi0/0       1    2   -   Listen   0007.b400.0102  10.0.0.2        -
Gi0/0       1    3   -   Listen   0007.b400.0103  10.0.0.3        -
!                   ^^^
!              Fwd = AVF forwarder number
!              R1 is AVG (Active) and AVF1 (Active)
!              R2 is AVF2 (Listen from R1's perspective)
!              R3 is AVF3 (Listen from R1's perspective)

! ── Simulate R2 (AVF2) failure ───────────────────────────────────
NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#shutdown

! ── After hold timer, AVG (R1) reassigns R2's virtual MAC ────────
*Mar  8 2026 10:22:15.003: %GLBP-6-FWDSTATECHANGE: GigabitEthernet0/0
  Grp 1 Fwd 2 state Listen -> Active

! ── R3 takes over as AVF for forwarder 2 ─────────────────────────
NetsTuts_R1#show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Gi0/0       1    -   110 Active   10.0.0.30       local           10.0.0.3
Gi0/0       1    1   -   Active   0007.b400.0101  local           -
Gi0/0       1    2   -   Active   0007.b400.0102  10.0.0.3        -   ← R3 handles R2's MAC
Gi0/0       1    3   -   Active   0007.b400.0103  10.0.0.3        -
! ── R3 now forwards for TWO virtual MACs (AVF2 + AVF3) ───────────

7. HSRP and VRRP Load Balancing with Multiple Groups

Since HSRP and VRRP only allow one active router per group, load balancing requires configuring multiple groups with different active routers — and pointing different hosts (or VLANs) at different virtual IPs. This is more complex than GLBP's single-group load balancing but widely deployed.

HSRP Dual-Group Load Balancing

! ── Group 1: R1 Active, R2 Standby — VIP 10.0.0.10 ───────────────
! ── Group 2: R2 Active, R1 Standby — VIP 10.0.0.11 ───────────────
! ── DHCP assigns GW 10.0.0.10 to half the hosts, 10.0.0.11 to other half

! ── R1: Active for Group 1, Standby for Group 2 ──────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#standby version 2
NetsTuts_R1(config-if)#standby 1 ip 10.0.0.10
NetsTuts_R1(config-if)#standby 1 priority 110      ! Active for group 1
NetsTuts_R1(config-if)#standby 1 preempt
NetsTuts_R1(config-if)#standby 2 ip 10.0.0.11
NetsTuts_R1(config-if)#standby 2 priority 90       ! Standby for group 2
NetsTuts_R1(config-if)#standby 2 preempt
NetsTuts_R1(config-if)#exit

! ── R2: Standby for Group 1, Active for Group 2 ──────────────────
NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#standby version 2
NetsTuts_R2(config-if)#standby 1 ip 10.0.0.10
NetsTuts_R2(config-if)#standby 1 priority 90       ! Standby for group 1
NetsTuts_R2(config-if)#standby 1 preempt
NetsTuts_R2(config-if)#standby 2 ip 10.0.0.11
NetsTuts_R2(config-if)#standby 2 priority 110      ! Active for group 2
NetsTuts_R2(config-if)#standby 2 preempt
NetsTuts_R2(config-if)#exit

! ── Verify both groups ───────────────────────────────────────────
NetsTuts_R1#show standby brief
Interface   Grp  Pri P State    Active          Standby         Virtual IP
Gi0/0       1    110 P Active   local           10.0.0.2        10.0.0.10  ← R1 active grp1
Gi0/0       2    90  P Standby  10.0.0.2        local           10.0.0.11  ← R1 standby grp2

NetsTuts_R2#show standby brief
Interface   Grp  Pri P State    Active          Standby         Virtual IP
Gi0/0       1    90  P Standby  10.0.0.1        local           10.0.0.10  ← R2 standby grp1
Gi0/0       2    110 P Active   local           10.0.0.1        10.0.0.11  ← R2 active grp2

Multiple HSRP groups provide load distribution but require that different hosts use different virtual IPs as their default gateway. This is typically achieved via DHCP scope configuration — one pool assigns gateway 10.0.0.10, another assigns 10.0.0.11. The complexity scales: 4 routers fully load-balanced requires 4 HSRP groups, 4 virtual IPs, and 4 DHCP gateway assignments. GLBP achieves the same distribution with 1 group and 1 virtual IP — the reason GLBP is preferred when all routers are Cisco.

8. Step 5 — Full Verification

show standby — Detailed HSRP Output

NetsTuts_R1#show standby GigabitEthernet0/0
GigabitEthernet0/0 - Group 1 (version 2)
  State is Active
    5 state changes, last state change 00:12:43
  Virtual IP address is 10.0.0.10
  Active virtual MAC address is 0000.0c9f.f001  ← HSRPv2 virtual MAC
    Local virtual MAC address is 0000.0c9f.f001 (v2 default)
  Hello time 200 msec, hold time 700 msec
    Next hello sent in 0.080 secs
  Preemption enabled, delay min 15 secs
  Active router is local
  Standby router is 10.0.0.2, priority 100 (expires in 0.620 sec)
  Priority 110 (configured 110)
    Track object 10 state Up decrement 20   ← ✓ IP SLA tracking active
  Authentication MD5, key-chain "not configured", key string "NetsTuts-HSRP"
  IP redundancy name is "hsrp-Gi0/0-1" (default)

show vrrp — Detailed VRRP Output

NetsTuts_R1#show vrrp GigabitEthernet0/0
GigabitEthernet0/0 - Group 1
  State is Master
  Virtual IP address is 10.0.0.20
  Virtual MAC address is 0000.5e00.0101  ← VRRP virtual MAC (VRID 1 = 01)
  Advertisement interval is 200 msec
  Preemption enabled, delay min 15 secs
  Priority is 110
    Track object 11 state Up  decrement 20
  Master Router is 10.0.0.1 (local), priority is 110
  Master Advertisement interval is 200 msec
  Master Down interval is 1.211 secs (expires in 0.989 secs)
  Authentication text "NetsTuts-VRRP"

NetsTuts_R1#show vrrp brief
Interface          Grp  A-Prio  P-Prio  State    Master_addr     Group_addr
Gi0/0              1    110     110     Master   10.0.0.1        10.0.0.20

show glbp — Detailed GLBP Output

NetsTuts_R1#show glbp GigabitEthernet0/0
GigabitEthernet0/0 - Group 1
  State is Active
    4 state changes, last state change 00:08:17
  Virtual IP address is 10.0.0.30
  Hello time 200 msec, hold time 700 msec
    Next hello sent in 0.112 secs
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, delay min 15 secs
  Active is local, priority 110
  Standby is 10.0.0.2, priority 100
  Authentication MD5, key-string "NetsTuts-GLBP"
  Load balancing: round-robin

  There are 3 forwarders (1 active):
  Forwarder 1
    State is Active
      1 state change, last state change 00:08:17
    MAC address is 0007.b400.0101 (default)   ← R1's virtual MAC
    Owner ID is 10.0.0.1
    Preemption enabled, min delay 30 sec
    Active is local, weighting 100

  Forwarder 2
    State is Listen
      1 state change, last state change 00:08:15
    MAC address is 0007.b400.0102 (default)   ← R2's virtual MAC
    Owner ID is 10.0.0.2
    Preemption enabled, min delay 30 sec
    Active is 10.0.0.2, weighting 100

  Forwarder 3
    State is Listen
      1 state change, last state change 00:08:13
    MAC address is 0007.b400.0103 (default)   ← R3's virtual MAC
    Owner ID is 10.0.0.3
    Preemption enabled, min delay 30 sec
    Active is 10.0.0.3, weighting 100

Verification Command Summary

Command	Protocol	What It Shows	Key Field
`show standby`	HSRP	Full HSRP state for all groups on all interfaces	State: Active/Standby/Listen; Virtual MAC; priority; track objects
`show standby brief`	HSRP	One-line summary per group: state, active/standby routers, VIP	State column; "P" flag = preempt enabled
`show vrrp`	VRRP	Full VRRP state for all VRIDs on all interfaces	State: Master/Backup; Virtual MAC; Master down interval
`show vrrp brief`	VRRP	One-line summary: VRID, priority, state, Master IP, group address	State column; A-Prio (actual priority after tracking)
`show glbp`	GLBP	Full GLBP state — AVG role, all AVFs, virtual MACs, load-balancing method	AVG state; forwarder states; virtual MACs 0007.b400.XXYY
`show glbp brief`	GLBP	One-line per forwarder: fwd number, state, virtual MAC, active router	All forwarders should show Active (not Listen) in healthy state
`show ip arp`	All	ARP table — confirms virtual MAC associated with virtual IP	Virtual IP should resolve to the expected virtual MAC (not a physical MAC)
`show running-config`	All	Verify FHRP commands are present under the correct interface	Confirm standby/vrrp/glbp commands, priority, preempt, and authentication
`debug standby`	HSRP	Real-time HSRP state transitions and Hello messages	State change messages — use only during testing, high CPU impact

9. Complete Configuration Reference & Key Points

Full FHRP Configuration — All Three Protocols on R1

! ════════════════ R1 — All Three FHRPs ═══════════════════════════
interface GigabitEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 !
 ! ─── HSRP Group 1 ───────────────────────────────────────────────
 standby version 2
 standby 1 ip 10.0.0.10
 standby 1 priority 110
 standby 1 preempt delay minimum 15
 standby 1 timers msec 200 msec 700
 standby 1 track 10 decrement 20
 standby 1 authentication md5 key-string NetsTuts-HSRP
 !
 ! ─── VRRP Group 1 ───────────────────────────────────────────────
 vrrp 1 ip 10.0.0.20
 vrrp 1 priority 110
 vrrp 1 preempt delay minimum 15
 vrrp 1 timers advertise msec 200
 vrrp 1 track 11 decrement 20
 vrrp 1 authentication text NetsTuts-VRRP
 !
 ! ─── GLBP Group 1 ───────────────────────────────────────────────
 glbp 1 ip 10.0.0.30
 glbp 1 priority 110
 glbp 1 preempt delay minimum 15
 glbp 1 timers msec 200 msec 700
 glbp 1 load-balancing round-robin
 glbp 1 authentication md5 key-string NetsTuts-GLBP
!
ip sla 10
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/1
 frequency 5
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability
track 11 interface GigabitEthernet0/1 line-protocol

FHRP Command Reference

Command	Protocol	Purpose
`standby [grp] ip [vip]`	HSRP	Define HSRP group and virtual IP. Activates HSRP on the interface.
`standby [grp] priority [n]`	HSRP	Set priority (1–255, default 100). Highest wins Active role.
`standby [grp] preempt [delay minimum [s]]`	HSRP	Enable preemption (disabled by default). Optional delay before preempting.
`standby [grp] timers [hello] [hold]`	HSRP	Set hello/hold timers in seconds or milliseconds (msec keyword).
`standby [grp] track [obj] decrement [n]`	HSRP	Decrement priority by n when track object goes Down. Triggers failover.
`standby version 2`	HSRP	Enable HSRPv2 (extended group range, millisecond timers, IPv6 support).
`vrrp [vrid] ip [vip]`	VRRP	Define VRRP group (VRID) and virtual IP. Activates VRRP.
`vrrp [vrid] priority [n]`	VRRP	Set priority (1–254, default 100). IP owner automatic priority = 255.
`vrrp [vrid] preempt [delay minimum [s]]`	VRRP	Preemption is ON by default. Use this command to add a delay or to disable preemption with `no vrrp [vrid] preempt`.
`vrrp [vrid] timers advertise [msec] [interval]`	VRRP	Set Master advertisement interval. Backups calculate hold time automatically.
`glbp [grp] ip [vip]`	GLBP	Define GLBP group and virtual IP. Activates GLBP AVG/AVF election.
`glbp [grp] priority [n]`	GLBP	Set AVG election priority (1–255, default 100).
`glbp [grp] load-balancing [round-robin\|weighted\|host-dependent]`	GLBP	Select AVF load-balancing algorithm. Default: round-robin.
`glbp [grp] weighting [n] lower [l] upper [u]`	GLBP	Set AVF weight and thresholds for weighted load-balancing with tracking.
`glbp [grp] weighting track [obj] decrement [n]`	GLBP	Decrement AVF weight when track object goes Down. If below lower threshold, remove from load balancing.

Key Points & Exam Tips

VRRP preemption is ON by default; HSRP and GLBP preemption is OFF. This is the most commonly tested FHRP comparison fact. In HSRP and GLBP, if the original active/AVG router fails and then recovers, it will NOT reclaim its role unless preempt is explicitly configured. In VRRP, the higher-priority router automatically reclaims the Master role when it recovers — no additional command needed (though a delay can be added with preempt delay minimum).
GLBP is the only FHRP that natively load-balances with a single virtual IP. HSRP and VRRP require multiple groups and multiple virtual IPs to load-balance. GLBP achieves load balancing with one group and one virtual IP by giving each host a different virtual MAC address (pointing to a different physical router). This is GLBP's primary advantage.
VRRP IP owner priority is always 255 and cannot be changed. When a VRRP router's physical interface IP equals the virtual IP, it becomes the IP owner with automatic priority 255. No other router can preempt the IP owner while it is running. This does not exist in HSRP — the virtual IP must always be a separate address from any physical interface IP.
HSRP virtual IP must not match any router's physical interface IP. Configuring standby 1 ip 10.0.0.1 on a router whose interface is 10.0.0.1 would cause problems — the virtual MAC would conflict with the physical interface's MAC resolution. Always use a dedicated virtual IP for HSRP groups.
GLBP can have up to 4 AVFs per group. With up to four routers acting as AVFs simultaneously, GLBP provides genuine active-active forwarding for all group members. If a fifth router joins the group, it enters a Listen state and becomes an AVF only when one of the four current AVFs fails.
Always configure preempt delay to allow routing convergence. Without a preempt delay, a recovering router may preempt and take over the Active/Master role before its routing table is fully populated. Traffic is then forwarded by a router that doesn't yet have a complete routing table, causing temporary drops. A delay of 15–30 seconds gives OSPF/EIGRP time to reconverge before the FHRP takeover occurs.
Use IP SLA tracking, not interface tracking. Interface tracking only detects physical layer failure (the link going down). IP SLA tracking detects end-to-end path loss — a much more meaningful trigger for FHRP priority decrement. A router's uplink can be physically up while the upstream router is unreachable. Only IP SLA detects this condition.
Virtual MAC addresses are protocol-specific. HSRP: 0000.0c07.acXX (v1) / 0000.0c9f.fXXX (v2). VRRP: 0000.5e00.01XX. GLBP: 0007.b400.XXYY. Knowing these formats allows you to identify which protocol is in use from a Wireshark capture or ARP table inspection — an important troubleshooting skill.
On the CCNP exam: be prepared to compare all three protocols in a table format (standard, terminology, load balancing, preemption default), configure VRRP and GLBP from scratch, explain GLBP's AVG/AVF roles and virtual MAC assignment, and describe the failover sequence for all three protocols including timer calculations.

Related Labs: FHRPs are fundamental to campus network design and work closely with the switching infrastructure. For Layer 2 redundancy that complements FHRP gateway redundancy see Private VLAN Configuration and VLAN and Trunking Configuration. For IP SLA configuration used in FHRP tracking see IP SLA Configuration & Tracking. In dual-datacenter designs, GLBP is often used alongside BGP for both internal gateway redundancy and external routing failover. For storm protection on the access layer segment where FHRPs operate see Storm Control & Traffic Shaping.

TEST WHAT YOU LEARNED

1. A network engineer configures HSRP on R1 with priority 110 and R2 with priority 100 — both without the `preempt` command. R1 starts first and becomes Active. Later R1 fails and R2 takes over as Active. R1 recovers shortly after. What is R1's HSRP state after recovery, and why?

A. R1 returns to Active immediately — the higher priority router always reclaims Active when it comes back up B. R1 returns to Active after 10 seconds — HSRP has a built-in 10-second recovery timer before preemption C. R1 transitions to Standby (not Active) because preemption is disabled by default in HSRP. R2 remains Active. Even though R1 has a higher priority (110 vs 100), HSRP does not allow a recovering router to displace the current Active router unless standby [grp] preempt is explicitly configured. R1 will become Standby, ready to take over if R2 fails. Only after configuring standby 1 preempt on R1 would it reclaim the Active role D. R1 stays in the Listen state indefinitely — once a router has failed it cannot rejoin as Standby without being manually reconfigured

Correct answer is C. This question tests the most fundamental and commonly missed HSRP behaviour: preemption is disabled by default. When R1 recovers, it enters the HSRP state machine from Initial, progresses through Learn → Listen → Speak, and then competes for the Standby role (not the Active role). Since R2 is already Active, R1 cannot displace it without preemption enabled. R1's higher priority is irrelevant without preempt — HSRP respects the currently Active router's position. The state machine result: R1 becomes Standby (the next-in-line to take over if R2 fails). This design was intentional — Cisco wanted network engineers to explicitly choose whether a recovering router should cause another disruption by preempting. Without preempt, a recovering router doesn't trigger a second failover event. With preempt, it does (which is why the preempt delay minimum option exists — to give routing protocols time to converge before the preempting router takes over). Contrast with VRRP where preemption is ON by default — a recovering higher-priority VRRP router automatically reclaims Master without the preempt command.

2. What is the GLBP virtual MAC address for group 2, forwarder 3?

A. 0007.b400.0203 — GLBP MAC format is 0007.b400.XXYY where XX = group number in hex and YY = forwarder number in hex. Group 2 (hex 02), forwarder 3 (hex 03) → 0007.b400.0203 B. 0000.0c07.ac02 — this is the HSRPv1 virtual MAC format for group 2 C. 0000.5e00.0102 — this is the VRRP virtual MAC for VRID 2 D. 0007.b400.0302 — group and forwarder numbers are reversed in the GLBP MAC format

Correct answer is A. The GLBP virtual MAC format is 0007.b400.XXYY where XX represents the GLBP group number in two hexadecimal digits and YY represents the forwarder (AVF) number in two hexadecimal digits. Group 2 in hex is 02, and forwarder 3 in hex is 03, giving 0007.b400.0203. This is a frequently tested exam fact. Knowing the virtual MAC formats for all three protocols allows identification from Wireshark captures, ARP tables, or switch MAC address tables: HSRP v1: 0000.0c07.acXX (XX = group in hex, range 00–FF for groups 0–255). HSRP v2: 0000.0c9f.fXXX (XXX = group in hex, range 000–FFF for groups 0–4095). VRRP: 0000.5e00.01XX (XX = VRID in hex, range 01–FF for VRIDs 1–255). GLBP: 0007.b400.XXYY (XX = group 00–FF, YY = forwarder 01–04). Option B (0000.0c07.ac02) is the HSRPv1 MAC for group 2. Option C (0000.5e00.0102) is the VRRP MAC for VRID 2. Option D reverses the group and forwarder positions, which is incorrect.

3. In VRRP, what happens when the virtual IP address is configured to be the same as one router's physical interface IP? What unique privilege does this router receive?

A. This is a misconfiguration — VRRP requires the virtual IP to be different from all physical interface IPs, just like HSRP B. The router becomes the permanent Backup — owning the IP means it defers to other routers for Master election C. The router must configure a separate loopback with the virtual IP to avoid ARP conflicts D. The router becomes the VRRP IP owner and receives automatic priority 255 — the highest possible VRRP priority. The IP owner always wins the Master election and cannot be preempted by any other router while it is running, regardless of other routers' configured priorities. If R1 owns the VIP (priority 255), R2 with priority 254 cannot become Master while R1 is up. Only when the IP owner is completely unavailable do other routers elect a new Master. This feature does not exist in HSRP — HSRP's virtual IP must always be a dedicated address separate from all physical interface IPs

Correct answer is D. The VRRP IP owner concept is one of the key differences between VRRP and HSRP and a frequently tested exam topic. In VRRP, the IP owner is the router whose physical interface IP matches the virtual IP configured in the VRRP group. IOS automatically assigns this router priority 255 (the maximum; normal configured priorities range from 1–254). Priority 255 ensures the IP owner always wins any Master election — no other router can be configured with a priority high enough to displace it. The practical implications: first, there is no need to allocate a separate virtual IP address when using the IP owner feature — you simply use one router's existing IP as the VRRP VIP. Second, you can only achieve true preemption by another router when the IP owner is completely offline. Third, this behavior makes VRRP somewhat simpler to configure in small environments where one router is clearly the primary. HSRP explicitly prohibits this configuration — configuring standby 1 ip [interface-ip] where the VIP matches the physical IP would create ARP conflicts because the router would be responding to ARP for the VIP using its physical MAC, while HSRP also tries to respond using the virtual MAC.

4. A network has three routers running GLBP with round-robin load balancing. PC-A, PC-B, and PC-C each send an ARP request for the virtual IP. Which virtual MACs do they receive, and which router forwards each PC's traffic?

A. All three PCs receive the same virtual MAC — the AVG's virtual MAC — and the AVG forwards all traffic B. PC-A receives 0007.b400.0101 (R1/AVF1) and sends traffic to R1. PC-B receives 0007.b400.0102 (R2/AVF2) and sends traffic to R2. PC-C receives 0007.b400.0103 (R3/AVF3) and sends traffic to R3. The AVG (R1) responds to each ARP request with the next AVF's virtual MAC in round-robin sequence. Each host's traffic flows to a different physical router, achieving genuine load distribution across all three routers simultaneously C. Each PC receives the virtual IP address but not a virtual MAC — GLBP uses IP-level routing decisions rather than MAC-level load balancing D. All three PCs receive 0007.b400.0101 initially — the AVG distributes load over time by changing the ARP responses, not per-request

Correct answer is B. This question goes to the heart of GLBP's load-balancing mechanism. The AVG (Active Virtual Gateway) is the single point of coordination for the GLBP group. Its primary function is managing ARP responses. When a host ARPs for the virtual IP (e.g., 10.0.0.30), the ARP request is received by all routers in the group, but only the AVG responds. The AVG's response contains the virtual IP but assigns a different virtual MAC address for each response in round-robin order: first ARP → 0007.b400.0101 (R1/AVF1), second ARP → 0007.b400.0102 (R2/AVF2), third ARP → 0007.b400.0103 (R3/AVF3), fourth ARP → 0007.b400.0101 (back to R1). Since a host sends traffic to the MAC address in its ARP cache, PC-A frames are destined for AVF1's virtual MAC and arrive at R1. PC-B frames go to R2. PC-C frames go to R3. This is why GLBP achieves true load distribution with a single virtual IP — the distribution happens at the ARP layer, completely transparent to the hosts. Hosts have no idea their gateway is a virtual construct shared by multiple routers.

5. An HSRP Active router (R1, priority 110) has its uplink to the internet fail. R1's LAN interface remains up. Without IP SLA tracking configured, what happens? With tracking configured as `standby 1 track 10 decrement 20`, what happens?

A. Without tracking: R1 immediately fails over because HSRP detects the upstream failure. With tracking: same behaviour, just with an additional log message B. Without tracking: HSRP detects the loss via Hello messages and transitions R1 to Standby within 3 seconds. With tracking: the transition happens within 10 seconds C. Without tracking: R1 remains Active indefinitely — it continues sending HSRP Hellos on its LAN interface, so R2 never detects a failure and never takes over. All traffic is forwarded to R1 which then black-holes it (no internet path). Hosts lose internet connectivity while HSRP appears healthy. With tracking (decrement 20): when track object 10 goes Down (upstream failure detected by IP SLA), R1's priority drops from 110 to 90. R2's priority (100) is now higher. If R2 has preempt configured, R2 takes over as Active. Hosts' traffic is rerouted through R2's working upstream path. Internet connectivity is restored D. Without tracking: R1 sends a resign message when it detects its uplink failure, gracefully handing over to R2. With tracking: this process is accelerated

Correct answer is C. This scenario illustrates the critical limitation of HSRP without tracking. HSRP's Hello/hold timer mechanism only detects failures of the interface HSRP is running on — the LAN-facing interface. If R1's LAN interface (Gi0/0) is up, R1 continues sending HSRP Hellos normally. R2 receives the Hellos, considers R1 healthy, and remains in Standby. From HSRP's perspective, nothing is wrong. Meanwhile, R1's WAN interface (Gi0/1) is down — all traffic forwarded to R1 is black-holed. Hosts are using R1 as their gateway (it's the HSRP Active), routing their traffic to a dead end. This is a real-world failure mode that causes complete outages while all monitoring tools (HSRP status, interface status) show "everything is up." IP SLA tracking solves this by monitoring end-to-end path reachability. The ICMP probe to 8.8.8.8 fails when the upstream path is broken. Track object 10 goes Down. HSRP decrement fires: 110 - 20 = 90. R2 (priority 100) > R1 (priority 90). If R2 has preempt enabled, R2 sends a coup message and takes over as Active. Traffic now flows through R2's working internet path. This is why IP SLA tracking is considered essential for production FHRP deployments and why interface tracking alone is insufficient.

6. What is the VRRP Master Down Interval formula, and why does the skew time exist? Calculate the Master Down Interval for a Backup router with priority 50 and advertisement interval 1 second.

A. Master Down Interval = 3 × Advertisement Interval. Skew does not exist in VRRP — all backups wait the same time B. Master Down Interval = Advertisement Interval + (Priority / 256). For priority 50, 1s interval: 1 + (50/256) = 1.195s C. Master Down Interval = 3 × Advertisement Interval. For priority 50, 1s interval: 3 × 1 = 3s. No skew is applied. D. Master Down Interval = 3 × Advertisement_Interval + Skew_Time, where Skew_Time = (256 − Priority) / 256. The skew exists to prevent simultaneous takeover — when the Master fails, all Backup routers detect the failure simultaneously. Without skew, all Backups would start their Master election at exactly the same instant, potentially causing conflict. The skew staggers the timers: lower-priority routers wait longer (higher skew). For priority 50, 1s interval: Skew = (256 − 50) / 256 = 206/256 = 0.805s. Master Down Interval = 3 × 1 + 0.805 = 3.805s

Correct answer is D. The VRRP Master Down Interval formula (from RFC 3768/5798) has two components: the base time (3 × Advertisement Interval) and the skew time ((256 − Priority) / 256 seconds). The base time of 3 × advertisement interval mirrors HSRP's logic: three missed Hellos = presumed dead. The skew time is VRRP's elegant solution to the simultaneous-election problem. When the Master fails, all Backup routers detect the absence of Master advertisements simultaneously (all running the same timer). Without any differentiation, multiple Backups would all become Master candidates at the same instant, potentially sending conflicting Master advertisements and requiring additional election rounds. The skew delays each Backup by a different amount based on its priority: high priority (e.g., 200) → skew = (256-200)/256 = 0.219s — waits barely at all. Low priority (e.g., 50) → skew = (256-50)/256 = 0.805s — waits much longer. This means the highest-priority Backup always starts its takeover attempt first. By the time lower-priority Backups finish their skew delay, the higher-priority Backup has already become Master and is sending advertisements — the lower-priority Backups see these advertisements and immediately transition back to Backup state without ever contesting the Master role. Elegant, deterministic, no explicit negotiation needed. For the calculation: priority 50, 1s advertisement interval → Master Down Interval = 3(1) + (256-50)/256 = 3 + 0.805 = 3.805 seconds.

7. An engineer wants to load-balance traffic across two routers using HSRP. They configure two HSRP groups: R1 is Active for group 1 (VIP 10.1.1.1), R2 is Active for group 2 (VIP 10.1.1.2). Both groups are on the same VLAN. What additional configuration is required to make this load balancing effective, and what is the limitation compared to GLBP?

A. No additional configuration is needed — HSRP automatically distributes hosts across the two groups B. The two virtual IPs must be assigned to different hosts as their default gateway. This is typically achieved via DHCP — configure two DHCP pools on the same subnet: pool 1 assigns gateway 10.1.1.1 (half the hosts use R1), pool 2 assigns gateway 10.1.1.2 (half the hosts use R2). Without this DHCP configuration, all hosts would receive the same default gateway and only one group would carry traffic. The limitation vs GLBP: HSRP requires two virtual IPs, two DHCP scopes, and administrative overhead to maintain the host/gateway assignments. GLBP achieves the same distribution with one virtual IP, no DHCP gateway manipulation, and automatic redistribution if a router fails C. Hosts must be manually configured with different default gateways — DHCP cannot be used for FHRP load balancing D. HSRP cannot load-balance — only GLBP supports any form of traffic distribution across routers

Correct answer is B. HSRP multi-group load balancing is a valid and widely deployed technique, but it requires explicit distribution of hosts across the virtual IPs. HSRP provides the redundancy mechanism (if one router fails, the other takes over as Active for both groups via priority/preempt configuration), but the load distribution itself requires that different hosts actually use different virtual IPs. The most scalable way to achieve this is DHCP: configure two pools for the same subnet, each with a different default-router option. Some network designs use odd/even IP assignment (hosts .1–.127 get gateway .1, hosts .128–.254 get gateway .2). The fundamental limitation is administrative: as you scale to 3, 4, or more routers, you need 3–4 virtual IPs, 3–4 DHCP scopes, and careful management of which hosts use which gateway. Failover also becomes more complex — each group needs cross-standby configuration (R1 is standby for group 2, R2 is standby for group 1). GLBP eliminates all of this complexity: one virtual IP, no DHCP manipulation, automatic load distribution via ARP responses, and automatic redistribution of a failed AVF's virtual MAC to remaining AVFs.

8. In GLBP, what happens when the AVG (Active Virtual Gateway) fails while three AVFs are active?

A. All AVFs stop forwarding traffic because they require the AVG to authorize each forwarding decision B. The GLBP group disbands and all routers return to initial state until the AVG recovers C. A new AVG is elected from the remaining routers (next highest priority). The newly elected AVG takes over responding to ARP requests for the virtual IP and continues assigning virtual MACs. Critically, the existing AVFs continue forwarding traffic uninterrupted — hosts that already have ARP cache entries pointing to the virtual MACs continue sending traffic to the correct AVFs. Only new ARP requests are affected during the brief AVG re-election period. The GLBP group operates normally with one fewer router D. The router with the highest IP address automatically becomes the new AVG regardless of configured priorities

Correct answer is C. GLBP's two-role architecture (AVG + AVF) provides important resilience. The AVG and AVF roles are independent — losing the AVG does not affect the AVFs' ability to forward traffic. When R1 (AVG) fails: existing hosts have ARP cache entries mapping the virtual IP to specific virtual MACs. These entries remain valid (typically for several minutes before aging out). Hosts continue sending traffic using their cached MACs. The remaining AVFs (R2/AVF2 and R3/AVF3) continue receiving and forwarding this traffic normally — they have the virtual MACs and are forwarding for them. The only impact is on new ARP requests: during the brief AVG re-election period (a few hello intervals), no router responds to ARP for the virtual IP. New hosts, or hosts whose ARP entries have aged out, cannot resolve the VIP until the new AVG is elected. R2 (next highest priority) wins the AVG election and begins responding to ARP requests. From this point, all new hosts get virtual MAC assignments from R2, and GLBP operates normally. This design is far more resilient than HSRP/VRRP: in HSRP, when the Active router fails, ALL traffic is disrupted (the virtual MAC must be moved). In GLBP, only new ARP requests are briefly disrupted; existing flows continue through their respective AVFs.

9. VRRP is being deployed in a multi-vendor environment alongside non-Cisco routers. What configuration consideration is essential when choosing a VRID number, and why must HSRP not be used in this scenario?

A. The VRID number must be unique per subnet — using the same VRID on two different subnets in the same broadcast domain would cause MAC conflicts since the virtual MAC 0000.5e00.01XX is derived from the VRID. HSRP cannot be used in multi-vendor environments because it is Cisco proprietary — non-Cisco routers do not support the HSRP protocol, cannot participate in HSRP groups, and would need to be configured as secondary gateways using a completely different redundancy mechanism. VRRP is the IETF open standard (RFC 5798) implemented by all major router vendors, making it the correct choice for multi-vendor deployments B. VRID must be set to 0 in multi-vendor deployments for compatibility — other values are Cisco-specific extensions C. HSRP can be used in multi-vendor environments — non-Cisco routers implement HSRP through a license extension available from Cisco D. VRID numbers must be even — odd VRIDs are reserved for Cisco-proprietary VRRP extensions

Correct answer is A. This question covers two important FHRP selection criteria. First, VRRP VRID uniqueness: the VRRP virtual MAC is 0000.5e00.01XX where XX is the VRID in hex. If two different subnets in the same L2 domain use VRID 1, both generate the same virtual MAC 0000.5e00.0101. This creates a MAC conflict — switches receive gratuitous ARPs from two different physical locations claiming the same MAC address. The switch's MAC table flaps between the two ports, causing traffic disruption. VRIDs must be unique per L2 broadcast domain (VLAN). A common enterprise practice is to map VLAN ID to VRID: VLAN 10 uses VRID 10, VLAN 20 uses VRID 20, etc. Second, multi-vendor requirement: HSRP (Hot Standby Router Protocol) is Cisco proprietary. Juniper, Arista, Nokia, Huawei, and other vendors implement VRRP but not HSRP. In a mixed-vendor deployment, VRRP is the correct choice. GLBP is also Cisco proprietary — only VRRP satisfies the open-standard requirement. VRRPv3 (RFC 5798) adds IPv6 support and is the current recommended version for new deployments.

10. A network engineer notices that `show standby brief` shows R1's state as "Init" on a newly configured HSRP group. What are the three most likely causes, and how would you diagnose each?

A. Init state means HSRP is working — it is the normal steady state before any traffic is sent B. Init state always indicates a hardware failure — replace the interface card C. Init state only occurs on the Standby router — the Active router always shows Active regardless of configuration D. Init (Initial) state means HSRP has not progressed past the starting state. Three causes: (1) Interface is down — HSRP cannot run on a down interface. Diagnose: show interfaces GigabitEthernet0/0 — check "is up, line protocol is up." Fix: no shutdown on the interface. (2) No virtual IP configured — HSRP must have a VIP to form the group. Diagnose: show running-config interface Gi0/0 — verify standby 1 ip [vip] is present. Fix: add the VIP command. (3) Authentication mismatch — if one router has MD5 auth and the other does not (or uses different keys), Hellos are rejected and HSRP stays in Init or does not progress. Diagnose: debug standby — look for authentication failure messages. Fix: ensure identical authentication configuration on all group members.

Correct answer is D. HSRP's Initial state indicates the protocol has been configured but has not progressed to an operational state. Understanding the three root causes is essential for efficient troubleshooting. Cause 1 — Interface down: HSRP multicast Hellos (224.0.0.102 for HSRPv2) are sent and received on the physical interface. If the interface is administratively down (shutdown) or the link is disconnected (no cable), HSRP cannot send or receive any messages. The HSRP process stays in Init because it never hears from other group members and the interface cannot transmit. show interfaces shows "administratively down" or "down/down." Cause 2 — Missing VIP: HSRP without a configured virtual IP cannot form a complete group. The VIP is the essential element that gives the group its identity. Without it, HSRP has nothing to advertise and stays in Init. Check show running-config interface for the standby ip command. Cause 3 — Authentication mismatch: This is the most insidious cause because both routers may appear to be configured correctly. If R1 uses MD5 authentication and R2 uses plain text (or no authentication), R1 discards R2's Hellos (authentication fails) and R2 discards R1's Hellos. Both stay in Init (or R1 stays in Init if R2 has no auth and R1 is waiting for a valid group member). debug standby on both routers shows "HSRP authentication failure" messages. The fix: standardise authentication configuration across all group members before deploying.

Back to Home