Multicast PIM Sparse Mode

Lessons Discussion
21

Hello Victoria.

If a router has no PIM neighbors, it cannot inform upstream neighbors about particular groups and sources. This means that multicast messages will not be processed by such a router.

I hope this has been helpful!

Laz

22

@lagapidis @ReneMolenaar can you explain why this PIM Register process is required i.e. why first packet is encapsulated in unicast and sent by DR to RP?

I am not able to understand the need for PIM Register process, I think I understand how it works.

Also, when DR receives packets from source, I thought they will be received continuously by the DR, then how is it able to identify and encapsulate only the first packet from the stream? and what happens to the remaining packets? are they buffered on the DR until the RP responds with a message that there are interested receivers?

23

Hi Dhananjay,

Have you seen this lesson? I explain it in detail here:

Rene

24

@ReneMolenaar thanks, it makes much more sense now, however, do you know what happens to the remainder of the packets being sent from the multicast source? i.e. the DR encapsulates the first packet that it receives from the multicast source and starts the PIM Register process towards the RP, what happens to the remainder of the packets being received continuously towards the DR until then? are they simply discarded by the DR until the registration process is complete or buffered by the DR?

25

Hi Dhananjay,

These are probably dropped. RFC 4601 describes the PIM register messages / process in quite some detail but they don’t really mention what happens with the data packets during the process. However, with most multicast processes, when the “state” isn’t right (yet), traffic gets dropped.

I guess you could test this if you want. Configure a small PIM sparse network, then send exactly 10 ICMP requests and see how many you receive on the other end :smiley:

26

Thanks so much for the content, preparing for certification and real life was never easier!

Please update the topology pic(above video), as Interfaces for R2 are named wrong.

Am i correct with the flag understanding:
T = fully joined and receiving multicast via SPT instead of RPT
J = quote Cisco “SPT-bit set”, understanding “I(Router) want to join SPT for my connected destinations”
F = quote Cisco “Register Flag”, understanding “I(Router) will join SPT for my connected sources”

27

Hello Alexander

The image you are talking about is this one:
image
Thanks for catching that, I’ll let @ReneMolenaar know to change that…

As for the flags, yes your understanding is correct.

Thanks again for catching that.

Laz

1 Like
28

Hi Rene ,I followed the Lab and see for sh ip mroute for R1 and R4 both of them

I see ,for R1 ,its has two port showing in forward and sparse where as in R4 ,i can only see one port in forward and sparse.

Topology are similar both end.

Thanks
Vinod

29

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

30

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

31

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?

32

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.

33

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

34

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

35

Hi Laz,

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

Nani

1 Like
36

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

37

Hello Stefanita,

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

Rene

1 Like
38

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

39

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

40

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