Skip to content
Log in Sign up My account

4.4 and 4.5 Multicast Design

Blueprint 4.4: Multicast routing concepts (source trees, shared trees, RPF, rendezvous points)

  • Compare source trees and shared trees and the PIM modes that build them
  • Explain what RPF protects and how unicast design can break multicast
  • Choose an RP discovery and redundancy method

Blueprint 4.5: Services based on multicast (SSM, PIM bidirectional, MSDP)

  • Pick SSM, PIM-SM, or bidirectional PIM for a given application
  • Use MSDP and anycast RP for redundancy and inter-domain sharing

The mechanics (IGMP, RPF check, register, SPT switchover, show ip mroute) are taught in ENCOR multicast. This page is about which model to deploy and why. The ENCOR diagrams E36 and E38 cover SSM and RPF visually.

4.4 Multicast routing concepts

Why design matters

Multicast sends one copy per link toward all interested receivers, which saves bandwidth and source load. The cost is state in every router on the tree and sensitivity to the unicast routing table. Good multicast design controls three things: how much state each router holds, how receivers find sources, and how the network reacts when a router, link or RP fails.

Source trees and shared trees

Source tree (SPT) Shared tree (RPT)
State (S,G) (*,G)
Root The source The rendezvous point
Path Shortest path from source to receivers Source to RP, then RP to receivers
State per router One entry per source per group One entry per group
Path quality Optimal Can be suboptimal, extra latency
Needs an RP No (SSM) or only to start (SM) Yes 
graph LR
  S["Source"] --> FHR["First-hop router"]
  FHR -->|"Register / (S,G)"| RP["RP"]
  RP -->|"Shared tree (*,G)"| R1["Last-hop router 1"]
  FHR ==>|"Source tree (S,G) after switchover"| R1
  R1 --> H1["Receiver"]

PIM dense mode floods and prunes. It is simple but wasteful, so it is rarely the right answer in a modern design except where a legacy application demands it. PIM sparse mode builds the shared tree on request and switches to the source tree for efficiency, which is the default model for general-purpose enterprise multicast. By default, the last-hop router switches to the shortest path tree as soon as it receives the first packet. ip pim spt-threshold infinity keeps receivers on the shared tree and reduces (S,G) state at the cost of extra path length through the RP.

RPF: the loop guard that can break your design

A router accepts a multicast packet only if it arrives on the interface the unicast routing table would use to reach the source (or the RP for shared-tree traffic). Packets that fail are dropped. This prevents loops without a spanning tree, but it ties multicast to unicast routing.

Design consequences:

  • Asymmetric or equal-cost unicast paths. With ECMP, the router picks one RPF interface per source. Multicast uses one path, not all of them, unless you configure ip multicast multipath.
  • Static routes and tunnels. A tunnel that carries unicast but whose RPF interface is a different physical link causes RPF failures. A static ip mroute fixes this when you cannot change unicast routing.
  • Redistribution and route summarisation. A summary that hides the specific source prefix, or a default route toward a firewall, can cause the wrong RPF interface.
  • Convergence. After a link failure, multicast cannot reconverge until unicast has. Unicast tuning and BFD directly improve multicast recovery. PIM hellos default to 30 seconds, so adding BFD or tuning the hello and hold timers on critical links shortens failover.

Exam trap

When multicast works from one source and not from another, or works one way and not back, think RPF before thinking PIM. The unicast route toward the source decides where multicast is accepted.

Rendezvous point design

Every sparse-mode design needs an answer to two questions: how do routers learn the RP, and what happens when it fails?

Method Standard How it works Strength Weakness
Static RP Yes ip pim rp-address on every router Simple, predictable, no dependency Manual at scale, no automatic failover alone
Auto-RP Cisco proprietary RPs announce to 224.0.1.39, a mapping agent sends the result to 224.0.1.40 Dynamic, long history Proprietary, needs a way to carry the discovery groups in sparse mode
BSR Yes (RFC 5059) Candidate RPs advertise to an elected bootstrap router, which floods the RP set in PIM messages Standards based, multi-vendor More moving parts, bootstrap router is another role
Anycast RP Yes Multiple RPs share one address; MSDP (or PIM) keeps them in sync Fast failover, load sharing Needs MSDP or PIM anycast RP configuration

