PIM Sparse Mode
Sparse Mode is an alternative way of building the SPT for multicasting. It is based on a shared tree concept for the establishment of an “initial” spanning tree and on a pull model (flooding must be explicitly required) as basic principle. Only one tree per Group (for all Sources) is initially built. At the establishment of the shared tree, entries on the shared tree SPT have the form (*,G). PIM SM uses a pull model: at the startup no flooding is done until some receiver or downstream router requires it explicitly, by using a PIM or IGMP Group G join message. The request then travels upstream to activate the flooding.
Because the Source of a required group is registered via a join message, in PIM SM a central registering element is needed in order to be able to register to Sources and to gather receivers. In SM a central Rendezvous Point (RP) is explicitly needed for this purpose. The RP is just one of the multicast routers, which is used (and explicitly known) by all other downstream routers to register AND by the First Hop router, which is sensing the Source, to register the Source as well. When a Source speaks, the First hop router sends the initial packets “tunneled” in unicast to the RP. Consequently the RP starts joining upwards on routers in its RFP best path towards that source, forming a (partial) source tree [from the Source to the RP]. Further the RP floods the multicast downstream towards the receivers (which joined/registered explicitly to it for the Group). Globally a shared tree is build (from Source to RP in source tree, from RP to receivers shared tree). The creation a streaming distribution tree is therefore incremental, with no unneeded flooding.
Once the streaming flows, PIM SM offers an optimization by reverting to the source tree (with just a few extra communication overhead, still in a pull fashion). If a PIM SM router, in fact, receives the multicast and verifies that the incoming path (which is via the RP) is not the best RFP for the source, it starts joining upwards to directly towards the source. When the multicasting starts arriving from the best path (that is the Source tree is active) a prune is sent to the RP. Therefore if the RP is not on the best path (SPT), it will progressively exit from the flooding process. A the end ONLY the needed routers will have a (S,G) entries and the RP will potentially have (S,G) pruning entries if it exit from the path. All other routers (non RP and non on the SPT) have no entry and require no participation in the PIM process.
Consideration about configuring PIM SM:
- It is very important to place the RP efficiently. A good router and generally in the center between sources and receivers is the best. If the location of the Sources is limited and well defined the RP can be put close to the Sources.
- The mechanism to choose or elect a RP is very important and differs:
- an RP can be configured statically: this may be prone of manual configuration and does not offer any failover or balancing mechanisms;
- an RP may be elected using Cisco proprietary AutoRP feature (multiple RP can act as alternative candidates. Election if performed by “electors” routers which listen to RP candidate announcements, elect the best, map the Group-to-RP and inform the rest of the PIM network). While this is a good method it relies on Multicast communication (for election and Group-to-RP information) and therefore requires a special hybrid mode, the SM-DM mode. The Dense mode is used to let candidates and diverers announce information, while once the RP is elected the SM is used (Note1: if the command “no ip pim dm-fallback” is entered the router falls back to DM if no RP is available! Note2: on newer IOS the SM only can be used along with the special command “ip pim autorp listener”. The router always use SM and only the AutoRP communication is dense flooded, with no reversion in case of lack of an RP);
- an RP may similarly may elected using standard based PIMv2 Bootstrap feature (a similar mechanism to AutoRP but which does not require any dense flooding for election/information and not neededing the SM-DM feature);
- It may be “structured” using the AnycastRP feature. This is actually based on configuring MSDP peering between multiple real RPs in order to learn and share/exchange Source information. The multiple real RPs share also a routed common loopback address (the SAME) and coordinate using MSDP Sources and user registration. AnycastRP allows very large networks to balance flooding to their closest real RP for that Group and to limit leaves configuration to JUST a static RP mapping. AnycastRP uses the Sparse Mode method, with only a static RP mappings to a virtual RP;
Example PIM Sparse Mode: Static RP Configuration
hostname RT5
!
ip multicast-routing
!
interface Ethernet0/0
ip address 192.168.1.120 255.255.255.0
ip pim sparse-mode <<<<<<< Note that it cannot reverse to Dense
! mode and that AutoRP will not work in
interface Ethernet0/0.33 this case!
encapsulation dot1Q 33
ip address 150.1.1.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet0/0.104
encapsulation dot1Q 104
ip address 138.1.56.5 255.255.255.252
ip pim sparse-mode
delay 20000
!
interface Serial0/0
ip address 138.1.11.155 255.255.255.224
ip pim sparse-mode
encapsulation frame-relay
no arp frame-relay
frame-relay map ip 138.1.11.130 402
frame-relay map ip 138.1.11.156 402 broadcast
no frame-relay inverse-arp
!
router eigrp 1
passive-interface Ethernet0/0
passive-interface Ethernet0/0.33
network 138.1.11.128 0.0.0.31
network 138.1.56.4 0.0.0.3
network 150.1.1.0 0.0.0.255
network 192.168.1.0
no auto-summary
eigrp stub connected
!
ip pim rp-address 10.100.100.1 <<<<<<< Just a Static RP mapping. Note that
! also the RP ITSELF needs it.
end
if the chosen RP is not configured, it will refuse to become the RP:
RT6
Mar 31 17:48:00: %SYS-5-CONFIG_I: Configured from console by vty4 (138.1.56.5)
Mar 31 17:48:18: %PIM-6-INVALID_RP_JOIN: Received (*, 239.255.255.250) Join from 0.0.0.0 for invalid RP 10.100.100.1
Mar 31 17:48:18: %PIM-1-INVALID_RP_REG: Received Register from 138.1.11.155 for 239.255.1.1, not willing to be RP
Imposing this too:
RT6(config)ip pim rp-address 10.100.100.1
RT6sh ip pim rp
Group: 239.255.1.1, RP: 10.100.100.1, next RP-reachable in 00:00:43
Group: 224.0.1.40, RP: 10.100.100.1, next RP-reachable in 00:00:43
Group: 239.255.255.250, RP: 10.100.100.1, next RP-reachable in 00:00:43
hostname RT6
!
ip multicast-routing
!
interface Loopback100
ip address 10.100.100.1 255.255.255.0
!
interface Ethernet0/0
!
interface Ethernet0/0.2
encapsulation dot1Q 2
ip address 10.1.35.6 255.255.255.0
ip pim sparse-mode
!
interface Ethernet0/0.60
encapsulation dot1Q 60
ip address 10.1.60.6 255.255.255.0
ip pim sparse-mode
!
interface Ethernet0/0.104
encapsulation dot1Q 104
ip address 138.1.56.6 255.255.255.252
ip pim sparse-mode
delay 20000
!
interface Serial0/0
encapsulation frame-relay
!
interface Serial0/0.1 multipoint
ip address 138.1.11.156 255.255.255.224
ip pim sparse-mode
no ip split-horizon eigrp 1
no arp frame-relay
frame-relay map ip 138.1.11.130 201 broadcast
frame-relay map ip 138.1.11.155 204 broadcast
no frame-relay inverse-arp
!
interface Serial0/0.2 point-to-point
ip address 138.1.15.10 255.255.255.248
ip pim sparse-mode
frame-relay interface-dlci 203
!
router eigrp 1
passive-interface Ethernet0/0.60
network 10.1.35.0 0.0.0.255
network 10.1.60.0 0.0.0.255
network 10.100.100.1 0.0.0.0
network 138.1.11.128 0.0.0.31
network 138.1.15.8 0.0.0.7
network 138.1.56.4 0.0.0.3
no auto-summary
!
ip pim rp-address 10.100.100.1 <<<<<<<< also for the RP itself.
!
end
RT3(config-if)ip igmp join-group 239.255.1.1 <<<<<<<< extra joiner for testing
RT5ping 239.255.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.255.1.1, timeout is 2 seconds:
Reply to request 0 from 10.1.23.3, 40 ms
Reply to request 0 from 10.1.23.3, 48 ms
Reply to request 0 from 10.1.23.3, 48 ms
Reply to request 0 from 10.1.23.3, 44 ms
Mroute Tables
NOTE:
• F—Register flag. Indicates that the software is registering for a multicast source.
• T—SPT-bit set. Indicates that packets have been received on the shortest path source tree.
Further note that entries (*,G) normally refer to a RFP via the available RP. In SM anyway, in the second optimization phase, also (S,G) entries appear, optimizing the shared tree into a source tree (and not mentioning the RP anymore).
— the First Hop router —
RT5sh ip mroute <<<<<<< This router is
IP Multicast Routing Table between Source
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected, and RP……..
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report, Z – Multicast Tunnel
Y – Joined MDT-data group, y – Sending to MDT-data group
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.1.1), 00:07:04/stopped, RP 10.100.100.1, flags: SPF <<<<<<< This is just
Incoming interface: Serial0/0, RPF nbr 138.1.11.156 the Register-
Outgoing interface list: Null Stop from the
RP itself
(192.168.1.1, 239.255.1.1), 00:07:04/00:03:27, flags: FT <<<<<<< Register rcvd
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 on the SPT to
Outgoing interface list: source (Source
Serial0/0, Forward/Sparse, 00:06:14/00:03:14 tree from RP
to source)
— the RP itself —
RT6sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report, Z – Multicast Tunnel
Y – Joined MDT-data group, y – Sending to MDT-data group
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.1.1), 00:10:07/00:02:49, RP 10.100.100.1, flags: SJC <<<<<<<< Due to Join
Incoming interface: Null, RPF nbr 0.0.0.0 received on
Outgoing interface list: E0/0.2 and
Ethernet0/0.2, Forward/Sparse, 00:09:37/00:02:49 E0/0.60
Ethernet0/0.60, Forward/Sparse, 00:10:07/00:02:26
(192.168.1.1, 239.255.1.1), 00:10:07/00:03:15, flags: T <<<<<<<< This because
Incoming interface: Serial0/0.1, RPF nbr 138.1.11.155 also on the
Outgoing interface list: SPT to Source
Ethernet0/0.2, Forward/Sparse, 00:09:37/00:02:49 <——- moves towards RT8
Ethernet0/0.60, Forward/Sparse, 00:10:07/00:02:26 <——- moves towards a
local IF
— A downstream router —
RT8sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report, Z – Multicast Tunnel
Y – Joined MDT-data group, y – Sending to MDT-data group
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.1.1), 00:15:16/00:03:06, RP 10.100.100.1, flags: SJC
Incoming interface: Ethernet0, RPF nbr 10.1.35.6
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:15:16/00:03:06 <<<<< shared tree via RP 10.100.100.1
(192.168.1.1, 239.255.1.1), 00:15:16/00:03:27, flags: JT <<<<< reverted to the Source SPT
Incoming interface: Ethernet0, RPF nbr 10.1.35.6
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:15:16/00:03:06 <—- joined the source tree lately
RT8sh ip mroute count
IP Multicast Statistics
3 routes using 1478 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 16036, Packets received: 16036
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 192.168.1.1/32, Forwarding: 16036/0/1344/0, Other: 16036/0/0
RT8sh ip mroute count
IP Multicast Statistics
3 routes using 1478 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 16041, Packets received: 16041
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 192.168.1.1/32, Forwarding: 16041/0/1344/0, Other: 16041/0/0
=====> the whole segment 10.1.23.0/24 for R3, R2, R8 receives the multicasts
RT3sh ip mroute count
IP Multicast Statistics
3 routes using 942 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 0, Packets received: 16968
RP-tree: Forwarding: 0/0/0/0, Other: 7/0/7
Source: 192.168.1.1/32, Forwarding: 0/-18/0/0, Other: 16961/0/16961
RT3sh ip mroute count
IP Multicast Statistics
3 routes using 942 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 0, Packets received: 16973
RP-tree: Forwarding: 0/0/0/0, Other: 7/0/7
Source: 192.168.1.1/32, Forwarding: 0/-18/0/0, Other: 16966/0/16966
Moving the RP elsewhere, not on the SPT
In order to see the optimization shared to source tree in SM, we move the RP out of the SPT.
On each router:
conf t
no ip pim rp-address 10.100.100.1 <— from RT6
ip pim rp-address 140.1.2.1 <— to RT1
end
clear ip igmp group
clear ip mroute *
============> The new RP takes initially the task of forwarding the Source:
RT1sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report, Z – Multicast Tunnel
Y – Joined MDT-data group, y – Sending to MDT-data group
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.1.1), 00:00:36/stopped, RP 140.1.2.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:36/00:02:57 <<<<<< By default
(192.168.1.1, 239.255.1.1), 00:00:29/00:02:52, flags: T
Incoming interface: Serial1.1, RPF nbr 138.1.15.10
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:29/00:02:33 <<<<<< the Source has
as registered
by 138.1.15.10
and the RP joins
upwards to it.
—-> RP is (initially) on the path to receivers, even if not on SPT:
RT1sh ip mroute count
IP Multicast Statistics
4 routes using 2176 bytes of memory
3 groups, 0.33 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 698, Packets received: 698
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 192.168.1.1/32, Forwarding: 698/19/1344/210, Other: 698/0/0
RT1sh ip mroute count
IP Multicast Statistics
4 routes using 2326 bytes of memory
3 groups, 0.33 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 725, Packets received: 725
RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
Source: 192.168.1.1/32, Forwarding: 725/19/1344/210, Other: 725/0/0
======> After Converged to SPT: RT6 has verified it is on a better path and starts
forwarding somewhere else, cutting RT1 from the path. It prunes it.
RT1sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report, Z – Multicast Tunnel
Y – Joined MDT-data group, y – Sending to MDT-data group
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.1.1), 00:01:27/00:03:04, RP 140.1.2.1, flags: S <<<<<<< Still default, for
Incoming interface: Null, RPF nbr 0.0.0.0 all sources…. but
Outgoing interface list: for that specific
Serial1.1, Forward/Sparse, 00:00:45/00:02:46 source, see below:
Serial0, Forward/Sparse, 00:01:27/00:03:04
(192.168.1.1, 239.255.1.1), 00:01:20/00:02:41, flags: PT
Incoming interface: Serial1.1, RPF nbr 138.1.15.10 <<<<<<< But now Pruned !!!!!
Outgoing interface list: Null the RP has no more
need to be on the
source tree path
which is elsewhere.
It does not flood
this source anymore…
Imposing no reversion to source tree SPT and leave RP in the path
Switchover from SM Shared Tree to Source Tree: defaults and “infinity”
Once the shared tree is established and multicast flows from the RP in downstream direction, traffic arrives to last hop routers. By default the “ip pim spt-threshold 0” (kbps) command is set by default and imposes the last hop router, once verified that the stream is received not from the best SPT path to the source (but on the RFP path to the RP), to join hop by hop the source tree. Once the source tree is completed and traffic arrives to the last hop router “also” from the SPT path, the last hop router sends a prune message towards the RP. The shared tree is hop by hop removed and the source tree remains.
Anyway the shortest-path tree requires more memory than the shared tree at the trade off of a better path and latency. In this case the routers on the SPT path end up with a (S,G) entry, while the routers on the shared tree path end up with a (*,G) and a (S,G) prune entry (PS: in DM ALL routers in the network will have an entry!). If the will is not to consume memory and CPU of routers on the Source Tree at trade off of a less optimal path, the “ip pim spt-threshold” can be modified. If the value is set to >0, but less than “infinity”, traffic must overcome that threshold of kbps (data rate) to be reverted to the Source Tree. If the “infinity” keyword is specified, all sources for the specified group use the shared tree, never switching to the source tree. Note: a “group-list <ACL>” extra parameter can be specified to select which groups the SPT threshold applies to. If a value of 0 is specified or the group list is not used, the threshold applies to all groups.
This can be imposed by issuing on each router the “ip pim spt-threshold infinity” global command:
On all Routers:
conf t
ip pim spt-threshold infinity group-list 5 <<<<<< Never revert to SPT Source Tree
access-list 5 permit 224.0.0.0 15.255.255.255
end
clear ip igmp group
clear ip mroute *
(*) Note anyway that if receivers are on a router between Source and RP, they will anyway have the stream directly via the partial source tree, not crossing the RP. For billingor similar purposes, place the RP BETWEEN all Sources and all Receivers.
———-> RT1 stays on the path
RT1sh ip mroute count
IP Multicast Statistics
4 routes using 2326 bytes of memory
3 groups, 0.33 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 258, Packets received: 449
RP-tree: Forwarding: 7/0/1344/0, Other: 7/0/0
Source: 192.168.1.1/32, Forwarding: 251/13/1344/143, Other: 442/60/131
RT1sh ip mroute count
IP Multicast Statistics
4 routes using 2326 bytes of memory
3 groups, 0.33 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 239.255.1.1, Source count: 1, Packets forwarded: 265, Packets received: 458
RP-tree: Forwarding: 7/0/1344/0, Other: 7/0/0
Source: 192.168.1.1/32, Forwarding: 258/13/1344/143, Other: 451/62/131
RT1sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
L – Local, P – Pruned, R – RP-bit set, F – Register flag,
T – SPT-bit set, J – Join SPT, M – MSDP created entry,
X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
U – URD, I – Received Source Specific Host Report, Z – Multicast Tunnel
Y – Joined MDT-data group, y – Sending to MDT-data group
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.255.1.1), 00:04:09/00:02:42, RP 140.1.2.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1.1, Forward/Sparse, 00:04:09/00:02:42
Serial0, Forward/Sparse, 00:00:57/00:02:36
(192.168.1.1, 239.255.1.1), 00:03:33/00:03:19, flags: T
Incoming interface: Serial1.1, RPF nbr 138.1.15.10
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:52/00:02:35, A <<<<<<< Not removed anymore!!!!
<<<<<<< Shared Tree stays