Skip to content
Log in Sign up My account

3.3.d Multicast

Blueprint 3.3.d: Describe multicast protocols, such as RPF check, PIM SM, IGMP v2/v3, SSM, bidir, and MSDP

  • Multicast addressing ranges and IPv4 to MAC mapping
  • IGMPv2 and IGMPv3 between hosts and routers, IGMP snooping
  • Reverse path forwarding (RPF) check
  • PIM sparse mode: RP, shared tree, source registration, SPT switchover
  • Source-Specific Multicast (SSM)
  • Bidirectional PIM
  • MSDP and Anycast RP

The verb is describe. Expect concept questions, drag-and-drop matching of terms, and exhibits of show ip mroute or a topology where you predict what a router does with a packet. You will not be asked to build a full multicast network in a simulation, but configuring a small PIM-SM domain in the lab is the fastest way to understand the output.

Why multicast

Unicast sends one copy per receiver, so 200 receivers of a 4 Mbps video stream cost the source 800 Mbps. Broadcast reaches everyone on the subnet and stops at the router. Multicast sends one copy per link, and routers replicate only where the tree branches toward interested receivers. Typical uses: IPTV and video distribution, financial market data, software and image distribution, and many control protocols (OSPF, EIGRP, HSRP, VRRP, PIM itself).

Addressing

IPv4 multicast is 224.0.0.0/4 (224.0.0.0 to 239.255.255.255, the old class D).

Range Name Notes
224.0.0.0/24 Local network control Link-local, sent with TTL 1, never forwarded by routers
224.0.1.0/24 Internetwork control Routable control traffic, for example 224.0.1.39 and 224.0.1.40 (Cisco Auto-RP) and 224.0.1.1 (NTP)
232.0.0.0/8 Source-Specific Multicast Default SSM range, no RP
233.0.0.0/8 GLOP Statically assigned from a 16-bit AS number in the middle two octets
239.0.0.0/8 Administratively scoped Private use inside an organization, like RFC 1918 for multicast

Link-local addresses worth memorizing:

Address Used by
224.0.0.1 All hosts (IGMP general queries)
224.0.0.2 All routers (IGMPv2 Leave, HSRPv1)
224.0.0.5 / 224.0.0.6 OSPF all routers / DR and BDR
224.0.0.9 RIPv2
224.0.0.10 EIGRP
224.0.0.13 All PIM routers (PIMv2 hellos, joins, prunes)
224.0.0.18 VRRP
224.0.0.22 IGMPv3 membership reports
224.0.0.102 HSRPv2, GLBP

Multicast IP to MAC mapping

An IPv4 multicast frame uses a destination MAC that starts with the 25-bit prefix 0100.5e followed by a 0 bit, then the low-order 23 bits of the group address.

A group address has 28 significant bits after the 1110 prefix. Only 23 are copied, so 5 bits are lost and 32 group addresses share each MAC (2 to the power 5). Switches without IGMP snooping and host NICs cannot tell them apart; the IP stack filters out the unwanted ones.

Worked example for 239.1.1.1:

  1. Drop the first octet entirely, and the high bit of the second octet. 239.1.1.1: second octet 1 = 0000 0001, high bit already 0, so it stays 01.
  2. Third and fourth octets copy as is: 01, 01.
  3. MAC = 0100.5e01.0101.

Now 239.129.1.1: second octet 129 = 1000 0001. Drop the high bit and it becomes 0000 0001 = 01. MAC = 0100.5e01.0101, the same as 239.1.1.1. So do 224.1.1.1, 225.1.1.1, 238.129.1.1 and the rest of the 32 groups that differ only in the lost bits.

IPv6 multicast uses 3333 followed by the low 32 bits of the IPv6 group, so FF02::1 maps to 3333.0000.0001.

Exam trap

To check if two groups collide on the same MAC, ignore the first octet, ignore the top bit of the second octet, and compare the rest. 224.10.10.10 and 239.138.10.10 collide (10 and 138 differ only in the top bit). 239.10.10.10 and 239.11.10.10 do not.

