PIM Register – There is a Source, but no Clients

In the previous article in this series, I examined the process of the source registration in PIM. We reached the point when RIp is aware of the existence of the source. I identified three possible scenarios at this point. Today, we’re going to examine scenario in which the source is registered, but there are no clients interested in receiving this traffic.To continue the examination of the PIM source registration process, we’ll use the following diagram, which is identical to the Figure 1 used in the previous article.

We left off our analysis at the point in time in which source is registered with the RP, as show on the diagram below.

At this point in time, source has not yet joined the the group, which means that RP is not aware it even exists. Since this is the case, multicast traffic encapsulated as unicast sent by FHR and processed by RP is unnecessary. RP will immediately start dropping this traffic and send unicast response back to FHR to stop sending it. This is so-called “PIM Register Stop”.

When FHR receives this message, it will immediately stop unicasting received multicast traffic to RP and start dropping it. Let’s examine this on a diagram.

Let’s examine the picture in some detail.

1. At this point, RP realizes that there are no directly nor indirectly connected clients willing to receive the traffic sent to group G. It immediately drops all packets, however (S, G) state is preserved on the RP.
2. Unicast message is sent to FHR to stop registration packets.
3. FHR stops the registration process and immediately starts dropping incoming packets from the source. Re-registration timer starts counting down from 180 seconds (3 minutes).
4. Source, SRC, is unaware of anything going on and it happily keeps on sending multicast traffic to FHR only to have it dropped there.

I would like to point out one item in step #3: the re-registration timer. As long as source keeps transmitting, registration process will repeat every three minutes. The reason behind this is the need to maintain RP informed about the presence of the source. If the source stops transmitting in the interim, both FHR and RP will lose their (S, G) states.

What happens when the client finally joins? Let’s take a look. I will start this explanation with a picture and talk through it.

1. While the source keep sending, client joins group G using IGMP.
2. Client’t membership report will cause DR (and all other PIM routers on the segment) to create local (*, G) state, with client-facing interface in outgoing interface list (olist) for (*, G).
3. DR generates PIM join for (*, G) group and send it towards the known RP address for the group G.
4. Since RP has (S, G) entry and by virtue of multicast rules associated (*, G) entry in it’s table, it will add interface downstream to DR to outgoing interface list (olist) for this (S, G). RP forwards (S, G) join towards the source, SRC.
5. FHR receives the join from RP and adds interface downstream to RP to the olist for (S, G). It stops dropping incoming multicast traffic sent by SRC and forwards it out from all the interfaces in “olist” for (S, G).
6. RP now receives the traffic from SRC and it sends it out all the interfaces in the “olist” for (S, G).
7. DR now receives the traffic and forwards the traffic out all the interfaces in olist for (*, G), which has the effect of client CLI receiving the traffic sent by SRC.

Next time, we’ll take a look into what happens when clients join and there are no sources.

Happy studies!

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Print Friendly

Tags: CCIE, CCIE R&S, CCIE R&S Training, multicast, pim register