For most enterprises a static RP with anycast RP and MSDP gives the fastest failover and fewest surprises. Use Auto-RP or BSR when you need dynamic RP assignment per group range across many routers or multiple vendors.

RP placement guidance:

  • Put the RP at the centre of the multicast topology, typically the core or the data centre, where both sources and receivers have short paths.
  • Use different RPs for different group ranges if you want to share load, or if business units must be separated.
  • Do not use an access-layer switch as an RP. Its failure takes the shared tree with it.
  • Protect the RP. Filter which sources may register and which groups it serves using an ACL on ip pim rp-address and ip pim accept-register.

Layer 2 is part of the design too. Without IGMP snooping, a switch floods multicast to every port in the VLAN, defeating the point of multicast. With snooping you need an IGMP querier in VLANs that have no multicast router, or membership state times out.

ip multicast-routing distributed
ip pim rp-address 10.255.255.100             ! anycast RP address
ip pim accept-register list SOURCES-OK        ! limit who may register
ip pim ssm default                             ! 232.0.0.0/8 for SSM
interface GigabitEthernet1/0/1
 ip pim sparse-mode

Scope and boundaries

Address plans matter: 224.0.0.0/24 is link-local, 232.0.0.0/8 is SSM by default, and 239.0.0.0/8 is administratively scoped (private, like RFC 1918). Use 239.x.x.x inside the enterprise and divide it into scopes (site, region, global). ip multicast boundary stops a scope from leaking across a boundary, and prevents internal traffic from reaching the Internet edge or a partner.

4.5 Services based on multicast

Choosing the PIM model

PIM-SM SSM Bidirectional PIM
Application pattern General purpose One-to-many with known sources Many-to-many
RP needed Yes No Yes (can be a phantom address)
Router state (*,G) and (S,G) (S,G) (*,G) only
Receiver signalling IGMPv2 or v3 IGMPv3 (or SSM mapping) IGMPv2 or v3
Security Any source can send to the group Receiver names the source Any source can send
Convergence Depends on RP Depends only on unicast Depends on RP and DF 
graph TB
  Q{"Application pattern?"}
  Q -->|"One source, known address,<br/>many receivers"| SSM["SSM (232/8)"]
  Q -->|"Many sources and receivers<br/>in one group"| BD["Bidirectional PIM"]
  Q -->|"General or unknown sources"| SM["PIM sparse mode + RP"]

SSM is the best answer for IPTV, market-data distribution from fixed sources, and software distribution. It removes the RP, the registration, and the SPT switchover, and it is inherently safer because a receiver only gets what it asked for. Its cost is that receivers must know the source address and support IGMPv3. When hosts speak only IGMPv2, SSM mapping on the last-hop router translates a group request to a source.

Bidirectional PIM is the answer when hundreds of sources also receive, for example trading floors or collaboration tools. PIM-SM would create an (S,G) entry for every source in every router; bidir keeps only (*,G) and flows traffic both up and down the shared tree. Caveats: every router and platform on the path must support bidir, the shared tree is always used so paths are not optimal, and the RP (even if phantom) is a design dependency.

Exam trap

SSM does not need an RP, and a design that asks for "no RP to fail" points to SSM. But SSM requires the receiver to know the source. If the scenario has unknown or changing sources, SSM alone cannot be the answer.

MSDP and anycast RP

MSDP connects RPs. Two design uses:

  1. Anycast RP inside one domain. Two or more RPs share the same loopback address. Receivers and sources use the nearest one. MSDP between their unique addresses shares information about active sources, so receivers joined to one RP still hear a source registered with another. If one RP fails, unicast routing converges to the other. This gives redundancy and load sharing, and recovery depends on the IGP rather than on a timer-based RP election. It is the preferred RP resilience mechanism in a large enterprise.
  2. Between domains. Each PIM domain keeps its own RP. MSDP lets the domains exchange source-active messages, so a receiver in one domain can join a source in another without sharing one RP. It is common between business units, data centres, or with partners.

MSDP details worth knowing for design: it peers over TCP port 639, applies a peer-RPF rule to avoid loops, supports mesh groups for full-mesh peering, and is defined for IPv4 only. For IPv6, the equivalent designs use embedded RP (RFC 3956) and PIM anycast RP. SSM needs none of this. Filter SA messages with ip msdp sa-filter so internal groups do not leak to a partner.

