
hsrp gives two routers one shared virtual gateway ip
standby 1 ipwhy your network doesn't fall over when a router dies
ever unplug a router in a lab and watch nothing happen. no dropped pings, no angry users, no ticket. that's not luck, that's hsrp doing its job quietly in the background. hot standby router protocol takes two physical routers and makes them look like one gateway to every pc, phone, and printer on the network. if you've ever wondered how "the network just works" even when hardware fails, this is usually the answer.
the virtual ip is the whole trick
your devices don't point their default gateway at a real router interface. they point it at a virtual ip that both routers agree to share.
standby 1 ip 192.168.1.1
group 1 here is just a label so you can run multiple hsrp groups on the same interface if you need to. the ip is the address every endpoint uses as its gateway. only one router answers to that ip and mac at a time, the active one. the other router sits there as the standby, listening for hellos, ready to take over the second the active goes quiet.
as a defender this matters because that virtual ip and its virtual mac are a single point that everything trusts. if you're auditing a network, find that virtual ip and confirm exactly which two devices are allowed to claim it. anything else on the segment sending hsrp hellos for that group is either a misconfigured device or someone trying to insert themselves as the gateway.
priority and preempt, who gets to be in charge
each router in the hsrp group has a priority value, default is 100. whichever router has the higher priority wins the active role. preempt is the setting that decides whether a recovered router is allowed to take the job back once it comes back online.
without preempt, a router that reboots after a failure comes back up as standby and just stays there, even if it's the "primary" and has higher priority. with preempt enabled, it reclaims active status automatically the moment it's healthy again. this is a design choice, not a bug, and it matters for change control. if you're troubleshooting a failover that "shouldn't have happened," check preempt settings first before you start blaming cables.
interface tracking, the part that actually detects failure
here's the thing hsrp doesn't do by default: notice that your uplink died. hsrp only knows the router it's running on is alive. it has no idea if that router's path to the internet or the core just disappeared. that's what interface tracking is for.
you tell hsrp to watch a specific interface, usually the wan or uplink port. if that tracked interface goes down, hsrp automatically drops the router's priority by a configured amount. if that drop pushes it below the standby's priority, the standby takes over as active, even though the router itself is technically still running fine.
this is the difference between "the router is dead" and "the router is alive but useless." a lot of real world outages happen because someone set up hsrp for router failure but never configured tracking, so when the uplink dies, the router happily stays active with a gateway that leads nowhere. everyone loses internet and nobody understands why the "redundant" setup didn't save them.
what to actually check on your own gear
pull up your hsrp config on both routers and read it like an auditor, not like the person who wrote it. confirm the virtual ip matches what your dhcp scope hands out as the default gateway. confirm priority values make sense, the router you want as primary should have the higher number. confirm preempt is set the way you actually want it, and confirm tracking is pointed at the real uplink interface, not some interface that's always up regardless of internet status.
also check for hsrp authentication. plain text or no authentication means anything on that broadcast domain can send hello packets and potentially insert itself into the group. that's a rogue gateway waiting to happen. md5 authentication on hsrp is cheap insurance for something this important.
the takeaway
hsrp is the reason a lot of failovers happen and nobody notices. that's the goal. but "nobody noticed" only holds up if priority, preempt, and tracking are actually configured correctly and someone bothered to test the failover on purpose instead of finding out during a real outage. go check your own routers, confirm the virtual ip, confirm tracking is watching the right interface, and pull the cable yourself in a maintenance window before the internet does it for you.