Why is a redundant PIM stub router topology a bad network design decision?

Question

Options

• AMulticast convergence takes long
• BMulticast traffic duplication will occur
• CIt interferes with IGMP snooping
• DIt interfaces with PIM snooping

• A
  21% (8)
• B
  62% (24)
• C
  13% (5)
• D
  5% (2)

Explanation

In a redundant PIM stub router topology, both stub routers receive the same multicast stream from upstream and independently forward it onto the shared downstream segment - resulting in duplicate multicast traffic on that segment. Because stub routers don't participate in full PIM neighbor negotiation or assert processes the way non-stub routers do, there's no built-in mechanism to elect a single forwarder, so both flood the same stream simultaneously.

Why the distractors are wrong:

• A (convergence): Convergence delay is a concern in some multicast designs, but it's not the defining problem with redundant stub routers specifically - duplication happens even after the network has fully converged.
• C (IGMP snooping): IGMP snooping is a Layer 2 optimization; redundant stub routers create a Layer 3 forwarding problem and don't inherently break IGMP snooping.
• D (PIM snooping): Similarly, PIM snooping is a switch-level feature for optimizing PIM traffic at L2 - stub router redundancy doesn't interfere with it.

Memory tip: Think "stub = dead end." A dead-end street with two on-ramps delivering the same truck causes a traffic jam - redundant stubs deliver the same multicast payload twice. When you see "redundant stub," think duplication, not delay.

No community discussion yet for this question.