Notable Replies

  1. Hi Benjamin,

    The PIM join starts at the bottom and works it way up the tree:

    This is the RPT (Root Path Tree) towards the RP.

    The bottom router receives an IGMP membership so it will send a PIM join.

    Once this has been established, we might switch to the SPT (Shortest Path Tree). The router that is switching to the SPT will send a PIM join towards the source…

    The source IP is indeed learned by looking at the IP header.


  2. 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:

    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 I will let Rene know. Thank you!

    I hope this has been helpful!


  3. Hi Laz,

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


  4. 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!


Continue the discussion forum.networklessons.com

40 more replies!