Multicast PIM Sparse Mode

Hello:
Why would R3 do the switchover to RPT?. R3 is only one hop to the RP and 2 hops to the source.
thanks

Hello Ram

It seems to me that Rene is stating the R3 has joined the SPT and not the RPT and that it is indeed forwarding traffic on its Ge0/2 interface, that is, the interface connected to H3 which is participating in the multicast group.

However, Rene does mention that it is possible to disable SPT and have all multicast traffic go through the RP. This of course is not an ideal multicast configuration and should not be implemented under normal circumstances, but it is included here for the purpose of learning and understanding.

I hope this has been helpful!

Laz

Why is destination for PIM join is 224.0.0.13 (all routers) and not directly to RP - 2.2.2.2. If R3 and R2 were not connected directly, how would the join go to RP in that case from R3? Would it be flooded to all PIM neighbors and eventually reach R2?

Hi Rene and Team,

I am new and excited to be in this Forum, its plain english as mentioned in the site and easy to understand Thanks Rene and Team.

I have questions

  1. I am confised with Incoming interface and Outgoing interface list before sending traffic. But i am clear about this after sending the traffic. Can you explain it ?
  2. Can i know for what reasons i am not able to see the tunnels in gns3 lab after configuring pim sparse-mode and rp address ?
    Even i don’t have option to check tunnel (‘show ip pim tunnel’) instead i have ‘show ip pim mdt’
  3. When Join/Prune is sending why Holdtime is 210 …Can you please explain this…

Look like one small print mistake ie.,
After sending traffic to the group 239.3.3.3 (S1#ping 239.3.3.3 repeat 1000), R2 produces a lot of debug information their Multicast group address mentioned as ‘192.3.3.3’ instead ‘239.3.3.3’.
Please update this.

Hello Priya

The PIM join is always issued to the ALL-PIM routers multicast address. This is because a host does not learn about the RP as an entity and thus cannot communicate directly with the RP. It is only the multicast routers that know where to find the RP.

The join would eventually go to the RP because join messages, like most multicast PIM messages, are multicast with TTL 1 to the ‘ALL-PIM-ROUTERS’ group and each participating router will retransmit this, once again with a TTL of 1 until all routers have received the information.

I hope this has been helpful!

Laz

Hello Nani

Great to have you here! We’re happy that you find the forum and Rene’s lessons helpful in your studies!

In the output of the show ip mroute command, you will see various multicast address groups that exist within the mroute table. For each of these, there is a single incoming interface. All multicast traffic that a router will route will only come from a single interface. If any packets from that particular multicast group arrive on another interface, they will be discarded. If there is currently multicast traffic being routed, the incoming interface will be populated. If not, it will be Null.

The outgoing interface list shows the list of interfaces from which multicast traffic will be sent. These interfaces depend on the hosts that have registered to that particular multicast group. If they are currently sending multicast traffic, you will see two times separated by a slash. The first is how long the entry has been in the IP multicast routing table, and the second is when the entry will be removed from the IP multicast routing table. If there is no traffic, you will see “stopped” after the slash.

More information about this output can be found here:
https://www.cisco.com/c/en/us/td/docs/ios/12_2/switch/command/reference/fswtch_r/xrfscmd6.html

Concerning the specific implementation on the GNS3 lab, we’ll need a little more information to determine the specific problem. However you can check your IOS version against that in the following documentation for that specific command:

The default J/P holdtime is indeed 210 seconds while the default PIM hello packet holdtime is 105, so this is correct.

Yes you are correct. This should be 239.3.3.3. I will let Rene know. Thank you!

I hope this has been helpful!

Laz

Hi Laz,

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

Nani

1 Like

Hello,

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

Many thanks,
Stefanita

Hello Stefanita,

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

Rene

1 Like

Rene,

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 ?

Regards
KN

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 239.1.2.3 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:
image

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!

Laz

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.

Mike

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!

Laz

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 (1.1.1.1, 239.1.1.1) AND I will also see (,239.1.1.1). The (,239.1.1.1) 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 (*,239.1.1.1) 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 224.0.1.40, so you will se an entry like (*, 224.0.1.40) 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 239.1.1.1

(*, 239.1.1.1), 00:00:19/00:02:51, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  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 *, 239.1.1.1 entry for multicast group 239.1.1.1. 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 (192.168.1.1, 239.1.1.1).

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!

Laz

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 192.168.1.1 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 192.168.1.1 as the unicast routing table on R4 has next hop interface towards R1 for 192.168.10 ? Or am I missing something?

Thanks,
M

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!

Laz

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.”


Thanks,
Madhu.

Hello Madhu

Yes, that’s absolutely right!

I’m glad this was helpful!

Laz

2 Likes

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