! RP1 and RP2 both carry 10.255.255.100/32 on Loopback100
interface Loopback100
 ip address 10.255.255.100 255.255.255.255
 ip pim sparse-mode
ip pim rp-address 10.255.255.100
ip msdp peer 10.255.0.2 connect-source Loopback0
ip msdp originator-id Loopback0

Multicast across the WAN

Multicast needs support in the transport. Over DMVPN and GRE tunnels, multicast replicates at the hub, so hub CPU and bandwidth grow with the number of spokes. Over a provider MPLS VPN, it depends on the provider offering multicast VPN service; if not, the enterprise tunnels multicast inside GRE or uses unicast replication. Design choices also include whether to use SSM over the WAN to avoid depending on an RP at a remote site. See DMVPN for the NHRP multicast mapping mechanics.

Design exercise

Scenario. A financial firm operates two data centres 40 km apart, joined by dark fibre with an IGP. Market-data feeds come from three fixed external-facing gateways in data centre A and are consumed by trading applications in both sites. Separately, a voice-and-chat collaboration platform lets any trader transmit to a room group, and every trader also receives. A partner firm runs its own PIM domain and needs access to one feed.

Requirements.

  • No single point of failure for multicast control.
  • Minimal state and fastest convergence for the market data.
  • The collaboration platform scales to hundreds of senders.
  • The partner may receive only one named feed.

Constraints.

  • The trading applications can use IGMPv3.
  • The collaboration platform's application supports IGMPv2 only.
Model answer
  • Market data: SSM in 232.0.0.0/8. Sources are fixed and known, and the applications support IGMPv3, so there is no RP to fail, no register, and no SPT switchover. Convergence depends only on the IGP, which BFD accelerates.
  • Collaboration: bidirectional PIM with a phantom RP address in a range that is routed in both data centres. Many senders are also receivers, and bidir keeps only (*,G) state. IGMPv2 receivers are fine because bidir does not need v3. Because there are no registers, hundreds of senders add no source state.
  • Control-plane resilience: if any group needs sparse mode (for example other applications), use anycast RP with MSDP between one RP in each data centre. A failure converges through the IGP. For bidir, the phantom RP's redundancy comes from routing the same address with different prefix lengths in the two sites.
  • Partner: because the feed is SSM, give the partner an (S,G) subscription directly with IGMPv3 or SSM at the border. Use a multicast boundary and a group ACL so only that feed crosses. MSDP with SA filtering is the alternative if the partner needed sparse-mode groups.
  • Scoping: use 239.x.x.x scopes for internal groups and filter at the boundary.

Rejected alternatives.

  • PIM-SM for everything. It works but needs an RP, creates (S,G) state for every collaboration sender, and gives slower convergence for market data.
  • SSM for the collaboration platform. Receivers cannot name hundreds of changing sources, and the application is IGMPv2 only. SSM mapping would not scale to that pattern.
  • Auto-RP with a single mapping agent. The mapping agent becomes another single point of failure and the protocol is proprietary.
  • One RP in data centre A. Loss of data centre A removes RP function for the whole firm.

Quick check

Why does an ECMP design sometimes deliver multicast over only one of the equal paths?

RPF selects one incoming interface per source (or RP). Without ip multicast multipath, the router uses a single path for multicast, even if unicast load-balances.

Which PIM model needs no RP and which needs IGMPv3 on receivers?

SSM needs no RP and requires IGMPv3 (or SSM mapping for IGMPv2 hosts).

What does MSDP carry, and what does it not carry?

It carries Source-Active messages naming active sources between RPs. It does not carry multicast data or replace PIM.

References

  • IP Multicast Configuration Guide, Cisco IOS XE (search "IP Multicast Routing Configuration Guide IOS XE" on cisco.com)
  • Cisco Validated Design: IP Multicast (search "IP multicast design guide" on cisco.com)
  • RFC 7761 (PIM-SM), RFC 5015 (bidirectional PIM), RFC 4607 (SSM), RFC 3618 (MSDP), RFC 5059 (BSR), RFC 3956 (embedded RP), all at rfc-editor.org
  • Cisco Live On-Demand Library: search "multicast design"