A national retailer runs HSRP on a vPC pair. Some gateway-bound frames hash to the standby peer and use the HSRP virtual MAC. Those frames are dropped while peer-gateway is off. Why does enabling peer-gateway fix the forwarding?
Select an answer to reveal the explanation.
Short Explanation
You can think of peer-gateway as letting either peer accept gateway traffic addressed to its partner. When a flow hashes to the standby, it can route frames sent to the HSRP virtual MAC locally instead of sending them across the peer-link to be dropped. This does not change who wins the HSRP election.
Full Explanation
With vPC, a downstream device can hash a gateway-bound frame to the HSRP standby peer. The frame uses the HSRP virtual MAC, which is owned by the active peer. Without peer-gateway, the standby sends the frame across the peer-link toward the active peer. vPC loop avoidance drops traffic that would leave a vPC member after arriving on the peer-link, so the flow is black-holed. Peer-gateway lets the receiving peer route frames addressed to the gateway virtual MAC locally, avoiding that hairpin. It does not raise HSRP priority or enable preemption: a higher-priority router remains standby unless preempt is configured, so this feature does not change the election. The virtual IP remains associated with the HSRP virtual MAC; peer-gateway does not bind it to an upstream router’s physical MAC. Nor does peer-gateway shut down the keepalive, which the peers use to detect each other. Shutting down the keepalive is not how the feature works, and forcing both peers to forward every vPC member port could risk a dual-active pair. Caveat: configure peer-gateway on both peers; it does not fix an HSRP priority or preemption issue. Practical check: enable it, send a flow that hashes to the standby, and confirm that peer routes the frame without a peer-link drop.