PIM takes care of providing a loop free path for multicast traffic by referring to the unicast routing table.

In case of PIM Sparse mode, RP acts as the root of the shared tree. Everything needs to be sent to RP first and then shortest path can be calculated if applicable. For the multicast traffic to flow end to end there should be two shared tree.

  1. Shared tree from last hop router DR (PIM router where receiver is connected) towards RP. This is noted as (*,G)
  2. Shared tree from RP towards first hop router DR (PIM router where source is connected). This is noted as (S,G)

Once both the shared trees are built, RP merges them by populating the outgoing interface list of (S,G) from the parent (*,G). In this process RP simply copies the outgoing interface list from the corresponding (*,G) to (S,G) entry.

After the end-to-end shared tree is built, the last hop DR (PIM router where receiver is connected) will initiate the SPT failover (if applicable) by sending a (S,G) join message towards source.

Steps involved for shared tree from receiver towards RP (*,G)
  1. When a receiver sends an IGMP join message, the immediate PIM router (last hop DR) will convert that IGMP join to PIM join.
  2. To send a PIM join message, the router (last hop DR) will create a (*,G) entry, puts the interface on which IGMP join message was received in the Outgoing Interface List (OIL) and sends the PIM towards the RP. Hence the incoming interface entry in the (*,G) will be the interface (RPF neighbor) through which it calculates the RP is reachable with lowest cost/metric.
  3. All intermediate routers (PIM neighbors) in that path from the router sending PIM join till RP, upon receiving PIM join will also create (*,G) entry where the outgoing interface is on which they received the PIM join from its downstream neighbor and the incoming interface is towards RP (RPF neighbor).
  4. Once the PIM join message reaches RP, RP will create a (*,G) and puts the outgoing interface on which it received the PIM join and incoming interface as ‘Null’ as RP does not forward the (*,G) further up the stream.
  5. Now at this point the shared tree is built from receiver to RP and can be seen on all intermediate routers hop by hop.
Steps involved for shared tree from source towards RP (S,G)
  1. When a source sends the traffic, the immediate PIM router (first hop DR) will check for a corresponding (*,G) for that group.
  2. It creates a (*,G) entry first where the incoming interface points towards the interface to reach RP and outgoing interface on which it received the traffic.
  3. It creates a corresponding (S,G) entry as well where incoming interface is the interface on which it received the traffic and outgoing interface as ‘Null’.
  4. Then it sends a unicast PIM source registration message towards RP. It actually encapsulates the multicast traffic inside the PIM source registration packet.
  5. Upon receiving the unicast message, RP de-encapsulates the packet and comes to know about the source ip address and the group details.
  6. RP checks for a corresponding (*,G) entry. If (*,G) is not present then RP creates one and then creates the (S,G).
  7. After creating the (S,G) entry, RP sends a (S,G) join to the intermediate router (PIM neighbor) towards Source.
  8. Once the (S,G) entry is made and populated with valid interfaces, RP sends Register Stop message towards Source.

Last hop router refreshes shared trees by periodically (once a minute) sending (*, G) Joins to the upstream neighbor in the direction of the RP. This (*,G) join message travels hop-by-hop towards RP.

Similarly it sends periodical (once a minute) (S, G) Joins to the upstream neighbor in the direction of the source to refresh the SPT tree.

We will use below topology to understand the multicast control plane traffic.

multicast-topology

Topology background

I am running bsr for RP discovery.

BSR config on RP router as below.

ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0

Multicast routing and PIM on all Interface config along with loop back need to be enabled on all routers.

ip multicast-routing  Global config mode
ip pim sparse-mode  Interface level config

OSPF is configured on all routers to populate the end to end unicast routing.

Now the config is ready and PIM is running end to end, let’s see the entries hop-by-hop when Receiver joins a group 226.100.100.100

  • RCV-1 is a host and acting as a multicast receiver. To simulate this lets configure ‘ip igmp join-group 226.100.100.100’ on its loopback 0.
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip pim sparse-mode
 ip igmp join-group 226.100.100.100
end
  • Upon receiving the igmp join the router converts to PIM join and creates (*,G) and sends to upstream router IOU3.
