Bidirectional PIM and MSDP: Scaling Multicast Across Domains

Standard PIM sparse mode scales beautifully for a handful of sources and thousands of receivers. Push it the other direction, thousands of sporadic senders, or stretch it across administrative boundaries, and two very different tools take over: bidirectional PIM collapses per-source state inside a domain, and MSDP carries source knowledge between domains (and between redundant RPs). This article covers both, with a live MSDP peering between two RPs in the lab and a real SA cache capture. Part of the IP multicast guide.

The State Problem

Every active source in PIM-SM costs the network (S,G) entries on every router along its tree (the machinery covered in PIM sparse mode explained). For a trading floor app or a sensor fabric where ten thousand endpoints each transmit occasionally to the same group, that is ten thousand source trees, plus a register burst and an SPT decision for each. The RP becomes a state bottleneck, and most of those trees carry a few packets an hour.

Bidirectional PIM's answer is radical: keep only the shared tree, forever, and make it carry traffic both directions.

Bidirectional PIM: One Tree, Both Ways

In bidir PIM, a group's entire life happens on a single (*,G) tree rooted at the RP. Receivers join it downward exactly as in PIM-SM. Sources send upward along it: any router receiving multicast for a bidir group forwards it toward the RP, no registration, no (S,G) state, no RPF check against the source, and traffic flows down every branch with interested receivers as it passes. Three consequences:

• State is O(groups), not O(sources x groups). Ten thousand senders to one group cost exactly one mroute entry per router. This is the entire point.
• Paths are never optimal. Everything transits the RP's tree, so source-to-receiver latency is whatever the shared tree gives you. Bidir trades path quality for state, the opposite of the SPT switchover.
• Loop prevention changes. With traffic flowing both directions on one tree, standard source-RPF cannot work. Instead each segment elects a designated forwarder (DF), the router with the best route to the RP, and only the DF moves packets toward the RP. One forwarder per link means no loops, enforced by election rather than per-packet source checks. (The RPF check still governs the tree toward the RP itself.)

Configuration is ip pim bidir-enable plus flagging the RP's group ranges as bidir (ip pim rp-address 2.2.2.2 <acl> bidir). Every router in the domain must support and enable it. In show ip mroute, bidir groups carry the B flag, and notably the RP for a bidir group can be a phantom, just a routable address on the tree with no actual router owning it, since nothing ever registers to it. Use bidir when a group's sender count is large, sporadic, and many-to-many (collaboration, presence, telemetry ingestion); use SSM when sources are few and known (see the SSM article); standard PIM-SM covers the middle.

MSDP: Source Knowledge Across Boundaries

Inside one PIM domain, the RP knows every active source because first-hop routers register them to it. That knowledge stops at the domain edge: a receiver in your network joining group G has no way to learn about a source registered to a different organization's RP, or even to a second RP in your own network. MSDP (Multicast Source Discovery Protocol) is the bridge: RPs peer over TCP 639 and tell each other about active sources with Source-Active (SA) messages, each carrying (source, group, originating RP).

The lab runs two PIM domains: R2 is the RP for domain 1 (where the source 10.0.30.10 lives), R4 is the RP for domain 2, and the two peer directly:

! R2 (RP, domain 1)
ip msdp peer 4.4.4.4 connect-source Loopback0
ip msdp originator-id Loopback0

! R4 (RP, domain 2)
ip msdp peer 2.2.2.2 connect-source Loopback0
ip msdp originator-id Loopback0

R2# show ip msdp summary
Peer Address     AS          State    Uptime/  Reset SA    Peer Name
                                      Downtime Count Count
4.4.4.4          ?           Up       00:01:03 0     0     ?

When sources in domain 1 went active (they registered to R2, whose (S,G) entries carry the A flag, "candidate for MSDP advertisement"), R2 originated SA messages and R4's cache filled with real cross-domain source knowledge:

R4# show ip msdp sa-cache
MSDP Source-Active Cache - 2 entries
(10.0.30.10, 239.1.1.10), RP 2.2.2.2, AS ?,00:05:40/00:05:41, Peer 2.2.2.2
(10.0.30.10, 239.2.2.20), RP 2.2.2.2, AS ?,00:00:35/00:05:41, Peer 2.2.2.2

Now if a receiver in domain 2 joins 239.1.1.10, R4 checks its SA cache, finds the source, and sends an (S,G) join across the domain boundary toward 10.0.30.10. Traffic then flows natively; MSDP moves knowledge, never data. In true interdomain deployments (between autonomous systems) the (S,G) join follows MBGP multicast-safe paths and SA floods are RPF-checked peer-by-peer to prevent loops; inside one organization, a simple mesh or hub of MSDP peers suffices. SA entries age out about six minutes after the source stops, so show ip msdp sa-cache is also a liveness view of remote sources.

DF Election and the Phantom RP

