{ "id": "9a11045f-f9eb-4d25-bc82-1625b4399fdd", "name": "Exploring Multicast with PIM Sparse-Mode", "slug": "exploring-multicast-with-pim-sparse-mode", "status": "published", "lab_type": "pta", "is_sample": false, "duration_in_seconds": 1800, "metadata": { "courses": [ "e2a1e73c-a8e0-4726-8b4f-eb120ea22acf" ], "pta_sdn": "1981", "collections": [], "pta_manual_id": "8e71-bae8-164f-5a5b", "pta_namespace": "my.ine", "learning_paths": [], "has_published_parent": true }, "session": null, "company": "a491bc32-c056-4946-9169-cc053387bada", "created": "2026-03-04T17:09:36.963324Z", "modified": "2026-03-31T18:25:48.832988Z", "is_beta": false, "lab_objectives": [], "main_learning_area": "e73fd5a8-2ead-4159-9a25-38b50ad4ab20", "learning_areas": [ { "id": "e73fd5a8-2ead-4159-9a25-38b50ad4ab20", "name": "Networking", "slug": "networking" } ], "categories": [], "tags": [], "difficulty": "professional", "is_web_access": false, "is_lab_experience": false, "is_featured": false, "cve": null, "severity": null, "year": null, "classification": null, "is_trackable": false, "cpe_credits": null, "is_skill_check": false, "external_url": "", "solution_video": null, "explanation_video": null, "description": "![image6](https://assets.ine.com/lab/learningpath/29fa64be78beb17b93c1f00087690beb0bf937959c76a724548b07c05d55f195.png)\n\nExploring 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\u2019s objective is to move beyond rote configuration and help learners clearly understand why PIM Sparse-Mode behaves the way it does\u2014how control-plane signaling precedes traffic, how the RP fits into the process, and how multicast state is created, used, and eventually removed.", "description_html": "

\"image6\"

\n

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\u2019s objective is to move beyond rote configuration and help learners clearly understand why PIM Sparse-Mode behaves the way it does\u2014how control-plane signaling precedes traffic, how the RP fits into the process, and how multicast state is created, used, and eventually removed.

", "tasks": "![image6](https://assets.ine.com/lab/learningpath/29fa64be78beb17b93c1f00087690beb0bf937959c76a724548b07c05d55f195.png)\n\n# Lab Tasks \u2014 Exploring PIM Sparse-Mode\n\n## Scope and intent\nIn this lab you\u2019ll bring **PIM Sparse-Mode** to life and *watch* it form trees in response to receivers and sources.\n\nUnicast reachability (EIGRP) and IP addressing are already working. Your job is multicast only.\n\n**Goal:** send a multicast ping from **Host9** to **225.9.9.9** and confirm the three receivers (Mcast-Rcvr-1/2/3) successfully receive the flow, while you understand *why* the network builds **(*,G)** first and **(S,G)** later.\n\n---\n\n## Topology quick map (only what you\u2019ll touch)\n- **RP:** R3 (Loopback0 = 3.3.3.3)\n- **Source LAN:** Host9 \u2194 R9 Gi0/1\n- **Receiver LANs:**\n - Mcast-Rcvr-1 \u2194 R8 Gi0/2\n - Mcast-Rcvr-2 \u2194 R5 Gi0/3\n - Mcast-Rcvr-3 \u2194 R6 Gi0/3\n- **Core links (for PIM adjacency and forwarding):**\n - R9\u2013R7, R7\u2013R3, R7\u2013R4, R7\u2013R2, R3\u2013R2, R3\u2013R5, R5\u2013R4, R4\u2013R6, R5\u2013R8\n\n> The \u201cMcast-Rcvr\u201d nodes are IOSv routers in GNS3, but in this lab they behave like **hosts** (IGMP only).\n\n---\n\n## Task 1 \u2014 Get oriented (no changes yet)\n1. Confirm unicast reachability between key nodes:\n - From R9, ping R3\u2019s loopback (3.3.3.3).\n - From R8/R5/R6, ping 3.3.3.3.\n2. On any router, run:\n - `show ip mroute`\n\n**Before moving on \u2014 answer/predict:**\n- Did you expect to see any multicast routing state right now? Why?\n\n---\n\n## Task 2 \u2014 Turn on multicast routing + PIM Sparse-Mode\nNow you\u2019ll \u201cswitch on\u201d the multicast control-plane.\n\n1. On every router that will participate in multicast forwarding (R2\u2013R9), enable multicast routing globally.\n2. On the routed interfaces that carry multicast, enable **PIM Sparse-Mode**.\n3. Configure **R3 as the static RP** for the domain.\n\n**Before you verify \u2014 answer/predict:**\n- With PIM enabled but *no receivers* and *no source traffic*, do you expect any `show ip mroute` entries? Why?\n- What do you expect to see change first: the multicast routing table, or PIM neighbor relationships?\n\nThen verify:\n- PIM neighbors exist where expected (`show ip pim neighbor`).\n- The RP mapping is known (`show ip pim rp mapping`).\n- R3 is reachable via unicast (`ping 3.3.3.3`).\n\n---\n\n## Task 3 \u2014 First receiver joins + IGMP packet capture (Mcast-Rcvr-1 only)\nIn this task you will capture an IGMP message on the receiver LAN.\n\n### Step 1 \u2014 Start capture (GNS3 \u2192 Wireshark)\n1. In GNS3, **right\u2011click the link between Mcast\u2011Rcvr\u20111 and R8**.\n2. Choose **Start Capture**. Wireshark should open.\n\n### Step 2 \u2014 Join the group\n3. On **Mcast\u2011Rcvr\u20111**, on the upstream interface (Gi0/2), join group 225.9.9.9:\n ```text\n interface gi0/2\n ip igmp join-group 225.9.9.9\n ```\n\n### Step 3 \u2014 Inspect the IGMP packet in Wireshark\nFind the IGMP packet that was captured and answer:\n\n1. **Which IGMP version** is it?\n2. Is it a **Membership Report**, a **Query**, or a **Leave**?\n3. What is the **Group Address** field set to?\n4. What is the **destination IP** of the IGMP packet? (Unicast? Multicast? Which one?)\n\n> Take a screenshot or jot down the answers \u2014 you\u2019ll use them later.\n\n### Step 4 \u2014 Stop capture\n4. Quit Wireshark.\n5. In GNS3, right\u2011click the same link and select **Stop Capture**.\n\n### Step 5 \u2014 Confirm local multicast state\n6. On **R8**, run:\n - `show ip igmp groups`\n - `show ip mroute 225.9.9.9`\n\n**Before moving on \u2014 answer/predict:**\n- Do you expect to see **(*,225.9.9.9)** state now?\n- Do you expect to see **(S,225.9.9.9)** state now? Why/why not?\n\n---\n\n## Task 4 \u2014 Watch a PIM Join reach the RP (capture on R6\u2013R4)\nNow you\u2019ll capture a PIM Join/Prune message on the core link into the RP.\n\n### Step 1 \u2014 Start capture (R6\u2013R4 link)\n1. In GNS3, right\u2011click the **link between R6 and R4** and choose **Start Capture**.\n\n### Step 2 \u2014 Have Mcast\u2011Rcvr\u20113 join\n2. On **Mcast\u2011Rcvr\u20113**, on the upstream interface (Gi0/3), join group 225.9.9.9:\n ```text\n interface gi0/3\n ip igmp join-group 225.9.9.9\n ```\n\n### Step 3 \u2014 Inspect the PIM Join in Wireshark\nIn Wireshark, find the packet sent from **R6 \u2192 R4** and confirm it is a **PIM Join/Prune**.\n\nAnswer:\n\n1. Is it a **(*,G)** join or an **(S,G)** join?\n2. What is the **Group Address**?\n3. Identify **at least three fields** from the Join/Prune message. (Examples: Upstream Neighbor Address, Holdtime, Group Count, Joined Source address/flags.)\n\n**Before moving on \u2014 answer/predict:**\n- Why is this join being sent **toward R3 (the RP)** instead of toward the source?\n\n### Step 4 \u2014 Stop capture\n4. Quit Wireshark.\n5. Right\u2011click the R6\u2013R4 link again and select **Stop Capture**.\n\n---\n\n## Task 5 \u2014 Bring in the final receiver (Mcast\u2011Rcvr\u20112)\nNow repeat the join action (no capture needed this time).\n\n1. On **Mcast\u2011Rcvr\u20112**, on the upstream interface (Gi0/3), join group 225.9.9.9:\n ```text\n interface gi0/3\n ip igmp join-group 225.9.9.9\n ```\n\nVerify on upstream routers (R5, and R3):\n- `show ip mroute 225.9.9.9`\n\n**Before moving on \u2014 answer/predict:**\n- You now have receivers, but still no traffic. Why should **(*,G)** exist anyway?\n\n---\n\n## Task 6 \u2014 Introduce the multicast source\nTime to actually create multicast traffic.\n\n1. From the command line of the Mcast-Src node ensure it has an existing IPv4 address on its eth0 interface using the command, **ifconfig** and that it has a default route to 155.1.36.6 using the command **route**\n\n ![image9](https://assets.ine.com/lab/learningpath/f7f5ade50793ce2cac78566b480f34e741be4c8c52c0679a0e745f530e0f6265.png)\n\n2. If you don't see either the IPv4 address or the default route add the following commands to that mcast-source node:\n\n ```\n ip link set eth0 up\n ip addr add 155.1.36.66/24 dev eth0\n ip route add default via 155.1.36.6 dev eth0\n ip route add 224.0.0.0/4 dev eth0\n ip link set eth0 multicast on\n ```\n\n\n3. From the **MCAST-Src**, send multicast traffic by using the command below in the command line of that node:\n\n ```\n while true; do\n echo \"udp test\" | socat - UDP4-DATAGRAM:225.9.9.9:9999,ip-multicast-ttl=16\n sleep 0.25\n done\n ```\n\n\n4. The commands you just implemented will send a steady stream of multicast packets that will not stop until you issue the \"Ctrl-C\" command on that node.\n\n**Before you look \u2014 answer/predict:**\n- Where do you expect to see **(S,225.9.9.9)** state appear first?\n- Do you think the RP will still be involved after traffic starts?\n\nThen verify on multiple routers:\n- `show ip mroute 225.9.9.9`\n- `show ip pim rp mapping`\n- Optionally: `debug ip pim` (use carefully)\n\n---\n\n## Task 7 \u2014 Compare (*,G) vs (S,G) like a detective\nWith traffic flowing, compare entries on:\n- R9 (near source), R3 (RP), and one router near a receiver (R8/R5/R6)\n\nAnswer:\n1. Which entries are **(*,G)** and which are **(S,G)**?\n2. What event(s) clearly triggered:\n - the creation of **(*,G)**?\n - the creation of **(S,G)**?\n3. Which entry appears to be responsible for forwarding the actual multicast packets?\n\n---\n\n## Task 8 \u2014 Wrap-up: stop traffic and watch state decay\n1. Stop the multicast traffic from the MCAST-Host node (Ctrl-C).\n2. Observe how the mroute state changes over time in routers directly connected to the Mcast-Receiver nodes with `show ip mroute 225.9.9.9`.\n\nAnswer:\n- Which state disappears first: (*,G) or (S,G)?\n- Why does that make sense?\n\n---\n\n**End of Lab Tasks**", "tasks_html": "

\"image6\"

\n

Lab Tasks \u2014 Exploring PIM Sparse-Mode

\n

Scope and intent

\n

In this lab you\u2019ll bring PIM Sparse-Mode to life and watch it form trees in response to receivers and sources.

\n

Unicast reachability (EIGRP) and IP addressing are already working. Your job is multicast only.

\n

Goal: send a multicast ping from Host9 to 225.9.9.9 and confirm the three receivers (Mcast-Rcvr-1/2/3) successfully receive the flow, while you understand why the network builds (*,G) first and (S,G) later.

\n
\n

Topology quick map (only what you\u2019ll touch)

\n\n
\n

The \u201cMcast-Rcvr\u201d nodes are IOSv routers in GNS3, but in this lab they behave like hosts (IGMP only).

\n
\n
\n

Task 1 \u2014 Get oriented (no changes yet)

\n
    \n
  1. Confirm unicast reachability between key nodes:
    2. \n
  2. From R9, ping R3\u2019s loopback (3.3.3.3).
    3. \n
  3. From R8/R5/R6, ping 3.3.3.3.
    4. \n
  4. On any router, run:
    5. \n
  5. show ip mroute
    6. \n
\n

Before moving on \u2014 answer/predict:\n- Did you expect to see any multicast routing state right now? Why?

\n
\n

Task 2 \u2014 Turn on multicast routing + PIM Sparse-Mode

\n

Now you\u2019ll \u201cswitch on\u201d the multicast control-plane.

\n
    \n
  1. On every router that will participate in multicast forwarding (R2\u2013R9), enable multicast routing globally.
    2. \n
  2. On the routed interfaces that carry multicast, enable PIM Sparse-Mode.
    3. \n
  3. Configure R3 as the static RP for the domain.
    4. \n
\n

Before you verify \u2014 answer/predict:\n- With PIM enabled but no receivers and no source traffic, do you expect any show ip mroute entries? Why?\n- What do you expect to see change first: the multicast routing table, or PIM neighbor relationships?

\n

Then verify:\n- PIM neighbors exist where expected (show ip pim neighbor).\n- The RP mapping is known (show ip pim rp mapping).\n- R3 is reachable via unicast (ping 3.3.3.3).

\n
\n

Task 3 \u2014 First receiver joins + IGMP packet capture (Mcast-Rcvr-1 only)

\n

In this task you will capture an IGMP message on the receiver LAN.

\n

Step 1 \u2014 Start capture (GNS3 \u2192 Wireshark)

\n
    \n
  1. In GNS3, right\u2011click the link between Mcast\u2011Rcvr\u20111 and R8.
    2. \n
  2. Choose Start Capture. Wireshark should open.
    3. \n
\n

Step 2 \u2014 Join the group

\n
    \n
  1. On Mcast\u2011Rcvr\u20111, on the upstream interface (Gi0/2), join group 225.9.9.9:\n 
    interface gi0/2\n ip igmp join-group 225.9.9.9
    2. \n
\n

Step 3 \u2014 Inspect the IGMP packet in Wireshark

\n

Find the IGMP packet that was captured and answer:

\n
    \n
  1. Which IGMP version is it?
    2. \n
  2. Is it a Membership Report, a Query, or a Leave?
    3. \n
  3. What is the Group Address field set to?
    4. \n
  4. What is the destination IP of the IGMP packet? (Unicast? Multicast? Which one?)
    5. \n
\n
\n

Take a screenshot or jot down the answers \u2014 you\u2019ll use them later.

\n
\n

Step 4 \u2014 Stop capture

\n
    \n
  1. Quit Wireshark.
    2. \n
  2. In GNS3, right\u2011click the same link and select Stop Capture.
    3. \n
\n

Step 5 \u2014 Confirm local multicast state

\n
    \n
  1. On R8, run:
    2. \n
  2. show ip igmp groups
    3. \n
  3. show ip mroute 225.9.9.9
    4. \n
\n

Before moving on \u2014 answer/predict:\n- Do you expect to see (*,225.9.9.9) state now?\n- Do you expect to see (S,225.9.9.9) state now? Why/why not?

\n
\n

Task 4 \u2014 Watch a PIM Join reach the RP (capture on R6\u2013R4)

\n

Now you\u2019ll capture a PIM Join/Prune message on the core link into the RP.

\n

Step 1 \u2014 Start capture (R6\u2013R4 link)

\n
    \n
  1. In GNS3, right\u2011click the link between R6 and R4 and choose Start Capture.
    2. \n
\n

Step 2 \u2014 Have Mcast\u2011Rcvr\u20113 join

\n
    \n
  1. On Mcast\u2011Rcvr\u20113, on the upstream interface (Gi0/3), join group 225.9.9.9:\n 
    interface gi0/3\n ip igmp join-group 225.9.9.9
    2. \n
\n

Step 3 \u2014 Inspect the PIM Join in Wireshark

\n

In Wireshark, find the packet sent from R6 \u2192 R4 and confirm it is a PIM Join/Prune.

\n

Answer:

\n
    \n
  1. Is it a (*,G) join or an (S,G) join?
    2. \n
  2. What is the Group Address?
    3. \n
  3. Identify at least three fields from the Join/Prune message. (Examples: Upstream Neighbor Address, Holdtime, Group Count, Joined Source address/flags.)
    4. \n
\n

Before moving on \u2014 answer/predict:\n- Why is this join being sent toward R3 (the RP) instead of toward the source?

\n

Step 4 \u2014 Stop capture

\n
    \n
  1. Quit Wireshark.
    2. \n
  2. Right\u2011click the R6\u2013R4 link again and select Stop Capture.
    3. \n
\n
\n

Task 5 \u2014 Bring in the final receiver (Mcast\u2011Rcvr\u20112)

\n

Now repeat the join action (no capture needed this time).

\n
    \n
  1. On Mcast\u2011Rcvr\u20112, on the upstream interface (Gi0/3), join group 225.9.9.9:\n 
    interface gi0/3\n ip igmp join-group 225.9.9.9
    2. \n
\n

Verify on upstream routers (R5, and R3):\n- show ip mroute 225.9.9.9

\n

Before moving on \u2014 answer/predict:\n- You now have receivers, but still no traffic. Why should (*,G) exist anyway?

\n
\n

Task 6 \u2014 Introduce the multicast source

\n

Time to actually create multicast traffic.

\n
    \n
  1. \n

    From the command line of the Mcast-Src node ensure it has an existing IPv4 address on its eth0 interface using the command, ifconfig and that it has a default route to 155.1.36.6 using the command route

    \n

    \"image9\"

    \n
    2. \n
  2. \n

    If you don't see either the IPv4 address or the default route add the following commands to that mcast-source node:

    \n
    ip link set eth0 up\nip addr add 155.1.36.66/24 dev eth0\nip route add default via 155.1.36.6 dev eth0\nip route add 224.0.0.0/4 dev eth0\nip link set eth0 multicast on
    \n\n
    3. \n
  3. \n

    From the MCAST-Src, send multicast traffic by using the command below in the command line of that node:

    \n
    while true; do\necho \"udp test\" | socat - UDP4-DATAGRAM:225.9.9.9:9999,ip-multicast-ttl=16\nsleep 0.25\ndone
    \n\n
    4. \n
  4. \n

    The commands you just implemented will send a steady stream of multicast packets that will not stop until you issue the \"Ctrl-C\" command on that node.

    \n
    5. \n
\n

Before you look \u2014 answer/predict:\n- Where do you expect to see (S,225.9.9.9) state appear first?\n- Do you think the RP will still be involved after traffic starts?

\n

Then verify on multiple routers:\n- show ip mroute 225.9.9.9\n- show ip pim rp mapping\n- Optionally: debug ip pim (use carefully)

\n
\n

Task 7 \u2014 Compare (*,G) vs (S,G) like a detective

\n

With traffic flowing, compare entries on:\n- R9 (near source), R3 (RP), and one router near a receiver (R8/R5/R6)

\n

Answer:\n1. Which entries are (*,G) and which are (S,G)?\n2. What event(s) clearly triggered:\n - the creation of (*,G)?\n - the creation of (S,G)?\n3. Which entry appears to be responsible for forwarding the actual multicast packets?

\n
\n

Task 8 \u2014 Wrap-up: stop traffic and watch state decay

\n
    \n
  1. Stop the multicast traffic from the MCAST-Host node (Ctrl-C).
    2. \n
  2. Observe how the mroute state changes over time in routers directly connected to the Mcast-Receiver nodes with show ip mroute 225.9.9.9.
    3. \n
\n

Answer:\n- Which state disappears first: (*,G) or (S,G)?\n- Why does that make sense?

\n
\n

End of Lab Tasks

", "published_date": "2026-03-31T18:25:48.826075Z", "solutions": "![image6](https://assets.ine.com/lab/learningpath/29fa64be78beb17b93c1f00087690beb0bf937959c76a724548b07c05d55f195.png)\n\n# Lab Solutions \u2014 Exploring PIM Sparse-Mode (Guided Debrief)\n\nThis document walks back through the lab in the **same order as the tasks**, answering every prediction question along the way. \nIt also explains a few *Cisco IOS behaviors* that can otherwise be surprising the first time you notice them.\n\n---\n\n## General Solution Configs\n\n```\nR2 through R9\n\nip multicast-routing\n!\ninterface range gigabit0/0 - 3\n ip pim sparse-mode\n exit\n!\nip pim rp-address 3.3.3.3\n\n```\n\n```\nMulticast Receivers\n\nMCAST-RCVR-1\n\ninterface gig0/2\n ip igmp join-group 225.9.9.9\n end\n\nMCAST-RCVR-2 & MCAST-RCVR-3\n\ninterface gig0/3\n ip igmp join-group 225.9.9.9\n end\n\n```\nMore detailed explanations are below.\n---\n\n## Before We Begin \u2014 Two Ground Rules (Very Important)\n\n### 1\ufe0f\u20e3 Multicast routing must be enabled first\nBefore PIM can function, **IP multicast routing must be enabled globally**.\n\nThis is required on **every router that will forward multicast traffic**:\n\n- R2, R3, R4, R5, R6, R7, R8, R9\n\nIt is **not required** on the receiver routers (Mcast-Rcvr-1/2/3).\n\n```text\nconf t\n ip multicast-routing\nend\n```\n\n---\n\n### 2\ufe0f\u20e3 Static RP really does mean *static*\nBecause this lab uses a **static Rendezvous Point**, *every router that participates in PIM Sparse-Mode must be told who the RP is*.\n\n```text\nconf t\n ip pim rp-address 3.3.3.3\nend\n```\n\nR3 owns that address on Loopback0, but that alone does **not** advertise RP information.\n\n---\n\n### 3\ufe0f\u20e3 Receiver routers are acting like hosts\nEven though **Mcast-Rcvr-1 / 2 / 3** are IOSv routers, in this lab they behave like multicast **hosts**:\n\n- They do **not** run PIM\n- They do **not** run multicast routing\n- They only use **IGMP**\n\n```text\ninterface \n ip igmp join-group 225.9.9.9\n```\n\n---\n\n## Task 1 \u2014 Getting Oriented\n\n**Question:** \nDo you expect any multicast routing entries to exist yet? Why?\n\n**Answer:** \nNot for your *lab group*, but you may already see **one multicast entry**.\n\nWhen `ip multicast-routing` is enabled, Cisco IOS automatically creates multicast state for certain **well-known control groups**, even before any receivers join.\n\nThis is normal.\n\n---\n\n## Task 2 \u2014 Enabling PIM Sparse-Mode\n\n### Required interface configuration\n\nAfter multicast routing is enabled, PIM Sparse-Mode must be enabled **per interface**:\n\n```text\nconf t\n interface gi0/0\n ip pim sparse-mode\n !\n interface gi0/1\n ip pim sparse-mode\nend\n```\n\nThis is required on:\n- Router-to-router links\n- Source-facing interfaces\n- Receiver-facing interfaces on upstream routers\n\nIt is **not** required on Mcast-Rcvr-1/2/3.\n\n---\n\n### Important clarification \u2014 why you already see a (*,G) entry\n\nAfter enabling multicast routing, you likely observed something similar to:\n\n```\n(*, 224.0.1.40), RP 3.3.3.3\n```\n\n**This entry is not caused by a receiver joining your lab group.**\n\n224.0.1.40 is a **well-known multicast control group** used internally by PIM and other protocols.\n\nIOS installs this (*,G) entry automatically so the router can:\n\n- Receive PIM control messages\n- Maintain RP reachability\n- Support multicast infrastructure signaling\n\n![image3](https://assets.ine.com/lab/learningpath/e5c9bb734efb0b2da1588446319b8bd06bce64d7c9da845edda5afee19afe46b.png) This entry exists **even with zero receivers** and **no user multicast traffic**.\n\n---\n\n### Question (revisited):\nWhat event causes the first (*,G) entry for *your multicast group* (225.9.9.9) to appear?\n\n### Correct answer:\nThe **first IGMP Membership Report** for **225.9.9.9**.\n\nControl-plane groups (like 224.0.1.40) appear automatically, \nbut **user multicast groups** only appear when a receiver explicitly joins.\n\nThis distinction is important and intentional.\n\n---\n\n## Task 3 \u2014 First Receiver Joins (Mcast-Rcvr-1)\n\n### What you saw in Wireshark\n\n- **IGMP version:** IGMPv2 \n- **Message type:** Membership Report \n- **Group address:** 225.9.9.9 \n- **Destination IP:** 224.0.0.22 \n\nThat single packet is enough to trigger multicast routing state for the group.\n\n![image1](https://assets.ine.com/lab/learningpath/65bae0bf4c83aadc3d1cc2d3fc226357fc5819540b8d8546ba9e53ba41e331f5.png)\n\n---\n\n### Why (*,G) propagated to the RP\n\nSequence:\n\n1. R8 receives the IGMP Membership Report\n2. R8 creates:\n ```\n (*,225.9.9.9)\n ```\n3. R8 sends a **PIM (*,G) Join** upstream\n4. The Join propagates:\n ```\n R8 \u2192 R5 \u2192 R3 (RP)\n ```\n\nOne receiver builds the **entire shared tree**.\n\n ![image7](https://assets.ine.com/lab/learningpath/5a47bd02ccda4ad33bae6ab6a3dd6453bd5f884a5b72fefb3c41136fdf71bb78.png)\n\n---\n\n### Why additional receivers on the same path don\u2019t trigger Joins\n\nBecause the tree already exists.\n\nPIM Joins extend trees \u2014 they do not count receivers.\n\n---\n\n## Task 4 \u2014 Watching a NEW PIM Join (Mcast-Rcvr-3)\n\nWhen Mcast-Rcvr-3 joins:\n\n1. R6 receives an IGMP Membership Report\n2. R6 has no (*,G) state yet\n3. R6 creates (*,G)\n4. R6 sends a **new PIM (*,G) Join** upstream\n\nPath:\n\n```text\nR6 \u2192 R4 \u2192 R7 \u2192 R3\n```\n\n### Wireshark observations\n\n- **Protocol:** PIMv2 Join/Prune\n- **Join type:** (*,G)\n- **Group:** 225.9.9.9\n- **Holdtime:** 210 seconds\n\n![image2](https://assets.ine.com/lab/learningpath/9c9c12f9c00a0acab7a666262456088ffc6e561bf54414784cb7e938db532697.png)\n\n---\n\n### Why the Join goes toward the RP\n\nNo source traffic exists yet.\n\nSparse-Mode always builds the **shared tree first**, rooted at the RP.\n\n---\n\n## Task 5 \u2014 Final Receiver (Mcast-Rcvr-2)\n\n**Why no new Join appears:**\n\n- R5 already has (*,G) state\n- The shared tree already exists on that path\n- No new branch is required\n\n![image8](https://assets.ine.com/lab/learningpath/527484eb59b388acd9617900020b3bf07c659d919a3eadc584b6a79a6b50ec54.png)\n---\n\n## Task 6 \u2014 Introducing the Multicast Source\n\nAfter adding the CLI commands to the MCAST-Source node and beginning the multicast stream, the sequence that you should have seen:\n\n1. R9 sends **PIM Registers** to R3\n2. R3 learns the source\n3. Routers build **(S,225.9.9.9)** state\n4. Traffic moves to the **Shortest Path Tree (SPT)**\n\n![image10](https://assets.ine.com/lab/learningpath/ac27dbff44d1ec38275f2b65bb5de87c05a684d7f665f039f89532854dc75f54.png)\n\n---\n\n### Where does (S,G) appear first?\nClosest to the source \u2014 starting at **R9**.\n\n![image11](https://assets.ine.com/lab/learningpath/de8ed643323120acc3823907357927cc71c12079ae11991d84d3b82490bae3d1.png)\n\n### How does the RP\u2019s role change?\nIt introduces the source, then data traffic typically bypasses it.\n\n---\n\n## Task 7 \u2014 (*,G) vs (S,G)\n\n- **(*,G):** receiver-driven, RP-rooted\n- **(S,G):** traffic-driven, source-rooted\n- **Forwarding:** typically occurs on (S,G)\n\n---\n\n## Task 8 \u2014 State Aging\n\nWhen traffic stops:\n\n- **(S,G)** ages out first\n- **(*,G)** may persist while receivers remain joined\n\n---\n\n## Final Takeaway\n\nSome multicast state exists **because the control plane needs it**. \nOther multicast state exists **because a receiver asked for it**.\n\nKnowing the difference prevents a *lot* of confusion \u2014 and now you\u2019ve seen both.\n\n---\n\n**End of Lab Solutions**", "solutions_html": "

\"image6\"

\n

Lab Solutions \u2014 Exploring PIM Sparse-Mode (Guided Debrief)

\n

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

\n
\n

General Solution Configs

\n
R2 through R9\n\nip multicast-routing\n!\ninterface range gigabit0/0 - 3\n ip pim sparse-mode\n exit\n!\nip pim rp-address 3.3.3.3\n
\n\n

Multicast Receivers\n\nMCAST-RCVR-1\n\ninterface gig0/2\n ip igmp join-group 225.9.9.9\n end\n\nMCAST-RCVR-2 & MCAST-RCVR-3\n\ninterface gig0/3\n ip igmp join-group 225.9.9.9\n end\n
\nMore detailed explanations are below.

\n
\n

Before We Begin \u2014 Two Ground Rules (Very Important)

\n

1\ufe0f\u20e3 Multicast routing must be enabled first

\n

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

\n

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

\n\n

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

\n
conf t\n ip multicast-routing\nend
\n\n
\n

2\ufe0f\u20e3 Static RP really does mean static

\n

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

\n
conf t\n ip pim rp-address 3.3.3.3\nend
\n\n

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

\n
\n

3\ufe0f\u20e3 Receiver routers are acting like hosts

\n

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

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

Task 1 \u2014 Getting Oriented

\n

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

\n

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

\n

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

\n

This is normal.

\n
\n

Task 2 \u2014 Enabling PIM Sparse-Mode

\n

Required interface configuration

\n

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

\n
conf t\n interface gi0/0\n  ip pim sparse-mode\n !\n interface gi0/1\n  ip pim sparse-mode\nend
\n\n

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

\n

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

\n
\n

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

\n

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

\n
(*, 224.0.1.40), RP 3.3.3.3
\n\n

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

\n

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

\n

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

\n\n

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

\n
\n

Question (revisited):

\n

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

\n

Correct answer:

\n

The first IGMP Membership Report for 225.9.9.9.

\n

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

\n

This distinction is important and intentional.

\n
\n

Task 3 \u2014 First Receiver Joins (Mcast-Rcvr-1)

\n

What you saw in Wireshark

\n\n

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

\n

\"image1\"

\n
\n

Why (*,G) propagated to the RP

\n

Sequence:

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

One receiver builds the entire shared tree.

\n

\"image7\"

\n
\n

Why additional receivers on the same path don\u2019t trigger Joins

\n

Because the tree already exists.

\n

PIM Joins extend trees \u2014 they do not count receivers.

\n
\n

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

\n

When Mcast-Rcvr-3 joins:

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

Path:

\n
R6 \u2192 R4 \u2192 R7 \u2192 R3
\n\n

Wireshark observations

\n\n

\"image2\"

\n
\n

Why the Join goes toward the RP

\n

No source traffic exists yet.

\n

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

\n
\n

Task 5 \u2014 Final Receiver (Mcast-Rcvr-2)

\n

Why no new Join appears:

\n\n

\"image8\"

\n

Task 6 \u2014 Introducing the Multicast Source

\n

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

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

\"image10\"

\n
\n

Where does (S,G) appear first?

\n

Closest to the source \u2014 starting at R9.

\n

\"image11\"

\n

How does the RP\u2019s role change?

\n

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

\n
\n

Task 7 \u2014 (*,G) vs (S,G)

\n\n
\n

Task 8 \u2014 State Aging

\n

When traffic stops:

\n\n
\n

Final Takeaway

\n

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

\n

Knowing the difference prevents a lot of confusion \u2014 and now you\u2019ve seen both.

\n
\n

End of Lab Solutions

", "flags": [], "min_points_to_pass": null, "access_type": "default", "taxonomy_skills": [], "user_status": "unstarted", "user_lab_status": null, "user_status_modified": null, "user_flags": [], "global_running_session": null }