*Dec 13 18:21:13.976: PIM(0): Check RP 1.1.1.1 into the (*, 226.100.100.100) entry
*Dec 13 18:21:13.976: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 226.100.100.100
*Dec 13 18:21:13.976: PIM(0): Upstream mode for (*, 226.100.100.100) changed from 0 to 1
*Dec 13 18:21:13.976: PIM(0): Insert (*,226.100.100.100) join in nbr 10.10.35.3's queue
*Dec 13 18:21:13.976: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 226.100.100.100
*Dec 13 18:21:13.984: PIM(0): Building Join/Prune packet for nbr 10.10.35.3
*Dec 13 18:21:13.984: PIM(0): Adding v2 (1.1.1.1/32, 226.100.100.100), WC-bit, RPT-bit, S-bit Join
*Dec 13 18:21:13.984: PIM(0): Send v2 join/prune to 10.10.35.3 (Ethernet1/0)

(*, 226.100.100.100), 00:07:23/00:02:42, RP 1.1.1.1, flags: SJCL
 Incoming interface: Ethernet1/0, RPF nbr 10.10.35.3
 Outgoing interface list:
 Loopback0, Forward/Sparse, 00:07:23/00:02:42
  • Upon receiving this the upstream neighbor IOU3 populates its table with (*,G) entry and sends a (*,G) towards RP.
IOU3#
*Dec 13 18:21:13.985: PIM(0): Received v2 Join/Prune on Ethernet1/0 from 10.10.35.5, to us
*Dec 13 18:21:13.985: PIM(0): Join-list: (*, 226.100.100.100), RPT-bit set, WC-bit set, S-bit set
*Dec 13 18:21:13.985: PIM(0): Check RP 1.1.1.1 into the (*, 226.100.100.100) entry
*Dec 13 18:21:13.986: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 226.100.100.100
*Dec 13 18:21:13.986: PIM(0): Add Ethernet1/0/10.10.35.5 to (*, 226.100.100.100), Forward state, by PIM *G Join
*Dec 13 18:21:13.986: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 226.100.100.100
*Dec 13 18:21:13.986: PIM(0): Upstream mode for (*, 226.100.100.100) changed from 0 to 1
*Dec 13 18:21:13.986: PIM(0): Insert (*,226.100.100.100) join in nbr 10.10.13.1's queue
*Dec 13 18:21:13.986: PIM(0): Building Join/Prune packet for nbr 10.10.13.1
*Dec 13 18:21:13.986: PIM(0): Adding v2 (1.1.1.1/32, 226.100.100.100), WC-bit, RPT-bit, S-bit Join
*Dec 13 18:21:13.986: PIM(0): Send v2 join/prune to 10.10.13.1 (Ethernet0/1)

(*, 226.100.100.100), 00:07:56/00:03:28, RP 1.1.1.1, flags: S
 Incoming interface: Ethernet0/1, RPF nbr 10.10.13.1
 Outgoing interface list:
 Ethernet1/0, Forward/Sparse, 00:07:56/00:03:28
  • Now RP also creates the (*,G) but doesn’t forward to others as RP is the root itself.
RP#
*Dec 13 18:21:13.987: PIM(0): Received v2 Join/Prune on Ethernet0/1 from 10.10.13.3, to us
*Dec 13 18:21:13.987: PIM(0): Join-list: (*, 226.100.100.100), RPT-bit set, WC-bit set, S-bit set
*Dec 13 18:21:13.987: PIM(0): Check RP 1.1.1.1 into the (*, 226.100.100.100) entry
*Dec 13 18:21:13.987: PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (*, 226.100.100.100).
*Dec 13 18:21:13.987: PIM(0): Add Ethernet0/1/10.10.13.3 to (*, 226.100.100.100), Forward state, by PIM *G Join
RP#

(*, 226.100.100.100), 00:08:44/00:02:38, RP 1.1.1.1, flags: S
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 Ethernet0/1, Forward/Sparse, 00:08:44/00:02:38
  • As the RP is not aware of the source for this group, the entry will remain in the parent state of (*,G). The last hop router keeps sending the (*,G) join message every minute towards RPF neighbor to keep everyone updated that a receiver is still connected to it.

Let’s see the entries hop-by-hop when a source joins the group 226.100.100.100

  • SRC (interface loopback 0) is a host and acting as a source of multicast traffic for group 226.100.100.100. We will ping to 226.100.100.100 source loopback 0 to simulate the multicast source traffic.
  • Now once it starts the feed, the SRC router creates a (*,G) and (S,G) entry in its table.
