Hands-On Lab: Configuring PIM Sparse Mode Multicast Routing

Lab Objective

Configure PIM Sparse Mode on three routers, designate one as the Rendezvous Point, verify a receiver's IGMP join builds a shared tree back to the RP, and confirm multicast traffic from a source reaches the receiver via RP-based forwarding.

Lab Purpose

Every routing protocol covered throughout this series handles unicast traffic exclusively. Multicast requires an entirely different forwarding paradigm — rather than a single destination, traffic must reach every interested receiver, and PIM Sparse Mode achieves this efficiently by building trees only where receivers have explicitly expressed interest via IGMP, rather than flooding traffic everywhere by default.

Lab Topology

Source ---- R1 ---- R2 (RP) ---- R3 ---- Receiver

Multicast group: 239.1.1.1
R2's Loopback0: 2.2.2.2/32 (used as RP address)

Task 1: Enable PIM Sparse Mode on All Relevant Interfaces

Enable IP multicast routing globally and PIM sparse-mode on every interface along the path.

Task 2: Designate R2 as the Rendezvous Point

Configure all three routers to use R2's loopback address as the static RP for the multicast group range.

Task 3: Configure the Receiver to Join the Group

Configure R3's interface facing the receiver to statically join the multicast group, simulating an IGMP join.

Task 4: Verify the Shared Tree Forms Toward the RP

Confirm R3 shows a (*, G) entry pointing toward the RP before any source traffic has even been sent.

Task 5: Send Multicast Traffic and Verify Delivery

Generate traffic from the source toward the group and confirm it reaches the receiver.

Solution and Verification

R1(config)# ip multicast-routing
R1(config)# interface gigabitethernet0/0
R1(config-if)# ip pim sparse-mode
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip pim sparse-mode

R2(config)# ip multicast-routing
R2(config)# interface gigabitethernet0/0
R2(config-if)# ip pim sparse-mode
R2(config-if)# exit
R2(config)# interface gigabitethernet0/1
R2(config-if)# ip pim sparse-mode
R2(config-if)# exit
R2(config)# interface loopback0
R2(config-if)# ip pim sparse-mode

R3(config)# ip multicast-routing
R3(config)# interface gigabitethernet0/0
R3(config-if)# ip pim sparse-mode
R3(config-if)# exit
R3(config)# interface gigabitethernet0/1
R3(config-if)# ip pim sparse-mode

R1(config)# ip pim rp-address 2.2.2.2
R2(config)# ip pim rp-address 2.2.2.2
R3(config)# ip pim rp-address 2.2.2.2

-- All three routers must agree on the
-- same static RP address -- a mismatch
-- here would mean different routers build
-- trees toward different, inconsistent
-- rendezvous points

R3(config)# interface gigabitethernet0/1
R3(config-if)# ip igmp join-group 239.1.1.1

-- Statically simulating a receiver's IGMP
-- join for lab purposes, in place of an
-- actual multicast client sending a real
-- IGMP membership report

R3# show ip mroute 239.1.1.1

(*, 239.1.1.1), uptime 00:01:15
  Incoming interface: GigabitEthernet0/0,
    RPF nbr 10.2.2.2
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- The (*, G) shared-tree entry exists
-- already, pointing toward the RP via the
-- incoming interface -- built purely from
-- the receiver's join, before any actual
-- source traffic has flowed

Source> [sends multicast traffic to 239.1.1.1]

R1# show ip mroute 239.1.1.1

(Source-IP, 239.1.1.1), uptime 00:00:05
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- A source-specific (S, G) entry now
-- exists on R1, confirming traffic is
-- actively being forwarded from the source
-- toward the RP and onward to the receiver

Receiver> [receives multicast stream]

-- Confirmed: traffic from Source
-- successfully reaches Receiver, traveling
-- Source -> R1 -> R2 (RP) -> R3 -> Receiver

Key Takeaway

The (*, G) entry represents the shared tree rooted at the RP, built the moment a receiver joins regardless of whether a source is even active yet, while the (S, G) entry represents source-specific traffic actually flowing — seeing a (*, G) entry with no corresponding (S, G) confirms a receiver has expressed interest but no traffic has arrived, a useful distinction when troubleshooting whether a multicast problem lies with receiver signaling or with the source's actual traffic delivery.