Skip to content
Log in Sign up My account

Interdomain Multicast: PIM-SM, MSDP, Anycast RP, MBGP and SSM

Multicast inside one domain is a solved problem. Between domains, with separate rendezvous points and separate administrations, it is where designs get complicated. This article covers how PIM Sparse Mode behaves across domains, how MSDP shares source information between RPs, how anycast RP gives you redundancy, how MBGP supplies the RPF information, and why Source-Specific Multicast (SSM) removes most of that machinery.

The problem

In PIM-SM, receivers join a group (*,G) towards a rendezvous point (RP). Sources register with the RP. The RP is the meeting place. If there is one RP per domain, then a receiver in domain B has no way to learn that a source is active in domain A, because the source registered with RP-A and the receiver joined at RP-B.

graph LR
    S["Source<br/>domain A"] --> RPA["RP-A"]
    RPB["RP-B"] --> R["Receiver<br/>domain B"]
    RPA -. "MSDP<br/>Source-Active messages" .-> RPB

Three things have to work for interdomain multicast with ASM (any-source multicast):

  1. Something must tell RP-B that a source is active at RP-A. That is MSDP.
  2. Multicast RPF checks must succeed across domain boundaries, and may need a different path from unicast. That is MBGP, or static mroutes.
  3. The data trees must be built between domains. That is PIM-SM between border routers, with the RP and source trees joined.

PIM-SM refresher

  • Receivers signal interest with IGMP (IPv4) or MLD (IPv6). IGMPv3 and MLDv2 add source filtering, which SSM needs.
  • The last-hop router sends a (*,G) join towards the RP, building the shared tree (RPT).
  • A source's first-hop router encapsulates data in PIM Register messages to the RP. The RP joins (S,G) towards the source, then sends a Register-Stop.
  • Receivers' last-hop routers usually switch to the shortest-path tree (SPT) with an (S,G) join towards the source, then prune the source off the shared tree.
  • The RPF check decides which interface is the correct incoming interface for a source or RP. It uses the unicast routing table by default, or the multicast RIB when configured.

PIM-SM is specified in RFC 7761. RP discovery can be static, Auto-RP (Cisco proprietary) or BSR (RFC 5059). For interdomain work, static RP or anycast RP is typical, since Auto-RP and BSR messages are normally kept inside the domain.

MSDP

Multicast Source Discovery Protocol (RFC 3618) connects RPs in different PIM-SM domains. It runs over TCP port 639 between RPs, and it is IPv4 only.

How it works:

  1. A source registers with its local RP.
  2. The RP creates a Source-Active (SA) message with the source, group and RP address, and sends it to its MSDP peers. Some implementations encapsulate the first data packet.
  3. Peers forward the SA away from the originator, applying a peer-RPF check so that SA messages do not loop.
  4. If a remote RP has receivers for that group (it has a (*,G) entry with outgoing interfaces), it joins the (S,G) tree towards the source across the domain boundary.
  5. The remote RP stores the SA in its cache, and the source becomes reachable for receivers in that domain.

Minimal IOS configuration on RP-A (RP address is Loopback0 192.0.2.1; remote RP 198.51.100.1):

ip multicast-routing
ip pim rp-address 192.0.2.1
!
interface Loopback0
 ip address 192.0.2.1 255.255.255.255
 ip pim sparse-mode
!
ip msdp peer 198.51.100.1 connect-source Loopback0 remote-as 65002
ip msdp originator-id Loopback0

Verification:

show ip msdp peer
show ip msdp sa-cache
show ip msdp summary
show ip mroute 224.1.1.1
show ip rpf 203.0.113.10

Common MSDP problems:

  • Peer-RPF failure. SA messages from a peer are accepted only if the peer is on the best path towards the originating RP, determined from BGP (or via mesh groups, default peers or a static route). If you peer over eBGP, the rule is tied to BGP next-hop and AS-path of the originating RP address, so that address must be in BGP.
  • Source address mismatch. The connect-source and the originator-id should be stable loopbacks that routing always reaches.
  • SA flooding. Without filters, every internal source is advertised to the world. Use ip msdp sa-filter and TTL thresholds to control it, and filter the group ranges that are local only (239.0.0.0/8 administratively scoped, 224.0.0.0/24 link-local, and others).
  • SA limits. Use ip msdp sa-limit per peer to protect the router from state exhaustion.

Warning

MSDP SA messages are an attack surface. Anyone who can inject sources can create state on your RP. Filter inbound SAs, limit the count per peer, and authenticate peers with MD5 where the implementation supports it.

Anycast RP

Anycast RP gives you RP redundancy and load sharing. Two or more RPs are configured with the same RP address on a loopback, and each is advertised into the IGP. Sources and receivers use the topologically nearest RP. If an RP fails, the IGP reconverges and clients use another.

Because each RP now sees only the sources registered to it, the RPs must share source information with each other. There are two methods:

  • MSDP between the anycast RPs (RFC 3446). Each RP has a unique address for MSDP peering and the shared anycast address for PIM. This is the common approach and works with any vendor that supports MSDP.
  • PIM-based anycast RP (RFC 4610). The RPs exchange Register messages directly, with no MSDP needed. It is the cleaner choice on platforms that support it.
