A water utility wants high-rate camera groups to use one RP and low-rate SCADA sensor groups to use another so shared-tree load is engineered separately. What configuration concept enables that separation?
Select an answer to reveal the explanation.
Short Explanation
Think of two ticket windows: cameras queue at RP-A, sensors at RP-B. Group-to-RP maps (ACLs or candidate-RP scopes) send each range to the right window so one busy tree doesn’t crush the other. Same PIM-SM idea—just smarter who sits at the hub.
Full Explanation
A water utility that wants high-rate camera groups on one RP and low-rate SCADA sensor groups on another is asking for group-to-RP mapping. PIM-SM supports assigning different multicast group ranges to different RPs via static RP ACLs, Auto-RP scoped announcements, or BSR candidate-RP group lists. That separation engineers shared-tree and Register load independently so camera bursts do not crush SCADA shared-tree resources.
Identical anycast RP addresses without MSDP between two cores provides geographic RP anycast, not range-based separation of camera versus SCADA groups onto different RP roles.
A single BSR with no candidate-RP priorities or group scope ACLs will not intentionally split ranges across RPs; without group scoping you forgo the traffic-engineering lever.
Disabling SPT switchover globally so every group stays on one shared tree forever changes tree-type behavior but does not map different ranges to different RPs.
Exam caveat: overlapping group ACLs or inconsistent maps across routers cause intermittent RP disagreement—consistency of the map is as important as the map itself.
Operational check: implement non-overlapping ACLs/scopes for camera vs SCADA ranges, verify show ip pim rp mapping on WAN routers, and generate joins in each range to confirm separate RPs. File the mapping table in the utility OT/IT multicast design.