Multicast PIM Sparse Mode

thank you now i got it

1 Like

hello.

i think Multicast PIM Sparse Prune Packet cloudshark link points to the wrong capture file

Hello Thomas

Yes, it seems you are right. It is a prune packet, but the addresses are different. I will let Rene know to take a look and make modifications.

Thanks!

Laz

Hi,
Recently I added a new L3 switch to an existing ring of L3 switches all of which are running multicast routing.
There is no igpā€™s running anywhere and all switches are just running ā€œip routingā€ as their means of routing between Sviā€™s.
This is all well and good.
So I created Sviā€™s for the vlans on the new switch in the same subnets (obviously) as the ones that exist on the switches there already.
But then this morning I noticed a strange item in the config.
When I run show ip int brief I now have a Tunnel0 interface showing the ip of one of the Sviā€™s.
When I do show int Tunnel0 it shows "Description: pim register tunnel (encap) for rp " and then the RP address.
I didnā€™t create this tunnel and didnā€™t create this description so it looks like this was done automatically by the ios.
This is really strange to me.
The ios is Xe 16.09.04
I was wondering if anyone has came across this issue before or knows how it was created or what its for.

Hello Sean

This is normal behaviour whenever a Rendevous Point (RP) is used in multicast. PIM Sparse mode uses the function of an RP to operate. If sparse mode is configured somewhere, then AutoRP by default will operate, creating a tunnel between each multicast router (your L3 switches) and the RP. More details about this tunnel can be found in the Rendezvous Point section of the following lesson (link takes you to the section):

I hope this has been helpful!

Laz

Hi,

In the RP config I noticed at some other blogs, the loopback also has PIM sparse mode enabled. It is not abled in this lesson when discussing the static RP. When do we enable the ā€˜ip pim sparse-modeā€™ under RP and when do we dont ? I see when you discussed Auto-RP and BSR you have it enabled. What makes static RP different in this case ?

Thanks
Krishh

Hello Krishh

As stated in the lesson:

You need to enable PIM on all interfaces that will send or receive multicast traffic. Including the interfaces that connects to sources and receivers.

Now that being said, there is a case where you must enable this command on a loopback interface, and that is when using auto RP. The mapping agent needs the ip pim sparse-mode on its loopback interface in order to process advertisements from candidate RPs. In the following lesson about Auto RP, you can see how this command was enabled on the loopback interface of the mapping agent:

I hope this has been helpful!

Laz

Hi Rene,
Could you clarify in what situations RPF nbr will show 0.0.0.0 when looking at the Multicast routing table? Sometimes I see it for the RPT entries and sometimes for the SPT entries.

Looking at the output on R2 (RP) all the (*, G) RPT entries show RPF nbr 0.0.0.0. Is that to imply ā€˜the RP is me?ā€™ or directly connected?

Likewise on R1, the (S,G) SPT entry shows RPF nbr 0.0.0.0. Is that because the source is directly connected?

Thanks

Hello Bhawandeep

In the multicast routing table, whenever the Incoming Interface is Null, the RPF nbr is 0.0.0.0. This is because there is no incoming traffic for this group, therefore there is no RPF neighbor.

However, when the Incoming Interface is not Null and the RPF nbr is 0.0.0.0, this does indeed mean that the source is directly connected. When RPF nbr is not 0.0.0.0, it tells us from which router the incoming multicast packets are coming.

I hope this has been helpful!

Laz

1 Like

Thanks Laz. Makes sense.

1 Like

Hello!
Can anyone give me more information on the ip pim rp-address override command?
It seems that specify a specific group to be overriden in order to use a specific RP.
Is that correct.
Has anything been written about this topic with examples.
I started here so hopefully i have a little more info by the time i get a response.
Thanks,

Hello James

The ip pim rp-address command is used to statically configure the address of the PIM RP. However, it is possible to dynamically configure an RP. This can be done using various discovery protocols, such as Auto-RP and PIMv2 Bootstrap router (BSR).

If you have configured both a static RP on the local router, but dynamic RP discovery is also configured, then by default, the dynamically learned RP will take precedence over any statically configured RP.

