A fire district verifies behavior after the standby FHRP router becomes active. What should remain continuous for hosts at a conceptual level?
Select an answer to reveal the explanation.
Short Explanation
After failover, firehouse PCs should still ARP the same virtual gateway identity—the VIP (and its virtual MAC idea) stays the familiar face. Hosts are not suddenly looking up OSPF RIDs or SNMP strings as gateways. Continuity of that virtual first hop is the point.
Full Explanation
After a fire-district standby FHRP router becomes active, hosts should still use the same virtual IP (and, conceptually, the associated virtual MAC) as their default gateway. Continuity of that virtual first-hop identity is what allows ARP and forwarding to shift to the new active router without rewriting every endpoint. At concept level, verifying failover means confirming the VIP/VMAC role moved, not that unrelated identifiers changed.
Expecting each host’s OSPF router ID in the neighbor table to remain continuous fails by concept: hosts are not OSPF routers and do not use RIDs as gateways. Claiming the native VLAN ID on every trunk must renumber during FHRP failover fails by concept: trunk native VLANs are Layer-2 tagging policy, unrelated to first-hop VIP ownership. Saying the SNMP community string is what hosts ARP for instead of a gateway fails by concept: SNMP is management; hosts ARP for the gateway IP/MAC, ideally the FHRP virtual identity.
Exam caveat: physical router interface IPs may differ, but the host-facing VIP should stay constant across active/standby transition. Operational check: after forcing standby→active, ping the VIP from a firehouse PC, check ARP for the virtual MAC concept, and confirm forwarding continues without gateway reconfiguration.