Production Campus: Multicast and QoS for Live Video
MediaWorks has a three-building production campus with 2,200 users and 400 editors. Editors use multicast for live video feeds (20 streams, 30 Mbps each) and shared storage; the backbone is 10G, but multicast is flooding all VLANs because PIM sparse mode has no RP redundancy and the RP is a single 3560. During live events, unicast file transfers to storage hit 7 Gbps and video drops. QoS is trust-all, with voice on the same queue as bulk backup. The company will add a fourth building and 100 more editors in nine months. The WAN has a 500 Mbps MPLS link to a post-production house. There is no multicast boundary. The network team has two CCNPs and no DNA Center.
1. Design the multicast topology: PIM mode, RP placement and redundancy, boundaries, and IGMP snooping. Why not dense mode?
Read the worked answer
Use PIM sparse mode with a redundant anycast RP pair in the core, or PIM BSR. The single 3560 RP is a failure domain; replace it with two routers, each with the same RP address on a loopback, and MSDP between them for source information. For the 20 live feeds, use SSM (232.0.0.0/8) because the receivers know the sources; SSM eliminates RP dependence and reduces join latency. Keep ASM for discovery only if needed. Put multicast boundaries at the distribution uplinks so mroute state does not leak to all VLANs; enable IGMP snooping and an IGMP querier in each VLAN. Do not use dense mode: it floods and repeats traffic, which is exactly the current symptom. Route multicast on the 10G backbone with PIM on all routers, and set a boundary toward the WAN unless the post-production house needs feeds.
2. Design QoS for the campus: trust boundary, classification, queuing, and how to protect video and voice from 7 Gbps storage bursts.
Read the worked answer
Set the trust boundary at the access switch for voice and video, but not for editor PCs. Mark voice EF, video AF41, storage and backup AF11 or scavenger, and call signaling CS3. Use an 8-class model with a priority queue for voice limited to 10%, a video queue with 30% bandwidth and 4-queue WRED, and a scavenger queue with 5%. On 10G links, enable egress shaping only where oversubscription exists; do not shape the core to 7 Gbps. Storage bursts should be classified as scavenger or AF11 and policed at the access edge to prevent them from starving video. Apply QoS on the WAN 500 Mbps link with shaping to 90% and a priority queue for voice. Validate with show policy-map interface and synthetic traffic. Trust-all is the root cause; fix classification first, then queuing.
3. Plan for the fourth building and multicast to the post-production house. What design changes and validation steps are required?
Read the worked answer
For the fourth building, add a distribution pair and dual-home it to the core with routed /31 links; run PIM on the new links and place the building in the same multicast domain, with an IGMP querier per VLAN. Extend the anycast RP or BSR scope to the new building, but do not add a third RP. For the WAN to post-production, use a multicast boundary and MSDP if the provider supports it; otherwise tunnel multicast over GRE or use SSM with a controlled source. QoS on the 500 Mbps WAN must reserve voice and video and shape to 90%. Validate with mroute, mstat, IGMP groups, and a canary feed before the editors move. Add 100 editors only after the new distribution and RP redundancy are stable; otherwise the existing 3560 remains a single point.