IGMP: hosts to routers

IGMP runs only on the last-hop segment between receivers and their router. Hosts use it to say "I want group G"; the router uses it to learn which groups have members on each interface. PIM is a router-to-router protocol and never talks to hosts.

IGMPv1 IGMPv2 (IOS default) IGMPv3
Join Unsolicited report Report sent to the group address Report sent to 224.0.0.22, can list sources
Leave None, membership times out Leave Group to 224.0.0.2 Report changing to EXCLUDE or removing sources
Group-specific query No Yes Yes, plus group-and-source-specific
Querier election Relies on PIM DR Lowest IP address wins Lowest IP address wins
Source filtering No No INCLUDE and EXCLUDE lists
Needed for SSM No No (only through SSM mapping) Yes

IGMP defaults on IOS: general query every 60 seconds to 224.0.0.1, max response time 10 seconds. When an IGMPv2 host leaves, the querier sends a group-specific query and waits the last member query interval before pruning, so other hosts on the LAN that still want the group can answer.

sequenceDiagram
  participant H1 as Host1
  participant H2 as Host2
  participant R as Querier router
  R->>H1: General query to 224.0.0.1
  H1->>R: v2 report for 239.1.1.1
  H2->>R: v2 report for 239.1.1.1
  H1->>R: Leave to 224.0.0.2
  R->>H2: Group-specific query for 239.1.1.1
  H2->>R: v2 report, still interested
  Note over R: keep forwarding 239.1.1.1

IGMP snooping lets a Layer 2 switch listen to IGMP reports and leaves and forward a group only to ports that asked for it, instead of flooding it like a broadcast. It is on by default on Catalyst switches. Without it, the 32:1 MAC overlap and unknown-multicast flooding mean every port in the VLAN receives every stream.

interface GigabitEthernet0/1
 ip pim sparse-mode            ! also enables IGMP on the interface
 ip igmp version 3             ! default is 2

Reverse path forwarding

Multicast routing turns unicast logic around. A router does not care where the packet is going; it cares where the packet came from. The RPF check accepts a multicast packet only if it arrived on the interface the router would itself use to send unicast traffic back to the source (or, on a shared tree, back to the RP). Packets that fail are dropped silently.

Why: in a meshed network, multicast copies can arrive over several paths and would loop forever, since there is no TTL-based loop prevention strong enough to stop replication storms. RPF guarantees each router accepts a given stream on exactly one interface.

graph LR
  SRC["Source 10.1.1.10"] --- R1
  R1 -- "best unicast path" --- R2
  R1 --- R3
  R2 -- "Gi0/0 RPF interface" --- R4
  R3 -- "Gi0/1 fails RPF" --- R4
  R4 --- RCV["Receivers"]

Key points:

  • The RPF interface comes from the unicast routing table (or a multicast-specific table: static ip mroute entries or MP-BGP multicast routes take priority when present).
  • show ip rpf 10.1.1.10 shows the RPF interface and neighbor for a source.
  • If the IGP prefers a path where PIM is not enabled, RPF fails and multicast breaks even though unicast works. The fix is to enable PIM on that path or add a static mroute: ip mroute 10.1.1.0 255.255.255.0 10.1.24.2.
  • On a shared tree, the check is against the RP address. On a source tree, against the source address.

Exam trap

"Unicast ping to the source works but multicast does not arrive" is the classic RPF symptom. The unicast route points out an interface with no PIM neighbor, so the router sends its join out a dead end and drops packets arriving on the PIM-enabled interface.

PIM sparse mode

Protocol Independent Multicast is "protocol independent" because it uses whatever unicast routing table exists for RPF; it has no routing protocol of its own. PIMv2 messages use IP protocol 103 and link-local group 224.0.0.13. Neighbors form with hellos every 30 seconds. On a LAN, the designated router (DR) is the highest DR priority (default 1), then highest IP. The DR on a source's segment registers the source; the DR on a receiver's segment sends joins.

