Multicast PIM Sparse Mode

Hi Laz,

Thanks for your in details explanations for each question. Yes it is helpful.


1 Like


I believe the “multicast-pim-sparse-join.pcapng” and the print screen should display the group, not the

Many thanks,

Hello Stefanita,

You are right, I just replaced the capture file and screenshot. Thanks!


1 Like


My question is regarding the PIM-SM Null Register packet (Null-Register bit set), per the document it stated the difference between initial Register message and second Register message is Null-Register bit set and without any encapsulated multicast packet.

I compared both the packets, the only difference I can see is, initial Register message have ICMP payload and second Register doesn’t have ICMP payload both having encapsulated multicast packet.

If my understanding is correct both contain encapsulated packet and only difference is first packet contains payload and second doesn’t. Is that correct ?


Hello Karthik

A PIM Register message will take the first multicast packet, encapsulate it within a PIM register message and send it to the RP. If you look at the payload of that PIM register, as you have done, you will see that it is a multicast packet inside of the register. Now what is actually inside that multicast packet can be anything. It can be an ICMP packet, or it can be a TCP segment of a video being sent. What’s in there depends on what actual information was being sent by the multicast communication. In the example that you looked at, it was an ICMP packet.

If you look at this packet capture, you will see a PIM register, and a register stop packet. Inside the PIM register packet, you will find a multicast packet, and inside that an ICMP packet. This is because someone initiated a ping to to get the PIM register sent. It just happens that the payload is ICMP in this case. Here’s a screenshot that shows this information:

Now a Null Register message will contain information about group addresses and source addresses within the payload itself. You can see this more clearly in the format that is described in this IETF document describing the PIM Null register packet.

In essence, yes, you are correct, both contain an encapsulated packet, it’s just that in the second case, the payload itself is the information found within the fields of the PIM Null register packet.

I hope this has been helpful!


Hi All,

I’m getting a bit confused by some outputs on the show ip mroute command.

When i have a multicast source trying to join a group, the router connected to the host shows an entry in the form of (*,G).

But I’m also reading PIM Sparse mode uses Shared Tree format of (*,G), where * is a wilcard mask meaning all sources.

I’m confused as to when the (*,G) entry is being used as IGMP v2 join or Shared Tree entry.

thanks in advance for any anwsers. Mutlicast takes some learning.


Hello Michael

An excellent explanation of these notations can be found at the following link:

Note here that the (S, G) notation is used to refer to the shortest path tree (SPT) distribution tree. This is when no single shared root of the tree is being used. In other words, this is when no Rendevous Point (RP) is being used.

Whenever an RP is being used, then the notation changes to (,G), which refers to the fact that a Shared Distribution Tree (SDT) is being used. The (,G) notation always refers to this.

I hope this has been helpful!


Thanks for the reponse Laz, I understand the difference between SDT & SPT but here’s where I get confused:

Even when running PIM dense mode with no RP, when I issue ‘show ip mroute’ I will see (, AND I will also see (, The (, will be for a device that has registered via IGMP to receive that multicast group. In this instance it doesnt have any link to sparse mode and RP as it is an IGMP join message.

So when is it used by IGMP join and then PIM Sparse mode as SDT? I’m confused by the notation (*, and its meaning when used by PIM Sparse RP and IGMP join.

I understand that for PIM Sparse RP the format is a wildcard for sources, but it is confusing that it is also used for IGMP join.

Hello Michael

Thanks for the clarification of your question. If you take a look at this lesson, you will see that Rene deals specifically with this question.

Under the section titled “Multicast Routing” he states that PIM dense mode doesn’t use an RP, but, Auto RP Discovery is enabled whenever you enable PIM and the router will listen to the Auto RP group address of, so you will se an entry like (*, even though an RP is not being used.

Now specifically for the join message, he mentions a little later on, the following:

R2#show ip mroute

(*,, 00:00:19/00:02:51, RP, flags: DC
  Incoming interface: Null, RPF nbr
  Outgoing interface list:
    GigabitEthernet0/3, Forward/Dense, 00:00:19/stopped
    GigabitEthernet0/2, Forward/Dense, 00:00:19/stopped
    GigabitEthernet0/1, Forward/Dense, 00:00:19/stopped

Above we can see that R2 has created an *, entry for multicast group At this moment however we are not receiving any traffic for this group so we don’t know what the source is and we can’t forward anything.

Now later on he generates multicast traffic and we can see that the routing table has changed to include the notation for SPT that we are familiar with such as (,

So the (*,G) notation for the join message in this context simply means that we are not receiving traffic for this group, and we simply don’t know the source of it yet.

I hope this has been helpful!


Hi Rene,
I have a question. In the example where you disable SPT joining on R4, it will start receiving the multicast traffic from source through R2 instead of the shortest route R1-R4. But going back to the earlier chapter’s concept of RPF check, will RPF check fail here on R4 when it receives multicast from as the unicast routing table on R4 has next hop interface towards R1 for 192.168.10 ? Or am I missing something?


Hello Madhu

This is an excellent question, and it shows that you are thinking critically and combining multiple concepts in your mind. If you take a look at the Multicast RPF (Reverse Path Forwarding) lesson, you will note that when the RPF check fails, it is because there is multicast traffic being received from an RPF neighbor that is not specified in the multicast routing table. Multicast traffic is received from IP address “X” when the RPF neighbor is actually “Y” in the multicast routing table.

In the example you are referring to, you will notice that you have two entries in the multicast routing table, one because R4 has joined the RTP, but also one because R4 has joined the STP specifically for traffic sourced from S1. This results in the following two scenarios:

  1. For multicast traffic coming from R2, any source will do, and since the IP address of R2 is in the multicast routing table, the RPF check will succeed.
  2. Similarly, for multicast traffic coming from R1 that is sourced from S1, this too will pass the RPF check because the IP address of R1 is in the multicast routing table (STP traffic) and the source IP is specified.

So in this scenario, the RPF check succeeds because the “RPF nbr” indicator in the routing table is satisfied.

I hope this has been helpful!


1 Like

Hi Laz,
Thank you for the detailed explanation. and I this I understand it now. In short, when we use RPT, the RPF check is for the RP address and in SPT the check is for source ip address of the multicast, is that right?

Looking at a cisco doc, it seems to say the same.
“All preceding sources of RPF data are searched for a match on the source IP address. When you use Shared Trees, the RP address is used instead of the source address.”


Hello Madhu

Yes, that’s absolutely right!

I’m glad this was helpful!



A post was merged into an existing topic: Multicast PIM Bootstrap (BSR)

A post was merged into an existing topic: Source Specific Multicast (SSM)

Hello Aymen

What you see in your output is normal behaviour. Whenever you enable sparse mode on an interface, an “invisible” tunnel interface is created that uses the same IP address as the interface on which the feature was enabled. In your case, tunnel0 is created which uses the same IP address as the loopback interface, since you enabled sparse mode on it.

These tunnel interfaces are created to encapsulate the first multicast packet in a PIM register message and to forward it to the RP. You will also see that the RP gets two tunnel interfaces, the second is used to decapsulate the PIM register packet it receives.

Now these tunnel interfaces cannot be seen in the regular configuration but they can be seen using the following command:

show ip pim tunnel

You should get something like this:

R1#show ip pim tunnel 
  Type       : PIM Encap
  RP         :
  Source     :
  State      : UP
  Last event : Created (00:00:22)

For the source as shown above, you should see the IP address of your loopback interface.

I hope this has been helpful!


1 Like


It seems show ip pim tunnel command is not available in 12.x version

R2#show ip pim tunnel
% Invalid input detected at '^' marker.

R2#show ip pim ?
  autorp      Global AutoRP information
  boundary    debug boundary command
  bsr-router  Bootstrap router (v2)
  interface   PIM interface information
  mdt         Multicast tunnel information
  neighbor    PIM neighbor information
  rp          PIM Rendezvous Point (RP) information
  rp-hash     RP to be chosen based on group selected
  vc          ATM VCs opened by PIM
  vrf         Select VPN Routing/Forwarding instance

Hello Syed

Yes, indeed, this command was introduced in Cisco IOS XE Everest 16.5.1a as seen in this command reference.


i’ve a few questions

  1. does the RP address have to be that of a loopback interface? what if, on both the RP and other routers, the RP is specified as the address of a real interface?
  2. can the RP ever be the first-hop-router? what about the last-hop-router? is any special configuration required to support these usages?

Hello Qiwei

No the address used for the RP can indeed be that of a physical interface. For example, in the following lesson you can see that the address used for the RP is that of the interface.

However, it is considered best practice to use the IP address of a loopback interface in order to avoid loss of an RP in the event that the physical interface goes down.

The RP can be any router in your multicast topology. Typically, however, it’s a good idea to keep the RP as centrally located as possible in your topology, because remember, all of your multicast traffic will flow through that router. If it is on the edge of your network, then all multicast traffic will have to travel to the RP and back. Keeping it close to the middle will make your multicast network more efficient.

I hope this has been helpful!


1 Like