Glossary

PIM-ASM

Protocol Independent Multicast – Any-Source Multicast

What is PIM-ASM

PIM (Protocol Independent Multicast) is a routing solution for IP multicast that, true to its name, doesn't care which unicast routing protocol built the routing table it relies on — static routes, RIP, OSPF, IS-IS, BGP, or any combination all work equally well. Multicast routing under PIM is completely decoupled from whichever unicast protocol produced that table; PIM simply uses the unicast routes already available to perform RPF (Reverse Path Forwarding) checks on multicast packets, then builds multicast forwarding entries once those checks pass.

PIM comes in two intra-domain modes — dense mode (PIM-DM) and sparse mode (PIM-SM) — and PIM-ASM (Any-Source Multicast) is the sparse-mode model built around a central coordination point. Rather than flooding multicast traffic everywhere and pruning back unwanted branches (as dense mode does), PIM-ASM maintains a single, network-wide known coordination point — the Rendezvous Point (RP) — that both multicast sources and receivers register with, so traffic only flows where it's actually been requested.

How PIM-ASM Works

Every PIM-ASM network relies on the RP as its central hub for matching multicast supply with multicast demand. Every PIM router in the network knows the RP's address, and everything else in PIM-ASM builds from that shared reference point.

When a host joins a multicast group G (via IGMP), the last-hop router — the local Designated Router (DR) for that segment — sends a Join message toward the RP. As that Join travels hop by hop, each router along the path creates a (*, G) entry, and the resulting set of paths forms a Rendezvous Point Tree (RPT) rooted at the RP — the shared distribution tree every receiver for that group ultimately hangs off of.

When a multicast source starts sending, the DR on the source's segment (the source-side DR) encapsulates the traffic in Register messages and unicasts them directly to the RP — a process called multicast source registration. The RP decapsulates these, creates a (S, G) entry recording that specific source-to-group pairing, and forwards the now-native multicast traffic down the existing RPT to reach every registered receiver.

A handful of supporting mechanisms make this actually work reliably:

  • RPF check: for any multicast packet, a router looks up the unicast route to either the source (SPT) or the RP (RPT) and treats that route's egress interface as the required ingress interface for multicast traffic. A packet arriving anywhere else is dropped — this both enforces correct forwarding and inherently prevents multicast loops.

  • Neighbor discovery: PIM-enabled interfaces periodically send Hello messages (destination 224.0.0.13, TTL 1) to discover PIM neighbors, negotiate protocol parameters, and keep neighbor relationships alive.

  • DR election: on any segment with multiple PIM routers, one is elected DR — by highest configured priority, or by highest IP address as a tiebreak (or fallback, if any router on the segment doesn't support priority at all). The DR is what actually registers sources with the RP or sends Joins toward it on behalf of everyone else on that segment.

  • RP discovery: an RP address can be configured statically (the same address hand-configured on every router) or dynamically, where a set of Candidate-RPs (C-RPs) and a Candidate-BSR (C-BSR) let the network elect a Bootstrap Router (BSR) that collects and distributes RP information automatically — including electing a new RP automatically if the current one fails.

  • Assert mechanism: if more than one router on the same segment believes it should be forwarding to that segment, an Assert election (comparing unicast routing protocol priority, then cost to the source, then IP address) picks exactly one winner, so only a single copy of the traffic is ever delivered.

Why PIM-ASM is Beneficial

  • Scales efficiently to sparse receiver populations: Because traffic only flows along paths that were actually requested via Join messages, PIM-ASM avoids the flood-and-prune overhead of dense mode — a real advantage when group members are spread thin across a large network.

  • Decoupled from the underlying routing protocol: Whatever unicast routing protocol a network already runs, PIM-ASM builds correctly on top of it, without requiring a specific IGP or a parallel unicast-routing deployment.

  • Loop-prevention built into the forwarding logic: RPF checks don't just enforce correct paths — they structurally prevent multicast loops as a side effect, without needing a separate loop-detection mechanism layered on top.

  • Resilient RP placement with dynamic RP: BSR-based dynamic RP election means a single RP failure doesn't take multicast service down with it — a backup C-RP can be automatically elected to take over.

  • Automatic load distribution across equal-cost paths: PIM's ECMP rebalancing spreads multicast traffic across multiple equivalent paths, and reshuffles automatically as links fail or recover, rather than concentrating traffic onto a single path and creating avoidable congestion.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements a complete PIM-ASM stack — static and dynamic RP, source and member-side DR handling, and multicast ECMP load balancing — configurable directly through the CLI.

  • Straightforward PIM interface enablement: ip pim and multicast-enable, applied to any Ethernet, VLAN, or LAG interface, are all it takes to bring an interface into the PIM domain and enable multicast forwarding on it.

  • Both static and dynamic RP configuration: ip pim rp <A.B.C.D> <A.B.C.D/M> sets a static RP directly, while ip pim bsr candidate-bsr and ip pim bsr candidate-rp (with configurable priority, advertisement interval, and covered group range) implement full dynamic RP election — demonstrated in AsterNOS's own documented example where a primary RP's failure triggers automatic BSR-driven failover to a backup C-RP, verified with live show ip pim bsr, show ip pim rp-info, and show ip pim bsrp-info output before and after the failure.

  • Explicit source-side DR registration: unknown-multicast trap sends unregistered multicast traffic to the CPU specifically so the source-side DR can complete Register-message registration with the RP — a step AsterNOS's documentation calls out explicitly in every source-facing configuration example.

  • Static multicast routes where dynamic PIM isn't needed: ip mroute ethernet <interface_id> <A.B.C.D> <A.B.C.D> lets operators configure fixed (S, G) forwarding entries directly, for topologies where dynamic RP/RPT construction isn't necessary.

  • Multicast ECMP rebalancing for equal-cost topologies: ip pim ecmp rebalance, combined with AsterNOS's documented best practice of placing the RP address on a Loopback interface (avoiding RP flaps caused by a single physical interface going down), automatically redistributes multicast traffic across healthy equal-cost paths as links fail or recover — confirmed in a documented example splitting four multicast groups evenly across two parallel paths.

  • Full operational visibility: show ip pim interface, show ip pim neighbors, show ip pim rp-info, show ip mroute, and show ip pim rpf give operators complete insight into PIM state, RP status, and multicast routing entries — everything needed to confirm a PIM-ASM deployment is actually forwarding traffic as designed, directly from the CLI.