Dense mode (PIM-DM) floods traffic everywhere and prunes back where nobody listens. It is a push model, wasteful at scale and rarely used. Sparse mode (PIM-SM) is a pull model: nothing is sent down a link until a downstream router explicitly joins.

Rendezvous point

Receivers do not know where sources are, and sources do not know where receivers are. They meet at the rendezvous point (RP). Every router in the domain must agree on the RP for each group. Ways to tell them:

Method How Notes
Static ip pim rp-address 10.255.255.2 on every router Simple, no failover unless Anycast RP
Auto-RP Cisco. Candidate RPs announce on 224.0.1.39, mapping agent announces on 224.0.1.40 Needs sparse-dense mode or ip pim autorp listener because the groups themselves are dense-flooded
BSR Standard (PIMv2). Candidate RPs send to the bootstrap router, which floods the RP set hop by hop to 224.0.0.13 Works in pure sparse mode
Anycast RP Several RPs share one address, sync sources with MSDP (or PIM Anycast RP, RFC 4610) Redundancy and load sharing

Building the trees

sequenceDiagram
  participant RCV as Receiver
  participant LHR as Last-hop router
  participant RP as RP
  participant FHR as First-hop router
  participant SRC as Source
  RCV->>LHR: IGMP report for 239.1.1.1
  LHR->>RP: PIM (*,G) Join, hop by hop
  SRC->>FHR: First packet to 239.1.1.1
  FHR->>RP: Register (unicast, data encapsulated)
  RP->>FHR: (S,G) Join toward source
  RP->>FHR: Register-Stop once native traffic arrives
  RP->>LHR: Traffic down shared tree
  LHR->>FHR: (S,G) Join, switch to SPT
  LHR->>RP: (S,G) RP-bit Prune off shared tree
  1. Receiver joins. The last-hop DR gets an IGMP report and sends a (*,G) join toward the RP, RPF hop by hop. Each router on the way creates (*,G) state. This is the shared tree (rendezvous point tree).
  2. Source registers. The first-hop DR encapsulates the source's packets in unicast Register messages to the RP.
  3. RP joins the source. If the RP has (*,G) state for the group, it de-encapsulates and forwards down the shared tree, and sends an (S,G) join toward the source. When native traffic arrives, it sends Register-Stop to the first-hop router.
  4. SPT switchover. On IOS the last-hop router switches to the shortest-path tree as soon as the first packet arrives (SPT threshold 0). It sends an (S,G) join directly toward the source and prunes the source off the shared tree. Traffic may then bypass the RP completely. ip pim spt-threshold infinity keeps the router on the shared tree.

Notation: (*,G) means any source for group G, rooted at the RP. (S,G) means a specific source and group, rooted at the source.

Reading show ip mroute

R4# show ip mroute 239.1.1.1
(*, 239.1.1.1), 00:05:10/00:02:58, RP 10.255.255.2, flags: SJC
  Incoming interface: GigabitEthernet0/0, RPF nbr 10.2.4.2
  Outgoing interface list:
    GigabitEthernet0/2, Forward/Sparse, 00:05:10/00:02:58

(10.1.1.10, 239.1.1.1), 00:01:40/00:02:52, flags: JT
  Incoming interface: GigabitEthernet0/1, RPF nbr 10.3.4.3
  Outgoing interface list:
    GigabitEthernet0/2, Forward/Sparse, 00:01:40/00:02:58
Flag Meaning
S Sparse mode entry
C Connected: a directly attached member (IGMP)
L Local: the router itself joined the group
J Join SPT: switchover to the source tree is enabled
T SPT bit: traffic is being received on the shortest-path tree
P Pruned: no outgoing interfaces
R RP bit: (S,G) entry pointing toward the RP, used for pruning a source off the shared tree
F Register flag: this router registers the source (first hop)
B Bidir group

