3.8FHRP and multicast

A host normally has only one default gateway, so if that router dies the whole segment loses external connectivity. FHRP (First Hop Redundancy Protocol) lets multiple routers share one virtual IP and virtual MAC so that, from the host's perspective, the gateway is always alive. Multicast, meanwhile, efficiently delivers one transmission to many receivers, but diagnosing it with unicast instincts always leads to a dead end—the key is the reverse-direction idea that paths are built from the receiver back toward the source. This section treats both from the practical angles of differing defaults and diagnostic procedure.

3.8.1Differing defaults of HSRP and VRRP

• HSRP is Cisco-proprietary with the roles active (actually forwarding) and standby (waiting). The virtual MAC for the virtual IP handed to hosts is 0000.0c07.acXX in HSRPv1 (XX being the group number in hex) and 0000.0c9f.fXXX in HSRPv2. Priority defaults to 100 and the higher value becomes active—but the crucial point is that preempt is disabled by default.
• VRRP is an IETF standard (RFC) with the roles master and backup and a virtual MAC of 0000.5e00.01XX. Its priority also defaults to 100, but the decisive difference is that preempt is enabled by default. VRRP is the choice in multi-vendor environments. Relatedly, GLBP (Cisco-proprietary) differs from both by load-balancing across multiple routers simultaneously while providing redundancy.
• The difference in preempt defaults causes the most incidents in practice. In HSRP, even if you design the high-priority router to be active, after that router reboots it remains standby, and the intended path (say the high-bandwidth link) goes unused. To restore the design you must explicitly configure standby <group> preempt. VRRP conversely fails back by default, so account for the possibility of an unintended switchback.
• Combining interface tracking (standby 1 track <if> <decrement>) lets a router lower its own priority and hand over the role when an upstream link fails. Configuring tracking but forgetting preempt means the switchover does not happen even as the priority drops (or it never fails back after recovery), so design the two together.

3.8.2Multicast delivery and RPF

• The RPF (reverse path forwarding) check is the core loop-prevention mechanism of multicast. For each received multicast packet it verifies whether the interface it arrived on matches the interface the unicast routing table would use to get back toward the source, and discards it on mismatch. Consequently, asymmetric unicast routing can break multicast while unicast still works.
• PIM SM (sparse mode) uses explicit joins, delivering only down branches that requested traffic. The receiver-side router sends a (*,G) join toward the RP (rendezvous point) and begins receiving over the shared tree (RPT). Once traffic flows, it switches to the more efficient SPT (shortest-path tree, (S,G))—the SPT switchover. An inconsistent or unreachable RP breaks sparse mode entirely, so check with show ip pim rp mapping that every router agrees on the RP.
• IGMP signals "I want this group" between a host and its adjacent router (inter-router delivery is PIM's job). v2 handles per-group join/leave and querier election. v3 decisively adds the ability to specify the source, which is what enables SSM (source-specific multicast, 232.0.0.0/8). SSM needs no RP because receivers directly specify (S,G), simplifying the design and preventing reception from unwanted sources.
• Bidir-PIM is optimized for many-to-many use (everyone is both sender and receiver): it uses only the shared tree without switching to the SPT and keeps no per-source (S,G) state, dramatically reducing router state. MSDP (Multicast Source Discovery Protocol) lets RPs in different domains exchange source information via SA (source active) messages, enabling interdomain multicast and anycast RP (multiple RPs sharing one address for redundancy and load sharing).

Suppose you configure HSRP on two campus distribution switches (DSW1 and DSW2), designing DSW1—which owns the high-bandwidth uplink—as active with priority 150 and DSW2 as standby at the default 100. One night you reboot DSW1 for maintenance; as expected DSW2 takes over as active and traffic continues. But after DSW1 returns, DSW2 remains active and traffic keeps flowing over the narrower uplink. Thinking "priority 150 is higher, so it will fail back on its own eventually" misreads the HSRP defaults. Because HSRP preempt is disabled by default, a higher-priority router does not reclaim the role while the current active is healthy. The fix is standby 1 preempt on DSW1, which reliably returns the higher-priority router to active when it comes back. Had the same design used VRRP, preempt is enabled by default and it would have failed back with no action—this difference in defaults is the single most important way to tell the two protocols apart. Further, in this environment, if DSW1's upstream link fails while DSW1 stays active, you land in the worst state: the gateway is alive but nothing can reach outside. To prevent that, combine interface tracking such as standby 1 track <upstream IF> 60, dropping the priority from 150 to 90 on an upstream failure so DSW2 (at 100) takes over. But configuring tracking while forgetting preempt means DSW2 cannot claim the role and no switchover occurs, so always design the two together. Separately, after starting an internal video multicast on the same campus, a report arrives that video fails to reach a few floors. Unicast connectivity is fine and ping works. Concluding "unicast works, so routing is fine" is wrong, because multicast has an additional gate: the RPF check. RPF verifies whether the interface a packet arrived on matches the interface the unicast routing table would use to return toward the source, discarding it on mismatch. Running show ip rpf <source IP> on the upstream router for the affected floors shows the arrival interface and the RPF interface disagree. The cause is an asymmetric path created during a routing change, where forward and return traffic take different links—invisible until now because unicast passes without complaint. In a PIM SM environment you additionally confirm with show ip pim rp mapping that all routers agree on the same RP and with show ip mroute that the (*,G) and (S,G) entries were created as expected. And if the source is fixed and receivers can specify it, moving to SSM (232.0.0.0/8) with IGMPv3 removes the need for an RP entirely, eliminating the whole class of RP-induced failures from the design.

3.8.3Section summary

• HSRP (Cisco, active/standby, virtual MAC 0000.0c07.acXX, priority default 100) has preempt disabled by default while VRRP (standard, master/backup) has it enabled; design tracking and preempt together
• The RPF check depends on unicast routing, so asymmetric paths drop multicast only; compare the arrival interface with the RPF interface using show ip rpf
• PIM SM starts on the RP shared tree and switches to the SPT, IGMPv3 source specification enables SSM (no RP), bidir cuts state, and MSDP exchanges SA messages between RPs