Bidir's designated forwarder deserves more than a bullet. On every link in the domain (including host segments), the routers compare their unicast routes to the RP address, and the one with the best metric (tie: highest IP) wins DF duty for that link. Only the DF forwards traffic from the link toward the RP, and only the DF forwards traffic from the RP tree onto the link. One forwarder per link, both directions, elected once instead of checked per packet: that is how bidir stays loop-free while abandoning per-source RPF. DF election happens per RP, so multiple bidir RPs mean multiple elections; a link's DF for one group range can differ from its DF for another.

The phantom RP is the design trick that follows. Since nothing registers to a bidir RP and no SA state lives on it, the "RP" only needs to be a routable address that DF elections can measure distance to. The standard implementation puts the address on a loopback subnet advertised by two routers at different prefix lengths (a /30 and a /29 covering the same address), so the longest-prefix route wins and failover is pure IGP convergence with no protocol awareness at all:

! Router A (primary)                ! Router B (backup)
interface Loopback1                 interface Loopback1
 ip address 10.255.1.2 255.255.255.252    ip address 10.255.1.2 255.255.255.248
! RP address = 10.255.1.1 on all routers (no router owns it)
ip pim rp-address 10.255.1.1 BIDIR-GROUPS bidir

An RP that is literally an unassigned IP address is the purest statement of what bidir changed: the RP became a routing anchor, not a device.

Operating MSDP: Filters, Limits, and the Junk Problem

MSDP's operational reputation was earned in the early 2000s when worms discovered that scanning multicast groups generated SA storms across the entire internet's RP mesh. The lessons live on as standard practice. Filter what you originate (ip msdp redistribute list) so internal-only groups in 239/8 never leak into SA messages; filter what you accept (ip msdp sa-filter in <peer> list ...) so a sloppy peer cannot fill your cache; and cap the blast radius with ip msdp sa-limit per peer. Well-known junk (SSDP's 239.255.255.250, mDNS) belongs in every SA filter you ever deploy.

Verification mirrors BGP operations, which MSDP deliberately resembles: show ip msdp summary for peer state and SA counts (shown above), show ip msdp peer for the TCP details and applied filters, show ip msdp sa-cache for the actual learned sources, and debug ip msdp detail when an SA you expected never arrives. The most common real fault is an SA that exists on the origin RP but never appears at the peer, and it is almost always an outbound redistribute filter or the origin's (S,G) losing its A flag because the source went quiet.

Anycast RP: MSDP's Day Job

The most common MSDP deployment never crosses an organizational boundary. Anycast RP solves RP redundancy: configure the same RP address (say 10.255.255.1/32 on a loopback) on two or more routers, advertise it in the IGP, and every router's ip pim rp-address 10.255.255.1 resolves to the closest instance automatically. Registers and joins land on different RPs depending on where they originate, so the RPs must share source knowledge, and that is exactly an MSDP full mesh between them (peered on separate, unique loopbacks, never the anycast address):

! RP-A                                  ! RP-B
interface Loopback1                     interface Loopback1
 ip address 10.255.255.1 255.255.255.255    ip address 10.255.255.1 255.255.255.255
ip msdp peer 2.2.2.2 connect-source Loopback0
ip msdp originator-id Loopback0         ! (mirrored on each RP)

Failure handling comes free from the IGP: when an RP dies, its /32 disappears and every router converges to the survivor at unicast-routing speed, no PIM reconfiguration anywhere. Before this pattern, RP failover meant BSR timers; anycast RP made sub-second RP redundancy routine, and it remains the standard design in IOS XE deployments (NX-OS offers a PIM-native anycast alternative, RFC 4610, without MSDP).

Interdomain ASM, Assembled

For completeness, here is how the full interdomain ASM machine fits together when the destination is another autonomous system rather than a second internal domain. MBGP (BGP's IPv4 multicast address family) advertises which prefixes are reachable for RPF purposes across the boundary, keeping multicast tree-building decoupled from unicast forwarding policy. MSDP rides on top, RP to RP, telling each domain which sources are alive. When a local receiver joins group G, the local RP finds a matching SA in its cache, sends the (S,G) join toward the source along MBGP-derived paths, and native traffic flows across the AS boundary on the source tree. Three protocols, three jobs: MBGP answers "which way", MSDP answers "who is sending", PIM builds the tree. In SSM deployments the first two disappear, which is the strongest argument in SSM's favor whenever interdomain multicast comes up; the comparison is drawn out in the SSM article.

Choosing the Tool

Key Takeaways

• Bidir PIM keeps every group on one two-way shared tree: state collapses from per-source to per-group, paths run through the RP forever, and designated forwarder election replaces source RPF.
• MSDP peers RPs over TCP 639 and floods Source-Active messages; each SA is (source, group, RP), cached and aged. Data never rides MSDP.
• show ip msdp sa-cache on a remote RP is the proof that cross-domain source discovery works; the A flag on the originating RP's (S,G) entries marks what gets advertised.
• Anycast RP is MSDP's most common job: identical RP address on multiple routers, IGP picks the closest, MSDP mesh keeps their source knowledge synchronized, failover at IGP speed.
• SSM makes MSDP unnecessary because receivers already know sources; interdomain ASM is the case that genuinely needs it.

Round out the cluster with troubleshooting IP multicast, or return to the complete multicast guide.