graph TB
    S1["Source 1"] --> RP1["RP1<br/>anycast 10.0.0.1<br/>unique 10.255.0.1"]
    S2["Source 2"] --> RP2["RP2<br/>anycast 10.0.0.1<br/>unique 10.255.0.2"]
    RP1 <-- "MSDP over unique addresses" --> RP2
    R1["Receiver 1"] --> RP1
    R2["Receiver 2"] --> RP2

IOS-XE configuration on RP1 for MSDP-based anycast RP:

ip pim rp-address 10.0.0.1
!
interface Loopback0
 description Anycast RP address
 ip address 10.0.0.1 255.255.255.255
 ip pim sparse-mode
!
interface Loopback1
 description Unique address for MSDP
 ip address 10.255.0.1 255.255.255.255
 ip pim sparse-mode
!
ip msdp peer 10.255.0.2 connect-source Loopback1
ip msdp originator-id Loopback1

The originator-id must be the unique address. If it is the anycast address, the peer RP sees SA messages that appear to be from itself, and drops them.

For three or more anycast RPs, put them in an MSDP mesh group so SA messages are not re-flooded between members:

ip msdp mesh-group ANYCAST 10.255.0.2
ip msdp mesh-group ANYCAST 10.255.0.3

Anycast RP is used inside a domain. For interdomain, each domain runs its own anycast RP set and the sets connect to each other and to external peers through MSDP.

MBGP and multicast RPF

Multicast RPF uses the unicast routing table by default. If your multicast and unicast paths differ across a domain boundary (for example, a peering link that carries multicast only, or a different upstream), the RPF check needs different information.

Multiprotocol BGP (RFC 4760) carries multicast reachability in a separate address family. In IPv4, that is the ipv4 multicast address family (AFI 1, SAFI 2). Prefixes there are used only for RPF, not for unicast forwarding.

router bgp 65001
 neighbor 198.51.100.2 remote-as 65002
 !
 address-family ipv4
  neighbor 198.51.100.2 activate
 exit-address-family
 !
 address-family ipv4 multicast
  neighbor 198.51.100.2 activate
  network 203.0.113.0 mask 255.255.255.0
 exit-address-family

Verify RPF with:

show bgp ipv4 multicast summary
show ip rpf 203.0.113.10

Notes:

  • Advertise the source subnets and the RP addresses in the multicast address family. MSDP's peer-RPF check also depends on the RP address being resolvable.
  • When both unicast and multicast tables contain a prefix, the multicast table is preferred for RPF on most implementations. Behaviour varies by platform, so test it.
  • Alternatives are static ip mroute entries and, on some platforms, a separate multicast RIB. Static entries are fine for a small number of peers and do not scale.

SSM: the alternative

Source-Specific Multicast (RFC 4607) changes the model. Receivers join a channel (S,G) directly, using IGMPv3 or MLDv2, and the network builds the SPT toward the source with no RP, no shared tree and no source discovery.

graph LR
    R["Receiver<br/>IGMPv3 join (S,G)"] --> LHR["Last-hop router"]
    LHR -- "PIM (S,G) join<br/>along the unicast path" --> FHR["First-hop router"]
    FHR --> S["Source"]

What you no longer need:

  • RPs and RP redundancy.
  • MSDP.
  • Register processing.
  • Protection against unwanted sources sending to your group, because the receiver names the source it wants.

The default SSM range is 232.0.0.0/8 for IPv4 and FF3x::/32 for IPv6. Enable it on IOS-XE with:

ip pim ssm default
!
interface GigabitEthernet0/0/1
 ip pim sparse-mode
 ip igmp version 3

What SSM requires:

  • IGMPv3 or MLDv2 support in receivers and in the switches between them and the router. Older IGMP snooping implementations may not handle v3.
  • The application must know the source address, delivered by a directory, a configuration or an out-of-band announcement. This is simple for IPTV and financial feeds and harder for ad hoc collaboration tools.
  • For legacy receivers that only support IGMPv2 and IGMPv1, SSM mapping translates a (*,G) report to (S,G) using a static or DNS-based mapping on the router.

SSM works the same way inside and between domains, because source discovery is no longer needed. For new interdomain designs it is the first choice when applications can use it. Use ASM with MSDP when you must support legacy applications that cannot name their source.

Choosing an approach

Requirement Approach
New application, source known to receivers SSM
Legacy ASM application inside one domain PIM-SM with anycast RP
Legacy ASM application between domains PIM-SM, MSDP, and MBGP or static RPF
Many-to-many (conferencing) inside a domain PIM-SM, or Bidir-PIM (RFC 5015)
Multicast path differs from unicast MBGP multicast address family

Troubleshooting order

  1. Does the receiver send an IGMP report? (show ip igmp groups)
  2. Does the last-hop router have a (*,G) or (S,G) entry? (show ip mroute)
  3. Does the RPF check pass towards the RP or source? (show ip rpf)
  4. Does the source's first-hop router register with the RP? (show ip mroute, look at the F and P flags)
  5. Does the RP see the SA from the remote domain? (show ip msdp sa-cache)
  6. Are TTL scoping, boundary ACLs or filters dropping the traffic? (show ip pim interface, check ip multicast boundary and TTL thresholds)
  7. Is a layer 2 device blocking it? (IGMP snooping and querier)

Practise these commands in a lab; the CCNP lab setup page describes how to build one.

References