Multicast PIM Sparse-Dense Mode

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hi Rene.
Thank for great explain, How ever i still confuse. Can you explain what is RP mapping agent ? and why we need it ?
Thank
Sovandara

3

Hello Heng

In the first version of PIM-SM, all routers were required to be manually configured with the IP address of the RP. This does not scale well for a large complex network.

After this, Cisco implemented the Auto-RP feature which automates the distribution of group-to-RP mappings in a PIM network. To make Auto-RP work, there must be an RP mapping agent which receives the RP announcement messages from the RPs and arbitrates conflicts. The RP mapping agent then sends the consistent group to RP mappings to all other routers by dense mode flooding. This way, all routers automatically discover which RP to use for the groups they support.

I hope this has been helpful!

Laz

2 Likes
4

I have a very basic topology of router on a stick so two VLANS (10 and 20) can communicate. What type of multicasting (SPARSE / DENSE) should I configure on my router (C2900 V15.2) to enable a server in one VLAN (VLAN 10) to send multicast traffic to devices in its own VLAN and devices in the other VLAN (VLAN 20) - that is connected via Router on a stick (sub – interfaces)

5

Hello Jason

If your topology only consists of a single router with two VLANs, then DENSE mode would be preferable. Arguably, this is the simplest mechanism as it doesn’t require an RP (since you only have one router). In such a case, dense mode forwards multicast traffic on all interfaces until we are requested to stop forwarding. For more info on dense mode, take a look at the following:

I hope this has been helpful!

Laz

1 Like
6

Hello, is the ip pim autorp listener command only needed in one adj PIM router or Do I needed it everywhere in order to get the RP?

7

Hello Joshua

It depends on your topology. In the following lesson, near the end, you will see an example of the use of this command. In the specific topology a mapping agent is used, and it was only necessary to enable this command on a specific router in order to get the topology to function.

This command should only be enabled on routers that may be blocking traffic from the 224.0.1.39 and 224.0.1.40 addresses due to PIM sparse mode. I believe that the above lesson will further clarify this situation.

I hope this has been helpful!

Laz

8

Hello Lazaros,

I was wondering about use of the command ip pim autorp listener on a bigger topology. Is it needed everywhere or it is just needed on adj routers?

9

Hello Joshua

The command should be implemented on routers configured in sparse mode, for which you want the flooding of the Auto-RP groups. If you require this for your whole network, then yes, you would implement everywhere.

I hope this has been helpful!

Laz

10

Hi Rene/laz,

i see this lesson has both the ‘‘startup config’’ at the beginning and the solution config at the end. very good idea, because in previous lessons, i had to determine which was the startup and which was the solution config. i am in multicast now, i am not sure if its the same as from here onwards?

regards

11

Hello Walter,

Nowadays, I usually add a “startup” config at the beginning when I show the topology and a “final” config at the end. When there is only one config, it’s the final config and at the bottom.

I add the startup configs so if you want to replicate this, you don’t have to worry about configuring basic requirements like IP addresses or routing. I will make a change though. For the startup configs I always added this line:

  • Want to take a look for yourself? Here you will find the startup configuration of each device.

And for the final configs:

  • Want to take a look for yourself? Here you will find the configuration of each device.

I’ll change the final config line to “Here you will find the final configuration of each device” so there is no doubt.

I hope this helps, if you see anything that is confusing, let us know and we’ll fix it!

Rene

2 Likes
12

Thanks Rene, so far the only startup config i saw was in one of the multicast lessons, other than that the previous lessons in the ENCORE course only have final configurations, I have have to always work out and try to figure which is the startup and final when i copy and paste into my gns3 topology

13

for e.g in the Multicast PIM Auto RP course, there is only final configs included with a lot of other courses, i hope you understand what i mean or maybe there is something not right with my web pages not display the startup configs for each course in the beginning.

image
image1009×219 9.64 KB

14

Hello Walter

The newer lessons that Rene creates will have both startup and final configs, and will be marked as such with the statement referring to “startup configuration” and “final configuration”. Some of the older lessons don’t have both startup and final, so for those you’ll have to work through what should be there in each case.

For the Multicast PIM Auto RP course, only the final configs are included, since it is one of the older lessons. However, over time these lessons may be updated as well. We’ll let you know.

Thanks for pointing it out!

Laz

2 Likes
15

Hello Rene,

Can you please explain what does the “scope 5” mean in the command ip pim send-rp-announce loopback 0 scope 5.
Also what would an actual end host not a Cisco router as simulated in these lessons do to join a multicast group ?

Thanks

16

Hello Amar

The scope keyword in the command is used to specify the time to live (TTL) value in the IP header of the Auto-RP discovery messages. The value used here should be large enough to ensure that the discovery messages will reach all of the routers within your PIM domain. But it should be small enough to prevent the unnecessary relaying and retransmitting of the discovery messages.

More information about this command can be found here:

I hope this has been helpful!

Laz

1 Like
18

I was going through this lesson https://networklessons.com/multicast/multicast-pim-sparse-dense-mode# and in section 1.2 I decided instead of using another device I could maybe use a svi interface and make it look I was pinging from somewhere(source-interface?) else just to test basic functionality.

S1#ping 239.1.1.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.3.101, 23 ms

except on the n3k nx-os platform the ping failed:
ping: either multicast replicate flag or source interface needs to be specified
Any idea how to go about this. It seems to get wonky with other ping options too.

1 Like
19

Hello Alex

It seems that the ping functionality in a Nexus device works a bit differently than in an IOS device. When you ping to a multicast address in IOS, it simply knows what to do. It sets the replication flag automatically and chooses the appropriate parameters to make the multicast ping work.

For Nexus devices, you must specify some of these parameters. In particular, if you do an extended ping on a nexus device, you can choose the source interface, which should result in a successful ping. In addition, some others have found that an extended ping in a nexus device with all default parameters will actually work as well. It seems that the replication flag is automatically set in such a case. Take a look at these Cisco community posts for more information:

Alternatively, you can use the ping multicast command about which you can find out more here:

This NetworkLessons note on using multicast ping on a Nexus device may also be helpful.

I hope this has been helpful!

Laz

20

Hello,

Thanks for lesson. I have a question though:

image

This sound good but… when we configure the mapping of the RP with the multicast group range, and we don’t use a group-list to specify an address, the the entire range of 224.0.0.0/4 is included, as stated in the lesson:

image
image421×118 2.64 KB

So that means that the 224.0.1.39 and 239.0.1.40 ranges are also included, and therefore they will have an RP, and therefore, their traffic will be forwarded in Sparse-mode?

As expected, this does not happen in practice, so I wanted to understand why. Is it because the mapping excludes this 2 multicast addresses? Or is it because this 2 multicast addresses can never be assigned an RP? Or because the command ip pim sparse-dense-mode does its magic similar to how the ip pim autorp listener command does, and the router knows that interfaces with this command should forward multicast traffic for 224.0.1.39 and .40 always on dense mode?

Thanks,
Jose

21

Hello Jose

That’s an excellent question and it shows that you’re thinking analytically…

Indeed, when you enable the RP functionality on R1, it does include the entire range of multicast addresses. However, as you have seen from your experimentation, some addresses, like 224.0.1.39 and .40, are exempt. Why? These groups must be flooded using dense mode to inform the whole topology of the existence of an RP. They can’t use an RP if the whole topology does not yet know about the RP. It’s kind of a chicken-and-egg scenario.

So by definition, these addresses are exempt from sparse mode behavior. They’re flooded by definition so that the whole topology can learn about the RP. you don’t have to configure this, it is something that happens behind the scenes.

I hope this has been helpful!

Laz

1 Like