Now the override keyword used in this command specifies that the statically configured RP will take precedence over any dynamically learned RP.

More info about this command can be found here:

I hope this has been helpful!

Laz

Hi, Rene.

Is ip pim spt-threshold 0 have to put to R4 in your example in order to get the multicasting always join SPT?
Thank you!

Hello Pui Lai

The command ip pim spt-threshold 0 is actually the default setting. So by default, the switch from the RPT to the SPT will happen almost immediately after the first data packet arrives at the last hop router. So this command is not needed unless you have changed it beforehand and you want to return to the default.

For more information about this particular command, take a look at this Cisco documentation:

I hope this has been helpful!

Laz

Hello all!
I would like to understand the logic of the ASM sparse-mode if there are several sources for one group from the very beginning. From the moment the source is registered until the stream/streams are received by the client. Please explain me)
Thank you!

Hello Georgiy

When employing PIM sparse-mode, it is possible to have several sources as well as several receivers for a single multicast group. This simply means that you will have multiple Root Path Trees in your network.

You can see how this works in detail by looking at the following lesson:

After going over this lesson, if you have any further more specific questions, feel free to ask!

I hope this has been helpful!

Laz

Hello Lazaros.
I ridden this topic and my question is more specific.Iā€™m only talking about ASM.and without diverse ACL.
Situation 1: We have 2 mcast sources with different IP addresses and FHR is one(src mcast directly connected to FHR via different links) and with the same groups.
rpf-check pass both sources. FHR send PIM registration for both mcast sources because diff (S,G), right? When RP receives PIM join those groups to the LHR send both flows? And LHR send to the end client both flow? How end client distinguish between streams if he sends IGMP join (*, G)?

Situation 2: We have 2 mcast sources with different IP addresses and FHR is one(src mcast directly connected to FHR via one link) and with the same groups.
rpf-check pass both sources. FHR send PIM registration for both mcast sources because diff (S, G), right?

Situation 3: We have 2 mcast sources with the same IP address and FHR is one(src mcast directly connected to FHR via one link) and with the same groups.
rpf-check pass. What will do FHR? I understand correctly that there will be an incomprehensible hodgepodge of traffic and, as a result, multicast will not work normally?

Situation 4: We have 2 mcast sources with the same IP address and FHR is one(src mcast directly connected to FHR via different links) and with the same groups.
rpf-check pass(ECMP). What will do FHR?

Is the two PIM neighbours know what mode they are running? Like sparse mode or dense mode?
I dont see anything in the hello message indicating whether they share this information with each other or not.

Hello Georgiy

Just a clarification, when you use the term Any-Source Multicast (ASM), we are actually talking about PIM sparse or PIM dense mode without the use of source-specific multicast (SSM). More info on this can be found at the NetworkLessons note on Any Source Multicast.

Situation 1. Because (*,G) is being used, the client will receive traffic from both sources even though theyā€™re only interested in the traffic from one of the two sources. It will keep the traffic it wants but will discard the traffic from the other source. How does it distinguish between them? The source IP address. ASM may not be able to distinguish between multicast traffic sources that a particular receiver may want (thatā€™s why traffic from both servers arrives at the receiver), but the receiver itself does know what it wants and what it doesnā€™t.

Situation 2. In this case, if youā€™re using (S,G), then you are using SSM, therefore a receiver can indicate from which source it wants traffic and from which it does not. SSM will deliver only the desired traffic.

As for situations 3 and 4, Iā€™m not sure I understand them, as they seem to be the same as the previous situations. Can you clarify?

I hope this has been helpful!

Laz

Hello Muhammad

PIM neighbors do not exchange information concerning whether they are using dense or sparse mode. These are parameters that are set on each participating multicast interface of a router, and each such interface functions independantly. In this sense, PIM is a stateless protocol, where there is no confirmation of the state in which a particular router is operating. This means that the onus is on the administrator to make sure that the correct mode is applied to the correct interfaces.

I hope this has been helpful!

Laz