Basic Multicast part 2 – PIM Sparse Mode – Static RP

This is the second part of my previous topic about Multicast. This time I will demonstrate how PIM Sparse Mode works based on the same topology as the previous post.

Let´s consider the following topology:

Source: The multicast source 150.1.0.4 will be sending to multicast group 239.10.10.10 which is part of the administratively scoped addresses assigned by IANA which is for use in private multicast domains, much like the IP unicast range defined in RFC 1918.

 RP: The RP is R4 with IP: 4.4.4.4

 IGP: The IGP used is EIGRP

 Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services

 As PIM Sparse Mode is a much wider topic than PIM Dense Mode I will start to talk about PIM Sparse Mode with static RP, than Auto-RP, Auto-RP listener and finally PIM BSR.

PIM Sparse Mode is based on the “pull model” or “explicit join” which use a combination of both a shared tree and a source-based tree. The RP is making the connection between the shared-tree (tree build down the Multicast receivers) and the source-based tree (tree built up to the source).

PIM Sparse Mode uses (*,G) entries to forward Multicast traffic unlike PIM Dense Mode. So the key difference between PIM Sparse Mode and PIM Dense Mode is that PIM Sparse Mode the forwarding state in the router is set up as a result of an explicit “join” where in PIM DM (PIM Dense Mode) the forwarding state is set up upon arrival of multicast traffic.

PIM SM (PIM Sparse Mode) is built around a single, unidirectional shared tree whose root is the rendez-vous point (RP). The RP knows all the receivers and all the source and make a connection between both therefore avoiding the flood and prune behavior of PIM DM. As PIM SM uses a unidirectional tree where multicast data can only flow down the shared tree, multicast source must register with the RP to get the multicast traffic down the shared tree. This registration process triggers an SPT (source path tree) from the RP to the source.

PIM SM gives more scalability over PIM DM as traffic doesn´t have to be flooded everywhere for the multicast routers to know the multicast source.

The big advantage of PIM SM it doesn´t allow only to receive multicast traffic via the shared tree through the RP but it also possible to build an SPT (source path tree) to the source. The advantage is that the multicast traffic is send directly from the source to the multicast receivers without going through the RP thereby reducing network latency and eventual congestion at the RP. The disadvantage is that routers must create  and maintain (S,G) state in their multicast routing table but it is much less than in PIM DM in this mode all the routers must maintain (S,G) state even if there are no active receivers (flood and prune mechanism). The question that could be asked is the following: “If SPT in PIM SM is desirable why join the shared tree in the first place? That is because routers have no way of knowing that a source is active along the shared tree before the first multicast packets start flowing down the shared tree.

Using Static RP is the easiest way to provide RP information to all Multicast router in the Multicast domain. The disadvantage is that it is not a scalable solution.

Let´s enable PIM Sparse Mode on all the interfaces in every router in the network by using the command: “ip pim sparse-mode”. Please note that multicast routing is already configured on all the routers.

One we have enabled PIM Sparse Mode we configure each router with the following static RP information: “ip pim rp-address 4.4.4.4”. This command tells the multicast router where to send the PIM join (*,G) when they need to join the shared tree in Sparse Mode. We will see later on (next post) that it is possible for a Multicast router to learn RP to Multicast group mapping dynamically with Cisco Auto-RP or PIM v2 Bootstrap mechanism. But for now on let´s look at how to configure PIM Sparse Mode with static RP.

Let´s check RP to group mapping on R1:

So R4 is the RP for all multicast group in this case: 224.0.0.0/4. We could have use the following option instead: ip pim rp-address<IP> [ACL] [override] where ACL define which group the RP will be mapped to. The override keyword will force the router to retain static information even if a different RP for the group is learned via Auto-RP.

 a)    Source registration

 No Receiver has registered with the RP for the multicast group 239.10.10.10 yet.

 In order to have the multicast traffic sent down the shared tree, the RP must register with the multicast source. Please note that the receivers can join the shared tree before the source register with the RP. There is no process of order operation here. But for this example we will start by registering the source with the RP as frequently the multicast source may begin sending traffic before any receivers join the group. In order for the source to register with the RP, the RP must build a SPT (source path tree) to the source but in order to do that the RP must somehow know that the source exist so PIM SM makes uses of the PIM register and PIM Register stop messages to implement a source registration process to accomplish the task.

PIM register message are sent by the first-hop DR (that is the DR directly connected to the source) to the RP.

Let´s send multicast traffic from the source (150.1.0.4) to the group 239.10.10.10.

With debug (debug ip mpacket, debug ip pim and no ip mroute cache on interface) on R3,R4 and R5 we can observe the following on R5 and R3:

The above output is telling us that there is an issue with the RPF process when multicast flow to 239.10.10.10 is received inbound on F0/1 (interface directly connected to the source).

Let´s see what the RPF check for the RP is:

So the issue is that there is no route to the RP IP address and hence the RPF process is failing. We can also observe that if we look at the multicast routing table on R5 or R3:

The incoming interface for the RP is null. In PIM SM the incoming interface of an (*,G) point towards the RP and the RPF is based on the route toward the RP IP and not the source IP. So in this case as we don´t have a route towards the IP address of the RP the incoming interface is null and therefore the entry is pruned.

So let´s inject the RP IP into the IGP which is in this case EIGRP and send multicast traffic from the source again.

As R5 wins the DR election on the 150.1.0.0/24 segment due to the highest IP compare to R4 (DR priority are equals to 1 on both routers) it will send an unicast PIM register message to the RP as soon as it receives the multicast traffic from the source. The issue we have seen with the IP of the RP not present in the RIB of the routers is now fixed so the RPF towards the RP should succeed which is the case as we can see in the debug output bellow made on R5:

So R5 sends a PIM register message to R4 (the RP) to tell R4 that it knows the source 150.1.0.4 sending multicast traffic to 239.10.10.10. Actually the PIM register message encapsulates the multicast packet sent by the source into a unicast packet. See this wireshark output taken when R5 send a PIM register to R4:

From the output above we can clearly see that the original multicast packet from the source is encapsulated into the PIM register unicast packet.

 R4, the RP is now receiving this Register message and de-encapsulates it and examine the destination address of the multicast packet inside:

Based on the destination multicast address R4 check its multicast routing table and in this case sees that it has no state for this group as no one has joined the shared tree yet. R4 creates an (S,G) entry upon receiving the PIM register message and also an (*,G) entry as (S,G) cannot exist without a (*,G) parent entry and therefore R4 create an (*,G) entry for group 239.10.10.10 with a Null outgoing interface list first as there are not receiver for this multicast group yet.

Likewise the (S,G) entry is created with a copy of its parent (*,G) outgoing interface list that is why we can see in the output bellow that the outgoing interface list is Null for the (S,G) entry.

If we do a show ip mroute on R5 which is the router responsible (DR) for registering the source with the RP we can see the following:

That means that R5 has created a (S,G) entry upon receiving multicast traffic from the source and that R5 is sending register messages to The RP R4. The FTP flag means the following:

 F flag: Source is directly connected and the register process must be used to notify the RP ot this source.

P flag: Outgoing interface is null as no one has joined the SPT tree yet for this source

T flag: traffic is being received from the source.

Registering flag: Means that R5 is in the process of register the source with the RP. However in actual practice this event happens so fast that it is almost impossible to catch the router in this state.

 So now if we step back to R4, the RP, as it has no receiver which have joined the shared tree yet it doesn´t need to receive the register message from R5. Remember that the register packets are unicast PIM sent to RP from the DR and these packets are encapsulating the multicast packet send from the Source to the multicast IP address 239.10.10.10 (in our case).

 To stop this register process the RP sends a PIM register stop message to  R5 as we can see in the output bellow:

Upon receiving the PIM register stop message from R4, R5 clear the “registering” indicator we saw previously which means that R5 will stop to send encapsulated multicast packets to R4 for a while. If the source is still active the process will start over but if the source is not active anymore the (S,G) entry will expire after 3 minutes. When R5 receive multicast traffic from the source the expire timer of the (S,G) will be reset to 3 minutes and R5 will send a PIM register message to R4.

 A receiver registers with the RP for the multicast group 239.10.10.10

 Now let see what happen when a receiver join the multicast group 239.10.10. In this case we make R1 join the multicast group 239.10.10.10. Upon joining R1 create an (*,G) entry which in turn trigger a PIM (*,G) join toward the RP (R4). When the RP receive a PIM (*,G) from its PIM neighbor (R2 in this case) via its Serial0/0.1 interface  it adds this interface to the outgoing interface list of the (*,G) state for 239.10.10.10 and as a consequence adds also this interface to the OIL (outging interface list) of the child (S,G) entry for this group. Recall that General multicast rule states that: “additions or deletions to the outgoing interface list of a (*,G) entry are replicated to all associated entries as long as the incoming interface (RPF interface) of a multicast entry never appear in its  outgoing interface list”.

 So R4 has the following state in the multicast routing table now:

As a side note, I would like to point out that there is an interesting fact here that we will cover later which is SPT switchover. I have used R1 to join 239.10.10.10 in order to generate a PIM join up to R4. If you look at the topology R1 which is last-hop router should have switched to the source path tree that is the shortest way up to the source which is via R2 then R3 and not R4 the RP. By default Cisco routers make SPT switchover after the first packet was received. But in this case I have disabled this process on R1 with “R1(config)#ip pim spt-thresold infinity” in order to show that the outgoing list entries was mirrored from (*,G) to (S,G) on R4 although in PIM SM only (*,G) are used to forward multicast traffic unless a (S,G) exist. I will come back to this topic later on.

 Back to R4 output above, we can see that the P flag (pruned) has been removed from both entries upon receiving the PIM join message from R2 for 239.10.10.10. That means that the RP is now ready to send multicast traffic down S0/0.1 as it has now a receiver for this group.

Upon clearing the flag from Pruned to not pruned on the (*,G) entry R4 now join the SPT by sending a PIM (S,G) towards the source to restart the flow of multicast traffic. Then, when R5 (DR) receives this PIM join packet it will remove the pruned flag on the (S,G) entry which will in turn enable forwarding of multicast stream to R4 (pruned flag removed on R5 (S,G) entry) as we can see in the output bellow:

That is also a reason why R4 the RP has kept the (S,G) entry so it could send a PIM (S,G) join later on when a receiver was active for 239.10.10.10.

R5 also will stop to send PIM register message to R4 as R4 has indicated to R5 to stop this process by sending a PIM register stop message. Multicast packet from R5 to R4 are not encapsulated anymore in unicast packet but are sent as normal multicast packet.

 The source registration process is over now and the RP is now the central point of connection between the shared tree (where multicast traffic is pushed down the receivers) and the source tree (where multicast traffic is pulled from the source).

 a)    SPT Switchover

 As I mention before (see side node above) Cisco implementation of PIM SM dictates that the last-hop router on the shared tree can join the SPT upon receiving the first multicast packet down the shared tree in order to have optimal path to the source and removes the RP as a possible “bottleneck” of all multicast traffic flows. The advantage of SPT switchover is that traffic goes directly from the source to receiver without going through the RP first thereby reducing network latency and possible congestion at the RP. As you can see on the topology, R4 is not situated in the optimal path from the source to the receiver (in this example R1). The more optimal path will be from the source directly to R3, R2 and then R1.

Also remember that R1 has been configured previously with R1(config)#ip pim spt-thresold infinity” to prevent SPT switchover.

R1 is consider the last-hop router because it has the C flag in the (*,G) entry which means that is has directly connected receiver (in fact in this case it is himself by using the “igmp join group” command).

To demonstrate the switchover to the SPT on R1 let´s configure the following: “R1(config)#ip pim spt-threshold 0” which basically means that R1 will always join the source tree upon receiving the first multicast packet from the source. After the first multicast packet is received we get the following output:

The J flag is now set and a (S,G) have been created. Recall that the main goal of SM is the minimize the (S,G) entries. As the SPT threshold is set to 0 the J flag will always be present on the (*,G) which means that a switchover is in process. A (S,G) entry is then create with the copy of its parent (*,G) entry outgoing interface list and because this list is not empty R1 sends a (S,G) join toward the source as highlighted in the following output:

Upon receiving a PIM (S,G) join, R2 will create an (S,G) entry like R1 did and forward the PIM (S,G) join message up toward the source. This will indeed create the SPT. We can see that R2 send the PIM (S,G) to R3 as R3 is its RPF neighbor for the source based on the IGP shortest path to the source 150.1.0.4.

 Now an interesting fact comes into this scenario. R2 sees that the RPF neighbor for the (S,G) and the (*,G) are not the same as we can see in the output bellow:

That means that at this point (on R2) the SPT tree and the shared tree diverge and as general PIM SM rule states when it is the case the router on which the trees diverge should send a (S,G)RP-bit prune up the shared tree in order to receive traffic only from the source path tree which is the optimal path to the source. This special type of prune is to tell the RP to prune the source traffic from the shared tree in order to avoid receiving multicast via the shared tree and the SPT at the same time.

We can see in the following output that R2 is sending a (S,G)RP bit prune up towards the shared tree (To R4):

Then R4, the RP receive the PIM (S,G) RP bit prune which trigger the removing of interface s0/0.1 from the (S,G) outgoing list (that is to say the interface is pruned) which in turn trigger a (S,G) PIM prune towards the source up to R5 (the DR):

We can see that this interface has now been cleared on R4. This will result in R4 not forwarding traffic down the shared tree anymore as long as the (S,G) entry has the outgoing interface list set to NULL.

Now the optimal multicast forwarding path is achieved and the multicast flow is going like that: Source to R3, to R2 and then to R1.

Next post will be on PIM SM with Auto-RP and this time I will not wait 5 months 😉

/Laurent