Here R4 has a local receiver (C), its shared tree comes in Gi0/0 toward the RP, and it has switched to the source tree (T) arriving on Gi0/1. The incoming interface of each entry is always the RPF interface toward the RP or source.

Exam trap

The incoming interface on a (*,G) entry points toward the RP; on an (S,G) entry it points toward the source. They can be different interfaces, as above. A question that asks "where does R4 expect traffic from 10.1.1.10?" wants the (S,G) incoming interface.

PIM assert

If two routers both forward the same stream onto one LAN, they see each other's packets on an outgoing interface and send Assert messages. The winner keeps forwarding: lowest administrative distance of the route to the source first, then lowest metric, then highest IP address. The loser prunes its interface.

Source-Specific Multicast (SSM)

In SSM the receiver already knows the source. It sends an IGMPv3 report for (S,G) and the last-hop router builds a source tree directly toward S. There is no RP, no shared tree, no registration and no SPT switchover. It is simpler, more secure (a receiver only gets traffic from the source it named) and is the preferred model for one-to-many services such as IPTV.

ip multicast-routing                 ! IOS XE routers use: ip multicast-routing distributed
ip pim ssm default                   ! treat 232.0.0.0/8 as SSM
interface GigabitEthernet0/2
 ip pim sparse-mode
 ip igmp version 3

For receivers that only speak IGMPv2, SSM mapping on the last-hop router translates a (*,G) report into (S,G) using a static mapping or DNS. ip pim ssm range <acl> defines a custom SSM range.

Bidirectional PIM

Applications where every participant is both a source and a receiver (many-to-many: trading floors, collaboration, some discovery protocols) would create one (S,G) entry per source per router in PIM-SM. Bidir-PIM keeps only (*,G) state. Traffic flows up the shared tree toward the RP and down to receivers, from any branch. There is no registration and no SPT switchover.

Because traffic flows in both directions on the tree, the normal RPF check cannot work. Instead, on every link a designated forwarder (DF) is elected per RP: the router with the best unicast route to the RP. Only the DF forwards traffic up toward the RP from that link and down onto that link. The RP does not even need to be a real router: it can be an address on a subnet (a "phantom RP").

ip pim bidir-enable
ip pim rp-address 10.255.255.2 bidir
PIM-SM SSM Bidir-PIM
RP needed Yes No Yes (can be phantom)
State (*,G) and (S,G) (S,G) only (*,G) only
Tree Shared, then source Source only Shared only, bidirectional
Register messages Yes No No
Host IGMP v2 or v3 v3 (or SSM mapping) v2 or v3
Best for General purpose One-to-many, known source Many-to-many

MSDP

Each PIM-SM domain has its own RP. If a source is in domain A and a receiver in domain B, RP B never hears about the source because the Register went to RP A. Multicast Source Discovery Protocol (MSDP, RFC 3618) connects RPs. RPs peer over TCP port 639 and send Source-Active (SA) messages naming each active (S,G) and the originating RP. An RP with interested receivers for that group joins toward the source across the domain boundary, and the last-hop routers can then switch to the SPT as usual.

graph LR
  subgraph A ["Domain A, AS 65001"]
    S["Source"] --> FA["FHR"] -->|"Register"| RPA["RP A"]
  end
  subgraph B ["Domain B, AS 65002"]
    RPB["RP B"] --> LB["LHR"] --> R["Receiver"]
  end
  RPA ==>|"MSDP SA over TCP 639"| RPB
  RPB -.->|"(S,G) join across domains"| FA

SA messages are checked with a peer-RPF rule (accept an SA only from the peer on the best path toward the originating RP) to prevent SA loops in a mesh of MSDP peers. Mesh groups relax that for full-mesh peerings.

Anycast RP uses MSDP inside one domain: two or more RPs share the same loopback address (for example 10.255.255.100/32), advertised into the IGP. Routers join the nearest one by normal routing. The RPs peer with MSDP using their unique loopbacks, so a source registered at one RP is known at the others. If one RP fails, the IGP converges to the other.