(*, 226.100.100.100), 00:00:07/stopped, RP 1.1.1.1, flags: SPF
 Incoming interface: Ethernet1/1, RPF nbr 10.10.37.3
 Outgoing interface list: Null

(7.7.7.7, 226.100.100.100), 00:00:07/00:02:52, flags: PFT
 Incoming interface: Loopback0, RPF nbr 0.0.0.0
 Outgoing interface list: Null
  • It sends a Source register message by encapsulating the first multicast data into a unicast frame to RP.

src-register

  • RP de-encapsulates the unicast message, reads the actual source and group address and creates the (S,G) table derived from its (*,G). (*,G) is already present in RP as RCV-1 has joined the group. It populates the (S,G) with incoming interface on which it received the register message and the outgoing interface list will be copied from the parent (*,G) entry.
  • After this step RP sends a (S,G) join towards the intermediate router (in our case IOU3), RP waits for the shared tree to be complete. RP confirms that when it starts receiving the multicast feed directly on the group address (not via unicast register) and then sends a register-stop towards Source (SRC router).
RP#
*Dec 14 12:30:08.914: PIM(0): Received v2 Join/Prune on Ethernet0/1 from 10.10.13.3, to us
*Dec 14 12:30:08.914: PIM(0): Prune-list: (7.7.7.7/32, 226.100.100.100) RPT-bit set
*Dec 14 12:30:08.920: PIM(0): Received v2 Register on Ethernet0/1 from 10.10.37.7 for 7.7.7.7, group 226.100.100.100
*Dec 14 12:30:08.921: PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of (7.7.7.7, 226.100.100.100).
*Dec 14 12:30:08.921: PIM(0): Insert (7.7.7.7,226.100.100.100) join in nbr 10.10.13.3's queue
*Dec 14 12:30:08.921: PIM(0): Building Join/Prune packet for nbr 10.10.13.3
*Dec 14 12:30:08.921: PIM(0): Adding v2 (7.7.7.7/32, 226.100.100.100), S-bit Join
*Dec 14 12:30:08.921: PIM(0): Send v2 join/prune to 10.10.13.3 (Ethernet0/1)
*Dec 14 12:30:10.916: PIM(0): Removing register decap tunnel (Tunnel1) as accepting interface of (7.7.7.7, 226.100.100.100).
*Dec 14 12:30:10.916: PIM(0): Installing Ethernet0/1 as accepting interface for (7.7.7.7, 226.100.100.100).
*Dec 14 12:30:10.923: PIM(0): Received v2 Register on Ethernet0/1 from 10.10.37.7
*Dec 14 12:30:10.923: for 7.7.7.7, group 226.100.100.100
*Dec 14 12:30:10.923: PIM(0): Send v2 Register-Stop to 10.10.37.7 for 7.7.7.7, group 226.100.100.100
  • Once the source receives the register-stop message, it stops sending the register packets (unicast) towards RP and clears the registering flag against the (S,G) entry.

rp-register-stop

 

Few points to remember here:

a.      Any multicast packet received on a router has to go through RPF check before being forwarded to the OIL (Outgoing Interface List) of the (S,G) table.

b.      In PIM Sparse mode implementation, for each (S,G) there has to be a corresponding parent (*,G). In other words if a (S,G) has to be created for a multicast group  e.g 226.100.100.100 then router checks for (*,226.100.100.100) entry in its multicast table first. If not available it creates one as parent entry and then (S,226.100.100.100) as its child.

[Only exception is IGMPv3 or Source Specific Multicast (SSM) where receiver directly asks to join the source.]

c.      The (S,G) join message is a unicast packet from Source connected router (first hop DR) to RP. Hence it is only known to the first hop DR and RP. This creates (S,G) entries in them. But if there are no receivers in that group then neither (*,G) nor (S,G) will be seen in the intermediate PIM neighbors in the path from Source router to RP.

d.      The SPT switch over from the shared tree is always initiated by the receiver end router (last hop DR) when the SPT-threshold is reached. By default on Cisco routers have the SPT-threshold set to zero. This triggers SPT immediately when it receives the packets on the shared tree.

e.      All PIM join/prune messages are sent to common multicast address 224.0.0.13. This packet contains all required information inside the ‘PIM option’ field.

pim-join-prune

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s