image6

Exploring Multicast with PIM Sparse-Mode is a hands-on lab designed to help learners build an intuitive, visual understanding of how multicast forwarding works in a PIM Sparse-Mode network. Through a sequence of guided predictions, configurations, and packet captures, learners observe how receiver interest (via IGMP) triggers the creation of shared (*,G) trees toward the Rendezvous Point, and how the introduction of an active source later drives the formation of source-specific (S,G) trees. By inspecting PIM Join/Prune messages, multicast routing tables, and state changes over time, the lab’s objective is to move beyond rote configuration and help learners clearly understand why PIM Sparse-Mode behaves the way it does—how control-plane signaling precedes traffic, how the RP fits into the process, and how multicast state is created, used, and eventually removed.

image6

Lab Solutions — Exploring PIM Sparse-Mode (Guided Debrief)

This document walks back through the lab in the same order as the tasks, answering every prediction question along the way.
It also explains a few Cisco IOS behaviors that can otherwise be surprising the first time you notice them.

General Solution Configs

R2 through R9

ip multicast-routing
!
interface range gigabit0/0 - 3
 ip pim sparse-mode
 exit
!
ip pim rp-address 3.3.3.3


Multicast Receivers

MCAST-RCVR-1

interface gig0/2
 ip igmp join-group 225.9.9.9
 end

MCAST-RCVR-2 & MCAST-RCVR-3

interface gig0/3
 ip igmp join-group 225.9.9.9
 end
More detailed explanations are below.

Before We Begin — Two Ground Rules (Very Important)

1️⃣ Multicast routing must be enabled first

Before PIM can function, IP multicast routing must be enabled globally.

This is required on every router that will forward multicast traffic:

It is not required on the receiver routers (Mcast-Rcvr-1/2/3).

conf t
 ip multicast-routing
end

2️⃣ Static RP really does mean static

Because this lab uses a static Rendezvous Point, every router that participates in PIM Sparse-Mode must be told who the RP is.

conf t
 ip pim rp-address 3.3.3.3
end

R3 owns that address on Loopback0, but that alone does not advertise RP information.

3️⃣ Receiver routers are acting like hosts

Even though Mcast-Rcvr-1 / 2 / 3 are IOSv routers, in this lab they behave like multicast hosts:

interface <upstream-interface>
 ip igmp join-group 225.9.9.9

Task 1 — Getting Oriented

Question:
Do you expect any multicast routing entries to exist yet? Why?

Answer:
Not for your lab group, but you may already see one multicast entry.

When ip multicast-routing is enabled, Cisco IOS automatically creates multicast state for certain well-known control groups, even before any receivers join.

This is normal.

Task 2 — Enabling PIM Sparse-Mode

Required interface configuration

After multicast routing is enabled, PIM Sparse-Mode must be enabled per interface:

conf t
 interface gi0/0
  ip pim sparse-mode
 !
 interface gi0/1
  ip pim sparse-mode
end

This is required on: - Router-to-router links - Source-facing interfaces - Receiver-facing interfaces on upstream routers

It is not required on Mcast-Rcvr-1/2/3.

Important clarification — why you already see a (*,G) entry

After enabling multicast routing, you likely observed something similar to:

(*, 224.0.1.40), RP 3.3.3.3

This entry is not caused by a receiver joining your lab group.

224.0.1.40 is a well-known multicast control group used internally by PIM and other protocols.

IOS installs this (*,G) entry automatically so the router can:

image3 This entry exists even with zero receivers and no user multicast traffic.

Question (revisited):

What event causes the first (,G) entry for *your multicast group (225.9.9.9) to appear?

Correct answer:

The first IGMP Membership Report for 225.9.9.9.

Control-plane groups (like 224.0.1.40) appear automatically,
but user multicast groups only appear when a receiver explicitly joins.

This distinction is important and intentional.

Task 3 — First Receiver Joins (Mcast-Rcvr-1)

What you saw in Wireshark

That single packet is enough to trigger multicast routing state for the group.

image1

Why (*,G) propagated to the RP

Sequence:

  1. R8 receives the IGMP Membership Report
  2. R8 creates: 
    (*,225.9.9.9)
  3. R8 sends a PIM (*,G) Join upstream
  4. The Join propagates: 
    R8 → R5 → R3 (RP)

One receiver builds the entire shared tree.

image7

Why additional receivers on the same path don’t trigger Joins

Because the tree already exists.

PIM Joins extend trees — they do not count receivers.

Task 4 — Watching a NEW PIM Join (Mcast-Rcvr-3)

When Mcast-Rcvr-3 joins:

  1. R6 receives an IGMP Membership Report
  2. R6 has no (*,G) state yet
  3. R6 creates (*,G)
  4. R6 sends a new PIM (*,G) Join upstream

Path:

R6 → R4 → R7 → R3

Wireshark observations

image2

Why the Join goes toward the RP

No source traffic exists yet.

Sparse-Mode always builds the shared tree first, rooted at the RP.

Task 5 — Final Receiver (Mcast-Rcvr-2)

Why no new Join appears:

image8

Task 6 — Introducing the Multicast Source

After adding the CLI commands to the MCAST-Source node and beginning the multicast stream, the sequence that you should have seen:

  1. R9 sends PIM Registers to R3
  2. R3 learns the source
  3. Routers build (S,225.9.9.9) state
  4. Traffic moves to the Shortest Path Tree (SPT)

image10

Where does (S,G) appear first?

Closest to the source — starting at R9.

image11

How does the RP’s role change?

It introduces the source, then data traffic typically bypasses it.

Task 7 — (*,G) vs (S,G)

Task 8 — State Aging

When traffic stops:

Final Takeaway

Some multicast state exists because the control plane needs it.
Other multicast state exists because a receiver asked for it.

Knowing the difference prevents a lot of confusion — and now you’ve seen both.

End of Lab Solutions