PIM Sparse mode, static RP

Sparse mode logic (pull mode) is the opposite of Dense mode logic (push mode), in Dense mode it is supposed that in every network there is someone who is requesting the multicast traffic so PIM-DM routers begin by flooding the multicast traffic out of all their interfaces except those from where a prune message is received to eliminate the “leaf” from the multicasting tree (SPT), the Source-Based Tree (S,G); as opposed to Sparse mode that send the traffic only if someone explicitly requested it.

Figure 1 illustrates the topology used to study PIM Sparse mode, in which the multicast source connected to R1 will provide the network with multicast traffic, R3 is considered as the Rendez-Vous point RP and a client requesting the multicast traffic is connected to R4.

Not like Dense mode, which build a separated source-based tree (S,G) between the source and the requester of the traffic, Sparse mode mechanism is based on a fixed point in the network named Rendez-Vous point.

All sources will have to register with the RP to which they send their traffic and thereby build a source-based tree (S,G) between them and the RP (not with the final multicast receiver like in PIM-DM) and all PIM-SM routers, “whatever” multicast traffic they are requesting, have to register with the RP and build a shared-tree (*.G)

Figure 1 PIM-Sparse mode topology

PIM-SM mechanism is composed of four main stages:

1 – the registration process of the source with RP.

2 – the creation of RPT (shared tree) of PIM-DR routers with the RP.

3 – The creation of SPT (Source Path Tree) of the upstream source router with the RP.

1 – Registration process of the source with RP.

The source router (directly connected to the source) will not be able to register with the RP if there is no already built RPT between PIM-DR routers and the RP, so source routers will continue to send their unicast registration packet every minute (with the first multicast packet encapsulated) to the RP and receive a Register-stop message from the RP that will ignore the packet.

2 – Creation of RPT (shared tree) of PIM-DR routers with the RP.

A PIM-DR router that have received an IGMP membership report for a specific multicast group will send a join message to the RP (statically configured) and build a shared tree (*,G)

generally the advertised IP of the RP is a loopback IP, because it is always UP and reachable through any of the RP physical interfaces.

3 – Creation of SPT (Source Path Tree) of the upstream source router with the RP.

Now that RP have already registered members for the multicast group that source PIM router is trying to advertise, it will accept the registration and decapsulate the first multicast packet and forward it to the requester.

For simplicity sake this lab will be limited to static RP configuration. As in dense mode the configuration commands needed are very simple:

1) Enabling multicast routing.

2) Enabling PIM sparse mode on all interfaces that could participate in the multicast.

3) Set statically the address of the RP (Rendez-vous Point) on all routers, RP itself included.

R4:

ip multicast-routing !! A best practice is to enable PIM on each interface that is !!susceptible of forwarding multicast traffic. interface Ethernet0/0 ip address 192.168.40.1 255.255.255.0 ip pim sparse-mode ! interface Serial1/0 ip address 192.168.14.4 255.255.255.0 ip pim sparse-mode ! interface Serial1/1 ip address 192.168.54.4 255.255.255.0 ip pim sparse-mode !! Statically configure the RP (10.3.3.3 is an R3 loopback !!interfaces reachable from everywhere). The access-list RP-Group, !!set the multicast group for which to register with the static RP ip pim rp-address 10.3.3.3 RP-Group ! ! ip access-list standard RP-Group permit 239.255.1.1 ! !! don’t forget connectivity using the routing protocol of your !!choice router eigrp 10 network 192.168.14.0 network 192.168.40.0 network 192.168.54.0 no auto-summary

A similar configuration should be configured on all routers.

Now in our lab and according to the explained PIM-SM logic we are expecting that the multicast traffic is forwarded from the multicast source 10.10.10.1 to the RP R3 and then to the router R4 and the client.

Let’s check this:

R4#mtrace 10.10.10.1 192.168.40.104 239.255.1.1 Type escape sequence to abort. Mtrace from 10.10.10.1 to 192.168.40.104 via group 239.255.1.1 From source (?) to destination (?) Querying full reverse path… 0 192.168.40.104 -1 192.168.40.1 PIM [10.10.10.0/24] -2 192.168.14.1 PIM [10.10.10.0/24] -3 10.10.10.1 R4# R4# R4#sh ip pim rp Group: 239.255.1.1, RP: 10.3.3.3, uptime 00:05:03, expires never R4# R4#

*** The RP seems to be correctly configured but the multicast trace route shows that the multicast traffic is taking the path between R4 and R1 ???

and this is confirmed by the BW graphics of routers (Figure2) :

Figure2: interface BW of all routers

The only interfaces showing activities are R1(fa0/0,s1/1) and R4(fa0/0,s1/0).

==> Note that in the remaining interfaces of other routers show a pick of very short traffic after which R1 and R4 start to forward multicast traffic.

Let’s digress for a moment and take a look at the topology (figure3) where clearly PIM-SM mechanism using the RP is not the optimal choice, it is obvious that the best mechanism will be a direct SPT that will immediately find the best/shortest path between the source and the client.

Figure3: not optimal PIM-SM

Here comes the concept of SPT and best path between the source and the receiver, in fact in PIM-SM after building the SPT and RPT around the RP, PIM-DR (connected directly to the client) will examine the RPF table and find that the path through RP is not the best path to the source of multicast and will try to join directly the upstream router R1 by building an SPT (S,G) and prune the path through RP.

In fact the pick of traffic correspond to the first phase of PIM-SM where the network forwarded the first packet(s) through RP and right after it switched from RPT through RP to a direct SPT.

Here is a global config command that can extend the first phase of RPT based on the traffic rate threshold

ip pim spt-threshold <rate>/infinity

We can use a specific threshold in kbps after which it becomes not optimal to forward multicast traffic through RP or another option “infinity” and the router will never switch to SPT.

Let’s try it with R4:

R4(config)#ip pim spt-threshold infinity

R4#mtrace 10.10.10.1 192.168.40.104 239.255.1.1 Type escape sequence to abort. Mtrace from 10.10.10.1 to 192.168.40.104 via group 239.255.1.1 From source (?) to destination (?) Querying full reverse path… 0 192.168.40.104 -1 192.168.40.1 PIM [10.10.10.0/24] -2 192.168.54.5 PIM [10.10.10.0/24] -3 192.168.35.3 PIM Reached RP/Core [10.10.10.0/24] -4 192.168.23.2 PIM [10.10.10.0/24] -5 192.168.12.1 PIM [10.10.10.0/24] R4#

Now we recognize the concept of PIM Sparse mode that pass all traffic through the RP (the core) and this is confirmed by the interface BW graphs (figure 4) where R1 s1/1 and R4 s1/0 are the only interfaces not forwarding multicast, the complete opposite of figure 3

Figure 4 : Before switching to SPT:

let’s do a last thing: disable “ip pim spt-threshold infinity” on R4.

The result (figure5) confirm what have been mentioned earlier.

Figure 5: back to SPT

CONCLUSION

Sparse mode protocol build SPT (S,G) between the source and the RP and an RPT between RP and PIM-DR; moreover it can switch to a direct SPT (S,G) between the source and the receiver if the path is more optimal.