A public health clinic network has sparse civic camera viewers across sites and wants shared-tree pull toward an RP instead of dense flood-and-prune. Which PIM mode best matches that requirement?
Select an answer to reveal the explanation.
Short Explanation
Sparse Mode is the “ask before you send” club: receivers join, traffic flows toward an RP, and idle branches stay quiet. Dense Mode is the opposite—blast everywhere then prune. For a few camera watchers on a big civic WAN, Sparse Mode is the sane default.
Full Explanation
A public-health clinic fabric with sparse camera viewers across sites needs on-demand distribution rather than constant flood-and-prune. PIM Sparse Mode matches that requirement by using explicit Joins toward a rendezvous point for shared trees (and optionally toward sources for SPTs). Idle branches stay quiet, which conserves WAN and campus bandwidth for clinics that only occasionally watch civic camera groups.
PIM Dense Mode flood-and-prune on every clinic WAN link is the opposite traffic pattern: it initially floods and relies on Prunes. That wastes capacity where receivers are sparse and links are precious.
IGMP proxy alone without any multicast routing protocol may help a stub edge forward membership toward an upstream router, but it does not by itself build multi-site shared trees across a clinic WAN the way PIM-SM does.
DVMRP distance-vector trees built only from RIP metrics are a legacy dense-style approach, not the modern sparse explicit-join model the stem asks for.
Exam caveat: Sparse Mode still needs a coherent RP plan (static, Auto-RP, or BSR) and working unicast RPF; choosing PIM-SM without RP reachability leaves receivers unable to join shared trees.
Operational check: confirm PIM-SM on clinic WAN routers, verify RP mapping, join a test camera group at a remote site, and ensure (*,G)/(S,G) state forms without dense flood on unused branches. Document RP and group ranges in the health-department multicast standard.