First, the essential ideas
- Default gateway and first hop
- The default gateway is the local router a host uses when no more-specific route matches a remote destination. First hop names that initial router, not the destination server.
- FHRP and virtual IP
- A First Hop Redundancy Protocol lets participating routers present a shared gateway identity. The virtual IP address belongs to the logical service, not to an extra physical device.
- Virtual MAC address
- The Ethernet identity used for the virtual router. Hosts can keep the same gateway IP while forwarding responsibility moves between participating routers.
- HSRP active and standby
- Hot Standby Router Protocol selects an active router to serve the group and a standby ready to take over. Other HSRP states describe discovery or readiness, not equivalent forwarding roles.
- VRRP active and backup
- Virtual Router Redundancy Protocol is an IETF standard. RFC 9568 says Active and Backup; older Cisco output may label the active role Master.
- Group and VRID
- A group identifies one HSRP service on an interface. VRRP calls its group number a Virtual Router Identifier, or VRID. The number alone does not identify a router or destination.
- Priority and preemption
- Priority expresses election preference. Preemption permits a preferred available router to take over from a lower-priority incumbent; it is different from replacing a failed router.
- Tracking and effective priority
- Tracking observes a configured condition, such as interface state. A configured decrement can lower the effective election priority when that condition fails.
- Address owner
- In VRRP, an address owner has the virtual address as its real interface address and uses priority 255. Our separate virtual .1 addresses have no address owner.
- Failover and convergence
- Failover transfers a role after failure detection. Convergence is the network settling into a usable state; neither term promises zero packet loss or a measured recovery time.
Start with the host's route, not a router's impressive-looking status. A laptop configured to use R1's physical .2 address will not automatically start using the group's .1 address. The two-LAN exercise deliberately gives the server its own virtual gateway so the return path is as explicit as the request.
See the idea
R1 or R2, never a serial router pair
Baseline uses R1; modeled failover uses R2. Both alternatives connect Client1 to Server1 while preserving both virtual gateways.
R1 serves both gateways
Client1 192.0.2.10 uses gateway 192.0.2.1, then SW1, R1 and SW2 to Server1 198.51.100.20. Server1 uses gateway 198.51.100.1 for the reverse path.
What this model leaves out: Baseline-versus-failover role comparison, not a cabling diagram. The two records summarize the same six-device, two-LAN model; virtual gateways are not extra devices. No runtime or timing is measured.
Full visual explanation and references
Baseline: Client1, SW1, R1, SW2, Server1. After R1 loss: Client1, SW1, R2, SW2, Server1. Replies reverse the corresponding path. R1 and R2 are alternatives, never serial hops.
Baseline-versus-failover role comparison, not a cabling diagram. The two records summarize the same six-device, two-LAN model; virtual gateways are not extra devices. No runtime or timing is measured.
- R1 serves both gateways
Client1 192.0.2.10 uses gateway 192.0.2.1, then SW1, R1 and SW2 to Server1 198.51.100.20. Server1 uses gateway 198.51.100.1 for the reverse path.
www.cisco.com - R2 takes both roles
After modeled R1 loss, R2 serves both virtual gateways. The complete request path is Client1, SW1, R2, SW2, Server1; neither R1 nor an unnamed upstream router is traversed.
www.cisco.comwww.rfc-editor.org - Verify the return path
After failover, the reply follows Server1, SW2, R2, SW1, Client1. Both virtual gateway addresses remain unchanged; the comparison does not measure recovery time.
www.rfc-editor.org
One idea at a time
Start with something familiar.
Draw Client1 and Server1 first. Their gateways are 192.0.2.1 and 198.51.100.1. Then draw R1 and R2 behind those virtual identities; do not add a third router for either virtual address.
Why learn this?
Two installed routers do not create useful redundancy unless hosts use the shared service and both routers can deliver traffic. Reading status becomes meaningful when it answers a specific endpoint question.
An everyday comparison
A reception desk keeps one published telephone number while different staff members take the shift. Callers use the desk number rather than one employee's private number.
What happens in a network
The published number resembles a virtual gateway, and the shift holder resembles the active role. Calling a private number resembles configuring the host with a single router's real address.
Where the comparison stopsTelephone shifts do not model Ethernet learning, protocol timers or return routes. The analogy explains stable identity only; it cannot predict packet loss.
Follow one worked example
- Read the baseline as a pair.
R1 serves both virtual gateways; R2 waits as the eligible replacement.
Why: The client-facing and server-facing roles both matter to the complete exchange.
- Remove R1 on the worksheet.
R2 takes responsibility for both groups after the modeled detection and election process.
Why: No host address change is needed because the virtual IPs remain the same.
- Trace the answer back.
Server1 uses 198.51.100.1, then R2 reaches Client1 on its connected LAN.
Why: A successful request without a return path is not an end-to-end result.
Your first small task
Client1 uses gateway 192.0.2.2 instead of 192.0.2.1. R1 disappears and R2 serves the virtual gateway. Explain the remaining fault.
Show a hint
Changing which router serves .1 does not transfer ownership of R1's separately configured .2 interface address.
Check the expected result
Client1 still targets R1's physical address. Restore its gateway to the virtual .1 address in the model, then trace both directions again.
Pause and explain it in your own words
Does an HSRP Active label prove Server1 is reachable?
Show a hint
Consider destination routes, interfaces, host gateways and the reply.
Show the explanation
No. The label reports one local group role. Check both LANs, the selected destination route, the server's return gateway and a real final-endpoint test before claiming service.
Short answer
What should you understand today?
HSRP and VRRP let hosts use a stable virtual gateway while participating routers exchange responsibility for forwarding. The host must actually use the virtual IP, and the surviving router still needs a usable destination and return path. Read role, group, virtual address, effective priority and preemption together; a healthy first-hop role does not prove an application works.
Before you begin
Learning targets
- Know IPv4 subnet membership, default gateways and Ethernet address resolution.
- Complete the required exercise on paper; no image, subscription or real router is needed.
- Optional observation requires an instructor-prepared isolated CML project, entitlement and authorized console access.
- Distinguish each real interface address from its virtual gateway.
- Interpret HSRP active/standby and VRRP active/backup status.
- Calculate effective priority and explain preemption.
- Trace request and reply paths when one router disappears.
- Verify the same final endpoint without claiming measured failover.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Default gateway and first hop
The default gateway is the local router a host uses when no more-specific route matches a remote destination. First hop names that initial router, not the destination server.
FHRP and virtual IP
A First Hop Redundancy Protocol lets participating routers present a shared gateway identity. The virtual IP address belongs to the logical service, not to an extra physical device.
Virtual MAC address
The Ethernet identity used for the virtual router. Hosts can keep the same gateway IP while forwarding responsibility moves between participating routers.
HSRP active and standby
Hot Standby Router Protocol selects an active router to serve the group and a standby ready to take over. Other HSRP states describe discovery or readiness, not equivalent forwarding roles.
VRRP active and backup
Virtual Router Redundancy Protocol is an IETF standard. RFC 9568 says Active and Backup; older Cisco output may label the active role Master.
Group and VRID
A group identifies one HSRP service on an interface. VRRP calls its group number a Virtual Router Identifier, or VRID. The number alone does not identify a router or destination.
Priority and preemption
Priority expresses election preference. Preemption permits a preferred available router to take over from a lower-priority incumbent; it is different from replacing a failed router.
Tracking and effective priority
Tracking observes a configured condition, such as interface state. A configured decrement can lower the effective election priority when that condition fails.
Address owner
In VRRP, an address owner has the virtual address as its real interface address and uses priority 255. Our separate virtual .1 addresses have no address owner.
Failover and convergence
Failover transfers a role after failure detection. Convergence is the network settling into a usable state; neither term promises zero packet loss or a measured recovery time.
A virtual gateway is an identity, not another box
Client1 is in 192.0.2.0/24 and Server1 is in 198.51.100.0/24, so their exchange needs routing. Each LAN has two real router interfaces and one virtual gateway address. The virtual IP is configured as the host's gateway. A virtual MAC supports the shared Ethernet identity while the current active router handles the handoff. No extra physical gateway is hidden in the diagram.
- Count two real routers, not three routers because a virtual address exists.
- Host gateway configuration is part of the redundancy dependency.
Interpret HSRP fields in interface and group context
Read interface, group, priority, state, active address, standby address and virtual IP together. The word local in an active-address field means the router whose console you are reading. A second router showing Standby supports the intended pair; an unknown standby does not prove a backup exists. Initial or discovery states should not be treated as the settled baseline.
- A group number needs an interface and protocol context.
- Compare both devices' records instead of trusting one healthy-looking line.
Translate VRRP terminology without changing the meaning
VRRPv3 supports IPv4 and IPv6; this exercise uses IPv4 only. Current RFC 9568 uses Active and Backup, while Cisco versions may display Master for the active role. Read the actual software's vocabulary. A VRRP address owner uses priority 255; other eligible priorities are 1 through 254, with 100 the default. Our real addresses .2 and .3 differ from the virtual .1, so neither router is the address owner.
- Map a legacy Master label to the current active forwarding role.
- Do not borrow VRRP owner priority 255 as an HSRP rule.
Separate failure replacement from preemption
A standby can replace a failed active router without preemption being enabled. Preemption concerns taking over from a still-operating lower-priority incumbent. HSRP preemption is not enabled by default; VRRP normally enables it, with special treatment for an address owner. Always inspect configuration and effective status rather than relying on a remembered default. Recovery may intentionally include a delay while the preferred router becomes ready.
- Election preference is not a demand for instantaneous role change.
- Failure detection, preemption and application recovery are separate events.
Tracking changes preference, not the entire network
An active router can keep sending local redundancy messages while its useful destination path fails. Object tracking can connect a chosen health condition to a priority decrement, but the scope of that condition must be explicit. An interface-up check does not prove that a remote service answers. A changed priority also needs compatible preemption behavior to transfer the role from a still-live incumbent.
- Inspect configured and current priority separately.
- No tracked condition in the baseline means no automatic upstream-health guarantee.
First-hop availability is narrower than service availability
This model survives one whole-router failure only while both switches, both endpoint links and the remaining router work. SW1 and SW2 are deliberate single points of failure. Both subnets are directly connected to each router, so no undeclared ISP, static default or remote routing protocol is needed. HSRP and VRRP do not replace destination routing, application checks or a redundant physical design.
- Test the final endpoint and its return path, not only the gateway.
- Current v1.1 objective 3.5 is conceptual; announced v2.0 objective 3.4 asks for HSRP and VRRP operational interpretation.
Real-world walkthrough
Two routers, one incorrectly configured host
In this hypothetical training network, the router pair correctly transfers both virtual gateways to R2. Client1 nevertheless fails because its default gateway is R1's real 192.0.2.2. The role election succeeded, but the host was never using the redundant identity.
- Compare Client1's configured gateway with the virtual IP, not merely the router inventory.
- Confirm R2's client-side and server-side group roles separately.
- Trace Client1's request and Server1's reply across the surviving router.
- Correct only the worksheet's host gateway to 192.0.2.1 and retrace the original endpoint pair.
- For a real rack, record actual route selection and endpoint responses before claiming recovery.
Guided GNS3 lab
Paper lab: one virtual identity, two router paths
Interpret supplied hypothetical HSRP and VRRP records, model a whole-router failure, restore the baseline and diagnose a physical-gateway mistake. Optional read-only checks can collect actual evidence on a prepared rack; none was executed during authoring.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| Client1 | ens2, VLAN 10 | 192.0.2.10/24; GW 192.0.2.1 | Request source |
| R1 | GigabitEthernet1 | 192.0.2.2/24 | Real client-LAN interface |
| R2 | GigabitEthernet1 | 192.0.2.3/24 | Real client-LAN interface |
| Group 10 | Client-side virtual service | 192.0.2.1/24 | Not an extra physical interface |
| R1 | GigabitEthernet2 | 198.51.100.2/24 | Real server-LAN interface |
| R2 | GigabitEthernet2 | 198.51.100.3/24 | Real server-LAN interface |
| Group 20 | Server-side virtual service | 198.51.100.1/24 | Server's return gateway |
| Server1 | ens2, VLAN 20 | 198.51.100.20/24; GW 198.51.100.1 | Final destination and reply source |
Set up the lab
- Required: draw the six named roles and mark every result HYPOTHETICAL. Use separate HSRP and VRRP worksheets; do not mix protocol versions or virtual-address ownership.
- Baseline HSRP worksheet: version 2, groups 10 and 20, R1 priority 120 active for both, R2 priority 100 standby for both, preemption enabled on both, default hello/hold timers 3/10 seconds, no tracking.
- Alternate VRRP worksheet: version 3 IPv4, VRIDs 10 and 20, same virtual IPs, R1 priority 120 Active and R2 priority 100 Backup, preemption enabled, neither router an address owner. No measured timing is supplied.
- Optional instructor prepares exactly this isolated CML topology, addresses, access VLANs, IPv4 forwarding, host default routes and permitted ICMP before observation. This is not a from-factory build guide. No bridge, NAT connector, Internet link or production access is allowed.
- Verify exact builds with show version. CML's CAT 8000V test table reports HSRP support; it does not establish VRRP validation. Use the optional VRRP commands only after the instructor verifies that exact release's capability and prepares a separate compatible variant; otherwise retain paper interpretation.
- For optional Ubuntu consoles, verify ens2 against the prepared node's actual interface inventory; document any different interface name before proceeding. The instructor supplies authorized accounts, not credentials embedded in this lesson. Virtual timing is not hardware timing.
Draw both complete LANs
Create the six devices, six cables and address ledger above. Label SW1 VLAN 10 and SW2 VLAN 20. Show .1 as a shared service on each LAN, not a third router, and write each host's exact default gateway.
- What you should see
- The model has named source, destination, both router paths and an explicit server return gateway.
- Why this step matters
- A complete scope prevents first-hop redundancy from hiding an absent downstream endpoint.
Interpret the HSRP baseline
Write the hypothetical Gi1 group 10 records from section two. Add Gi2 group 20: R1 Active, priority 120, active local, standby 198.51.100.3, VIP 198.51.100.1; R2 Standby, priority 100, active 198.51.100.2, standby local, same VIP.
- What you should see
- R1 serves both virtual gateways, while R2 is the identified standby on both LANs.
- Why this step matters
- The word local changes with the console; two groups on separate interfaces need separate records.
Optional HSRP status collection
Optional prepared rack only: select R1 in the CML workbench, open Console and connect with the instructor-authorized account. Start at > or #; use end if left in configuration mode. Repeat on R2 through its own Console. Only use the prepared HSRP variant. Record both interfaces and groups; compare observed fields with the paper baseline without assuming they match.
enable
show version
show standby brief
show standby
show ip route 198.51.100.20
show ip route 192.0.2.10What each command means
enable- Enter privileged EXEC using authorized access; do not bypass authentication.
show version- Record the exact image, release and platform for this observation.
show standby brief- Compare interface, group, current role, peer addresses and virtual IP.
show standby- Inspect detailed priority, preemption, timers and any tracking.
show ip route 198.51.100.20- Verify the route to the actual server, not just its gateway.
show ip route 192.0.2.10- Verify the return-side route to the actual client.
- What you should see
- A prepared matching rack should show both connected subnets and the planned two-group roles; retain actual deviations.
- Why this step matters
- Read-only operational fields add evidence without inventing a configuration or a completed failover.
Optional client baseline check
Only on the prepared rack, select Client1, open its CML Console, log in with the authorized Ubuntu account and use its terminal. Do not type these commands into a router console. Otherwise write the expected route and test on paper.
ip route get 198.51.100.20
ping -c 3 198.51.100.20What each command means
ip route get 198.51.100.20- Inspect the selected next hop, output interface and source for Server1.
ping -c 3 198.51.100.20- Send three ICMP echo probes to the final server; preserve actual replies or failure.
- What you should see
- A correctly prepared client selects 192.0.2.1 via ens2 with source 192.0.2.10; successful replies remain unmeasured here.
- Why this step matters
- The operating system's selected route must use the virtual gateway before redundancy can help this host.
Remove R1 on the worksheet only
Cross out R1 and both of its links on the HSRP worksheet. Leave R2, both switches, endpoints, addresses and host gateways unchanged. Do not power off a real router or run shutdown commands as part of this paper exercise.
- What you should see
- The only changed variable is availability of the entire R1 role; both R2 LAN attachments remain.
- Why this step matters
- Whole-router loss makes both request-side and reply-side failover explicit without an undeclared asymmetry.
Predict the surviving HSRP roles
After the modeled detection process, change both R2 group records to Active with active local. Mark the absent standby unknown. Keep virtual addresses .1 and R2's real addresses .3 unchanged; do not invent a precise recovery time.
- What you should see
- R2 now serves both virtual gateways, but no second operational standby remains in this two-router design.
- Why this step matters
- A successful takeover restores one usable router path, not the original amount of redundancy.
Trace request and reply after failure
Trace Client1 to SW1 to R2 to SW2 to Server1. Then start at Server1's gateway 198.51.100.1 and trace the reply through SW2, R2 and SW1 to Client1. Check both destination subnets on R2.
- What you should see
- Both modeled directions terminate at the original endpoints through the surviving connected interfaces.
- Why this step matters
- The client-facing Active label alone cannot establish Server1's return delivery.
Restore and retest the original model
Restore R1 and its two links with the original addresses and priorities. With the explicitly enabled preemption and readiness assumptions, predict R1 resuming both Active roles and R2 Standby. Retrace the original endpoint pair.
- What you should see
- The restored worksheet matches the original two-group baseline; no runtime recovery or zero-loss claim follows.
- Why this step matters
- Rollback includes topology, roles and end-to-end reasoning, not just erasing the failure mark.
Interpret the alternate VRRP design
Use a separate clean worksheet with no HSRP. For each VRID, record R1 priority 120 Active or legacy Master and R2 priority 100 Backup, matching VIPs and owner false. Cross out R1, predict R2 Active for both VRIDs, then restore R1 with the stated preemption policy.
- What you should see
- The same host virtual gateways support the modeled transfer, but role names and protocol identity are VRRP-specific.
- Why this step matters
- This exercises both required operational interpretations without claiming the protocols interoperate as one group.
Optional VRRP status collection
Optional prepared rack only: select R1 in the CML workbench, open Console and connect with the instructor-authorized account. Start at > or #; use end if left in configuration mode. Repeat on R2 through its own Console. Use only the separately prepared, capability-verified VRRPv3 IPv4 variant. Do not enable VRRP beside HSRP on these virtual IPs. If unavailable, retain the paper records and mark runtime unsupported.
enable
show version
show vrrp brief
show vrrp
show ip interface briefWhat each command means
enable- Enter authorized privileged EXEC for read-only inspection.
show version- Record the exact software used for this optional VRRP observation.
show vrrp brief- Read interface, VRID, address family, priority, preemption, role and group address.
show vrrp- Inspect detailed virtual addresses, current role, ownership, timers and priority.
show ip interface brief- Compare real interface addresses with the separate virtual service addresses.
- What you should see
- Use the platform's actual state labels; unsupported commands are a boundary, not permission to fabricate output.
- Why this step matters
- A capability-qualified alternative preserves practical verification without asserting untested simulator support.
Calculate a tracked priority separately
Return to a copy of the baseline. Add a hypothetical failed health object with decrement 30 to R1's priority 120 for one named group. Compute 90, compare with R2's 100 and explicitly require R2 preemption. Then clear the hypothetical fault and restore 120.
- What you should see
- The effective priority changes from 120 to 90 and back; the baseline itself still contains no configured tracking.
- Why this step matters
- A numerical exercise teaches preference while keeping unexecuted health monitoring separate from observed state.
Diagnose the wrong physical gateway
On the R1-failed copy, change only Client1's gateway from 192.0.2.1 to 192.0.2.2. Explain why R2 owning .1 does not make .2 available. Restore .1, then retrace request and reply to Server1 without changing either host address.
- What you should see
- The modeled client failure follows the wrong gateway; restoring the virtual address repairs that stated dependency.
- Why this step matters
- Two working redundancy records cannot compensate for a host pointed at an absent physical router.
Close with an evidence boundary
Compare baseline, failure and restored worksheets for each protocol. For any optional rack observation, preserve real device versions, console fields and endpoint results separately. Do not record a measured outage duration unless an authorized future runtime test actually measures it.
- What you should see
- The report distinguishes paper predictions, optional collected outputs and unmeasured failure behavior.
- Why this step matters
- Honest evidence labels prevent a technically useful exercise from becoming a fabricated lab completion.
Verify
- Both host gateways equal the correct virtual .1 address, not R1's physical .2.
- The HSRP and VRRP worksheets identify both LAN groups, both routers and current roles.
- The R1-failed model has complete request and reply paths through R2.
- Priority 120 minus decrement 30 equals effective 90; preemption is checked separately.
- Restore original addresses, roles and gateway choices; record optional outputs as observations only if actually collected.
Troubleshoot
- If a host still targets .2 after takeover, inspect its selected route before changing the redundancy protocol.
- If both routers claim the active role on one LAN, compare VLAN, protocol/version, group, virtual IP and peer communication; do not accept dual-active as the healthy baseline.
- If a gateway responds but Server1 does not, inspect destination and return routes, interfaces and endpoint filtering.
- If optional VRRP support is unavailable, stop at the explicit paper alternative rather than importing unlicensed images or inventing CLI output.
GNS3 does not provide Cisco images. Use software only when the applicable license or entitlement permits that environment. Do not share or redistribute image files. Cisco Modeling Labs is the official alternative; its reference images are licensed for use within CML unless separately licensed. A paper exercise needs no image, but does not establish hands-on competence. Virtual routers do not reproduce physical radios, PoE delivery, hardware forwarding rates or failover timing.
- Restore both paper protocols to their original independent baselines and erase the temporary wrong host gateway.
- Optional observation is read-only; leave the instructor's prepared rack unchanged and close authorized console sessions.
- Retain measured and predicted evidence separately; image rendering and independent review remain parent-owned.
Practice set
Answer before you reveal
01Why is the virtual gateway not a third physical router?
The topology contains only R1 and R2 as routers. Which one handles the virtual identity can change without adding a device.
02What does local mean in R2's active-address field?
Operational output is relative to the console being read. Pair the word with interface and group before identifying the forwarding device.
03Does failed-active replacement require preemption?
A standby replacing a missing active router is failure handling. A recovered preferred router taking the role back is a different decision.
04What is R1's effective priority after a decrement of 30 from 120?
The configured preference and effective value differ while the tracked condition is down. Role change still depends on the applicable preemption rules.
05Why does the model put a virtual gateway on Server1's LAN?
If Server1 remained pointed at failed R1's real address, client-side takeover could succeed while end-to-end communication still failed.
06Does a VRRP Master label contradict RFC 9568 Active?
Translate the observed field with the platform documentation. Do not confuse vocabulary updates with proof that the running protocol is faulty.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Hosts must use the virtual gateway to benefit from the group.
- Read protocol, interface, group, role and peer fields together.
- HSRP preemption defaults differ from VRRP; inspect actual policy.
- Tracking can change effective priority but does not prove application health.
- Trace both forward and return paths through the surviving router.
- Keep hypothetical status records distinct from captured output.