interface Loopback100
 ip address 10.255.255.100 255.255.255.255     ! shared anycast RP address, on both RPs
ip pim rp-address 10.255.255.100
ip msdp peer 10.255.255.3 connect-source Loopback0
ip msdp originator-id Loopback0

Exam trap

MSDP carries source information between RPs. It does not carry multicast data and it does not replace PIM. Data still flows on PIM trees. Also, MSDP is only for PIM-SM: SSM has no RP and does not need it.

Lab: PIM-SM with a static RP

Topology: four routers in a square, all running OSPF. R2 is the RP. A source behind R1, receivers behind R4.

graph LR
  SRC["Source<br/>10.1.1.10"] -- "Gi0/3 10.1.1.0/24" --- R1
  R1 -- "10.1.2.0/30" --- R2["R2 RP<br/>Lo0 10.255.255.2"]
  R1 -- "10.1.3.0/30" --- R3
  R2 -- "10.2.4.0/30" --- R4
  R3 -- "10.3.4.0/30" --- R4
  R4 -- "Gi0/2 10.4.4.0/24" --- RCV["Receiver"]
  1. Build the addressing and OSPF area 0 on every interface and loopback.

  2. On every router enable multicast routing and PIM on every interface, including loopbacks, and point to the RP.

    ip multicast-routing                   ! on Catalyst 8000v: ip multicast-routing distributed
ip pim rp-address 10.255.255.2
interface range GigabitEthernet0/0 - 3
 ip pim sparse-mode
interface Loopback0
 ip pim sparse-mode

  3. Verify PIM neighbors: show ip pim neighbor on R4 should list R2 and R3. show ip pim rp mapping should show 10.255.255.2 as static RP for 224.0.0.0/4.

  4. Simulate a receiver. On the receiver node (an IOSv with no ip routing works) or on R4's Gi0/2 itself: ip igmp join-group 239.1.1.1. On R4, show ip igmp groups lists 239.1.1.1 on Gi0/2.
  5. Check the shared tree on R4: show ip mroute 239.1.1.1 shows a (*,G) entry with incoming interface toward R2.
  6. Send traffic from the source: ping 239.1.1.1 repeat 100 (or from R1 with source GigabitEthernet0/3). Replies come back from the receiver address.
  7. Check R4 again. You should now see an (S,G) entry with the T flag, and the incoming interface is R4's RPF interface toward 10.1.1.10. Compare it with show ip rpf 10.1.1.10.
  8. On R1, show ip mroute 239.1.1.1 shows the (S,G) with the F (register) flag during registration. On R2, show ip pim rp and show ip mroute show the RP's view.
  9. Break it. Remove ip pim sparse-mode from the R3 to R4 link but leave OSPF there, and make that link the preferred unicast path to the source (lower its OSPF cost). Multicast to the receiver breaks once R4 tries to use the source tree. show ip rpf 10.1.1.10 on R4 points out an interface with no PIM neighbor. Fix it with PIM, or with a static ip mroute pointing to R2.
  10. Extend it. Add ip pim spt-threshold infinity on R4 and clear the mroute table. The (S,G) entry keeps traffic on the shared tree through R2.

Quick check

What MAC address does group 238.200.5.9 map to?

Second octet 200 = 1100 1000. Drop the high bit to get 0100 1000 = 0x48. Third and fourth octets are 0x05 and 0x09. MAC = 0100.5e48.0509.

Which IGMP version and address range does SSM require by default, and why is there no RP?

IGMPv3 and 232.0.0.0/8. The receiver names the source in its IGMPv3 report, so the last-hop router can join straight toward the source. Nobody needs a meeting point to discover sources.

In Bidir-PIM, what replaces the RPF check for traffic flowing up toward the RP?

The designated forwarder, elected per link per RP as the router with the best unicast route to the RP. Only the DF forwards traffic between that link and the RP direction, which prevents loops.

References