PIM Sparse Mode Packet Deep Dive
PIM Sparse Mode Packet Deep Dive
Configuring PIM-SM: Configuring PIM-SM can be done by following commands in global mode and interface mode.
Enable PIM-SM on every interface in every router in the network, using the following interface command:
However, PIM-SM mode works when the Presence of RP is defined on routers participating in multicast traffic. So we can define RP via static, Auto-RP and another method. We will discuss these method in details:
But for here, we can define you as static way:
Here, the recommended method for enabling multicast is to use pim sparse-dense mode. Router can work well in sparse mode but depending on existence of RP it can switch to dense mode to ensure that multicast packet should be delivered to destination.
PIM-SM States Rule:
PIM-SM stares rules can be broadly defined as per following criteria:
Apart from all general rule we discussed in PIM-DM, fooling are the PIM_SM rules which is following while preparing the mroute table.
PIM-SM (*, G) state Rule:
PIM-SM (*, G) is created only when directly connected is joining the group by sending the IGMP membership report or when router receives the (*, G) join receipt. So we can say that (*, G) entry is created only on demand.
PIM-SM Rule 1: PIM-SM (*, G) is created when Explicit Join operation is done.
PIM-SM Rule 2: The Incoming interface of (*, G) will always points up the shared tree towards RP.
In PIM-SM mode, the IP address of RP is used to find the RPF interface.
PIM-SM(S, G) State Rule:
PIM-SM Rule 3:
There are some following condition which causes (S, G) entry to be created on router:
- (S, G) entry is created when router receives the (S, G) join/Prune message
- (S, G) entry is created on last-hop router when it switches to SPT
- (S, G) entry is created when there is unexpected arrival of (S, G) traffic and when there is no (*,G)
- (S, G) entry is created at RP when Register Message from Source is received.
PIM-SM Outgoing interface rules:
Addition of interface in OIL of (*, G) or (S, G) can be achieved by PIM-SM Rule 4 in either of following condition:
- When (*, G) or (S, G) join is received via this interface
- When there is a directly connected member of the group exists on the interface.
Removal of interface in OIL of (*, G) or (S, G) can be achieved by PIM-SM Rule 5 in either of following condition:
- When (*, G) or (S, G) prune is received via this interface or no directly connected member of this group on this interface
- Interface expiration timer count goes to zero
PIM-SM state Maintenance Rule:
Maintenance rule basically relates to expiration timer of interface which is reset to 3 min as result of following conditions:
PIM-SM Rule 6
- When (*, G) or (S, G) join is received on interface
- An IGMP membership report is received from directly connected member on interface.
PIM-SM (S, G) RP Bit State Rules:
When last Hop router has switched from Shared tree to SPT than it no longer needs to receive the same (S, G) traffic from shared tree and to stop this traffic from shared tree router will (S,G) state will send the (S,G) prune with RP-bit setup called as (S,G) RP-bit prune.
Sending (S, G) RP-Bit Prune:
A router will send the prune message when it has joined the SPT for source and no longer wants to receive the source traffic via shared tree and in prune message (S, G) RP-bit prune up the shared tree. It can be possible that on same interface (S, G) join and (S, G) RP-bit prune message can be sent via same interface and in order to avoid this PIM-SM Rule 7 is applied.
PIM-SM Rule 7:
Router will send (S, G) RP-bit Prune up to shared tree when RPF neighbor for (S, G) entry is different from RPF neighbor of (*, G) entry.
When any router receive the (S, G) RP-bit prune message from a downstream router, following action is performed.
- Creates an (S, G) state entry if this entry does not exits
- Sets the RP-bit in the (S, G) entry denoted by R flag.
- Populates the outgoing interface of (S, G) by coping the interface of (*, G) entry based on general Rule 3
- Removes the interface from which (S, G) RP-bit prune was received from OIL list
- Re-computes the RPF information of (S,G) entry based on RP address instead of Source address
As soon as PIM-SM(S, G) RP-bit states that (S, G) forwarding table is applicable to shared tree and incoming interface of the (S, G) entry must point to RP instead towards source S.
PIM-SM Rule 8: This rules states that the RPF interface that is incoming interface of SM (S, G) entry is calculated by using Source IP address and when RP-Bit is set the RPF interface would be IP address of RP.
Let’s understand how Traffic and RPF interface is calculated when (S, G) RP-bit rune is used.
R4 and R5, both receiving (S, G) traffic down the shared tree before (S, G) RP-bit Prune is send and below is the mroute table of R3.
Now let’s suppose R5 joins SPT to Source via R1 and sends the (S, G) RP-bit Prune to Router R3 which will stops the redundant flow of (S, G) traffic from its shared tree.
When R3 Receives the (S, G) RP-bit Prune, it will create the (S, G) entry based on rules
Now when (10.10.10.10, 22.214.171.124) packet is arrived at R3 via shared tree, R3 will search (S, G) entry in its mroute and will use its existing (S, G) entry to forward packet. On (10.10.10.10, 126.96.36.199) R3 will check its incoming interface to see that whether arriving packet has passed the RPF check and as R flag is setup , the incoming interface will point to fa0/1 towards RP instead of fa0/0 as a result of PIM-SM Rule 8. Because multicast packet is flowing down shared tree and arrives at fa0/1, the RPF check succeeds and R3 will then forward the packet out all interface as per OIL List.
PIM-SM State Flags:
Below table indicates the FLAG and its type used in PIM-SM mode.
Working of PIM-SM Mode:
In this we will learn how PIM-SM work and how its mroute table is populated when it’s join the shared tree, how it switches to SPT and how Prune works.
Host expresses desire to join (188.8.131.52) and send IGMP membership report to R3 by multicasting this IGMP report to 184.108.40.206. When R3 receives this packet, will check its mroute table for (*, G) entry and will not found any entry related to that and hence will create new (*, G) entry.
- First line of the above mroute indicates that it was created when it receives the (*, G) join from Host and RP for this group is 10.11.11.11.
- Second line shows that RPF interface is fa0/1 and it was computed by PIM-SM rule-2 and General Rule 2. And RPF interface is calculated by IP address of RP on shared tree via neighbour 10.12.12.12.
- Third line show the OIL which is F0/0 and is added based on PIM-SM Rule-4.
As the R3 created new (*, G) entry, R3 will send the (*, G) join message towards R2 (RPF neighbour). R2 will also create the new (*, G) entry for group 220.127.116.11 in same way as R3 does.
As R2 has also created (*, G) entry, It will send the (*, G) join towards its RPF neighbour which is R1. When R1 which is also RP receives the (*, G) join from R2, it will create (*, G) entry in its mroute table as shown below.
Till here, we have successfully set up state in all routers and the branch from RP is ready on shared tree to forwards traffic from RP to host, if RP started receiving the multicast packet from source.
Now let’s see how Source starts sending multicast packet and how RP gets registered with Source.
PIM Register Process:
In PIM-SM, it works on unidirectional model of tree where, Source sends the traffic on SPT to RP and from RP the multicast traffic flows to Host on shared tree, if PIM-SM has not switches to SPT.
Now when the shared tree is created from RP to Branches there are PIM registrations process so that source can be able to send the traffic to RP. There are some possible cases in this.
Receivers Join first: In this before Source and RP get registered, shared tree has been created from RP to all host (branches). Now let’s suppose that shared tree has been created already before any source begin sending.
Let’ see the state of R1 (RP) before any source begin sending:
Now on R4 and R5, Source has not started sending anything so there will be no state for group 18.104.22.168.
Now let’s say Source on R5 is connected with source and they started sending traffic for group 22.214.171.124, R5 will encapsulates this multicast traffic in register message and unicast to RP. RP which is R3 de-capsulate packets and forward down shared tree.
Let’s understand how it happens:
When Source starts sending multicast on 126.96.36.199, and R5 receives this packet from source it will start find (S, G) entry and (*, G) entry and which in any case will not find any one of them. R5 will than create the (S, G) but due to this step a (*, G) entry will also be created automatically as per general rule 1.
Now R5 will also find that Source is directly connected, R5 will began encapsulating packet in Register packet and unicast to RP.
RP upon receiving, will de-capsulate this and examine the destination address of multicast packet and forwards this multicast packet to interface as per OIL.
- In this (*, G) entry the first line has sparse mode due to which S flag is set up. There is also P Flag because OIL is NULL. In this the incoming interface is interface towards RP that is RPF neighbour 10.13.13.14. This is why because (*,G) is used to control the multicast traffic down the shared tree and as there is no IGMP Membership or no directly connected member who are willing to join this group so OIL of (*,G) remains NULL and hence P flag is set up.
- In (S, G) entry 192.168.1.2 is sending traffic to group 188.8.131.52, F flag is set because the source is directly connected and P is due to its OIL is NULL and T is because it has received at least one packet of that group.
- The incoming interface of (S, G) is fa0/1 which is towards source and RPF neighbour is 0.0.0.0.
- However the OIL is also NULL with P flags set because in (S, G) OIL reflects the interface where directly connected member of group or downstream neighbour that have joined the SPT, but both above condition is not met so OIL is NULL.
Now RP will send the (S, G) join interface towards source so that R5 can join the SPT and pull multicast packet from 192.168.1.2 to RP. The (S, G) join will go via hop to hop and reaches to R4 first and then to R5 and form the SPT between source and RP.
R1 State after sending (S, G) join:
R4 State after (S, G) join:
R5 State after (S, G) join:
- On R1, RP has created a new (S, G) entry because it has sent (S, G) join. The outgoing interface list of the (S, G) was populated with a copy of the outgoing interface list from the parent (*, G) entry according to General Rule 3. The incoming interface points toward the source through RPF neighbor 10.14.14.14 (R4) via interface fa0/1, which is based on PIM-SM Rule 8 and General Rule 2.
- On R4, both (*, G) and (S, G) state is created as a result of the (S, G) Join received from the RP. Also (*, G) entry on R4 is pruned (P flag is set) because the outgoing interface list is Null.
- And if we look at (S, G) entry incoming interface that points toward the source via RPF neighbor 10.13.13.15 R5 via fa0/0. The outgoing interface list contains fa0/1, which is the interface by which the (S, G) Join from the RP was received.
Now as the (S,G) and (*,G) is created RP will began to receive (SPT ) traffic from Source, and as the SPT is created , next time RP receives an (S,G) register message and found that it is correctly receiving multicast traffic from source , it will respond by sending back an (S,G) Register-Stop message.
Now When R5 will receive the register stop message from RP it will not send multicast traffic encapsulating in register message and will update its (S,G) state entry by clearing the Registering indicator .
Register process is now complete and Multicast traffic will flow from Source to RP via SPT which is further send down from RP to host.
When Source Registers first: When source register first before shared tree is created, following steps are used:
Step 1 Source begins sending Group G traffic.
Step 2 Router A encapsulates the packets in Registers; unicasts to RP.
Step 3 Router C (RP) has no receivers on shared tree; discards packet.
Step 4 RP sends Register-Stop to Router A.
Step 5 Router A stops encapsulating traffic in Register messages; drops further packets from source.
Step 6 Router C receives (*, G) Join from a receiver on shared tree.
Step 7 RP sends (S, G) Joins for all known sources in group.
Step 8 RP begins receiving (S, G) traffic down SPT.
Step 9 RP forwards (S, G) traffic down shared tree to receivers.
PIM-SM will switch from shared tree to SPT when traffic rates exceeds a threshold and we say this threshold as SPT-Threshold.
The switch to SPT can be done based on two tasks:
- On each second, Router will compute total traffic rate flowing down the shared tree.
- If this rates exceeds, SPT-Threshold, it sets JOIN-SPT “J” flag in the (*, G) entry.
Once the above action is performed , STEP 2 is used which is discussed below and after above STEP , it triggers a switch to the SPT that is executed when next time a packet is received via shared tree. When this packet is arrived, it source address is the SPT tree:
If the J flag is set to (*, G) then
- Join the SPT for (Sr, G)
- Mark (Sr, G) entry with flag J
- Clear Flag “J” in (*, G)
Now let’s discuss the SPT Switchover in detail
In above figure, the (Sr, G) traffic is flowing down from shared tree to both host before switch to SPT. Following is the Router states before switchover.
Now, let’s suppose total traffic rate flowing down to shared tree exceeds SPT-Threshold at R3. Now once this is found, R3 will join the SPT (J) flag in (*, G) for group 184.108.40.206 which indicates that there is Switch to SPT is going to take place. While this is being done, next (Sr, G) packet arrives and which triggered the switchover to SPT for source.
Now let’s suppose, we received (Sr, G) packet down the shared tree than R3 checks (*, G) entry and found that there is J flag is set. Now R3 creates the (Sr, G) state and sends an (Sr, G) join towards source to join SPT for this source. This Join will travel hop to hop to form the SPT.
State of R3 after switchover:
You can see that (Sr, G) entry has been created and J flag has been set which indicates that state was created as result of SPT-Switchover mechanism. When router R2 receives the (Sr, G) join, R2 also joins the SPT by creating the (Sr, G) entry in mroute table.
Now R2 detects that there is different path used in shared tree and SPT tree in above two figures which triggers R2 to generate the (Sr, G) RP-Bit Prune msg to F0/0 towards RP that is to R1.
Now R2 will also forwards (Sr, G) Joins to hop by hop router to first hop router connected to source directly and thus building SPT tree for source (Sr). Once this is done, Traffic from Source Sr will flow all along source to R3 and finally delivered to Host at R3.
The (Sr, G) RP-bit Prune is also sent up to shared tree to R1 and adjusting the OIL list accordingly.
Pruning is used to stop the unwanted traffic in both types of tree shared or source tree. We will discuss both scenario steps.
Pruning the shared tree:
Following are the steps used when pruning message is used on shared tree:
Step 1 R2 is a leaf router; last host leaves group G.
Step 2 R2 removes fa0/1 from (*, G) and any (Sr, G) outgoing interface lists.
Step 3 R3 (*, G) outgoing interface list is now empty; sends (*, G) Prune toward RP.
Step 4 R2 receives Prune; removes fa0/2 from (*, G) outgoing interface list.
Step 5 R2 (*, G) outgoing interface list is now empty; send (*, G) Prune toward RP.
Step 6 Pruning continues back toward RP.
Pruning the source tree:
Following are the steps used when pruning message is used on source tree:
Step 1 R3 is a leaf router; last host, leaves group G.
Step 2 R3 remove fa0/1 (*, G) and any (Sr, G) outgoing interface lists.
Step 3 R3 (*, G) outgoing interface list is now empty; sends (*, G) Prune toward RP.
Step 4 R3 stops sending periodic (S, G) Joins.
Step 5 R2 receives Prune; removes fa0/2 from (*, G) outgoing interface list.
Step 6 R2 (*, G) outgoing interface list now empty; sends (*, G) Prune toward RP.
Step 7 (Sr, G) state times out; (Sr, G) Prune sent toward Si.
Step 8 (Sr, G) traffic ceases flowing down SPT.