Multicast PIM Sparse Mode


(Lazaros Agapides) #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


(Dhananjay P) #22

@lagapides @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?


(Rene Molenaar) #23

Hi Dhananjay,

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

Rene


(Dhananjay P) #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?


(Rene Molenaar) #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:


(Alexander F) #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”


(Lazaros Agapides) #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


(Vinod A) #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


(Ram S) #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


(Lazaros Agapides) #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


(Priya L) #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?


(Nani M) #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.


(Lazaros Agapides) #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


(Lazaros Agapides) #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


(Nani M) #35

Hi Laz,

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

Nani


(Staut S) #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