LogoفارسیFA

Hands-On Lab: Configuring PIM Sparse Mode Shortest-Path Tree Switchover

This hands-on lab observes a receiver's last-hop router automatically switch from the shared RP-rooted tree to a direct shortest-path tree toward the source once traffic volume crosses the default threshold, verifying both tree types appear in the multicast routing table at different stages.

Shortest-Path Tree SwitchoverSPT ThresholdLast-Hop Router Behavior

~4 min read · Updated Sep 26, 2026

Lab Objective

Observe the default SPT switchover behavior on R3 (the last-hop router from the previous lab), confirming it initially forwards traffic via the shared tree through the RP, then automatically switches to a direct shortest-path tree toward the source once the default SPT threshold is exceeded.

Lab Purpose

The previous lab established basic shared-tree forwarding through the RP. In real deployments, routing all traffic through the RP indefinitely is often suboptimal if the RP is not on the most direct path between source and receiver — PIM Sparse Mode's default behavior automatically optimizes this by switching the last-hop router to a direct path once traffic volume justifies the switch.

Lab Topology

Same topology as the previous lab:
Source ---- R1 ---- R2 (RP) ---- R3 ---- Receiver

Default SPT threshold is 0 kbps on
Cisco IOS, meaning the switchover happens
almost immediately upon the first packet
in many implementations -- this lab
demonstrates the mechanism explicitly

Task 1: Confirm the Initial Shared-Tree Forwarding State

Immediately after multicast traffic starts, examine R3's mroute table for evidence of shared-tree forwarding.

Task 2: Verify the SPT Switchover Occurs

After traffic has been flowing briefly, re-examine R3's mroute table for a new source-specific entry indicating a direct path has been built.

Task 3: Compare the RPF Interface Before and After Switchover

Confirm the RPF (Reverse Path Forwarding) interface for the source-specific entry differs from the shared-tree entry's incoming interface, if the direct path differs from the RP path.

Task 4: Verify the Shared Tree Entry Persists Alongside the New SPT Entry

Confirm the original (*, G) entry remains present even after the switchover, still used for signaling purposes.

Task 5: Understand the Flag Indicating SPT Status

Examine the flags on the mroute entries that specifically indicate SPT-related state.

Solution and Verification

Source> [begins sending multicast traffic
         to 239.1.1.1]

-- Immediately after traffic starts:

R3# show ip mroute 239.1.1.1

(*, 239.1.1.1), uptime 00:05:20, RP is 2.2.2.2
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward

(Source-IP, 239.1.1.1), uptime 00:00:02
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- Both entries already present -- since
-- the source and RP happen to be reached
-- via the same interface in this topology,
-- the switchover is not visually obvious
-- from the interface alone yet

R3# show ip mroute 239.1.1.1 | include Flags

(*, 239.1.1.1), ..., flags: SJC
(Source-IP, 239.1.1.1), ..., flags: SJT
-- The "T" flag on the (S, G) entry
-- specifically indicates this entry is
-- using the Shortest-Path Tree -- its
-- absence on the (*, G) entry confirms
-- that one remains the shared-tree entry

R1# show ip mroute 239.1.1.1

(Source-IP, 239.1.1.1), uptime 00:00:03, flags: FT
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- R1 also shows the "T" flag, confirming
-- SPT forwarding is active along the path
-- closest to the source as well

R3# show ip mroute 239.1.1.1

(*, 239.1.1.1), uptime 00:10:45, RP is 2.2.2.2
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward

(Source-IP, 239.1.1.1), uptime 00:05:27, flags: JT
  Incoming interface: GigabitEthernet0/0
  Outgoing interface list:
    GigabitEthernet0/1, Forward
-- The (*, G) shared-tree entry is STILL
-- present well after the switchover --
-- it remains for signaling purposes (a new
-- receiver joining would still need it),
-- while the (S, G) entry now actively
-- carries the real traffic via the SPT

Key Takeaway

The "T" flag on an (S, G) mroute entry is the definitive indicator that traffic for that source is now forwarded via the Shortest-Path Tree rather than the RP-rooted shared tree — this switchover happens automatically and by default on Cisco IOS, and the persistence of the (*, G) entry afterward is not a leftover artifact but an intentional part of the design, since it continues serving any future receiver that joins the group through the shared tree before potentially triggering its own SPT switchover.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue
Previous ArticleNext Article