03-24-2025 04:36 AM
Hello, everyone.
I've just started AutoRP and realized that I don't understand it at all. I'll use this diagram from NetworkLessons.com
I understand the discovery process, so to sum it up, the configured RP canditate announces itself by sending traffic to 224.0.1.39.
Then the mapping agent makes the big decision and tells the others who the RP is by sending the traffic to 224.0.1.40.
However, there is a problem. These multicast entries and autoRP in general operate under dense mode, correct? So they will be flooded out. However, the MA isn't directly connected to R2 or R6. And since R1, R5, and R4 operate under sparse mode, they won't forward this mapping out because they haven't received a PIM join from R6 or R2.
What confuses me is the following:
Won't every router have an entry like this once multicast routing is enabled on them? It has a D flag which represents Dense mode. So why cannot they just flood traffic going to 224.0.1.40? The MA has the same entry and it can flood traffic easily but these other routers refuse to do so. Why do we need to configure AutoRP Listener or other features to make this work?
Thank you.
David
Solved! Go to Solution.
03-24-2025 08:48 AM - edited 03-24-2025 08:58 AM
Hi @Mitrixsen ,
> The RP mapping agent then sends the consistent group-to-RP mappings to all other devices by way of dense > mode flooding.
This can only happen if the interfaces are configured as sparse-dense-mode on the mapping agent or if "ip pim autorp listener" is configured.
"ip pim autorp listener" is definitely the preferred way to deploy auto-rp, as it removes the need for dense mode from the entire network.
03-24-2025 11:33 AM
Dave, BTW, what I was trying to lead you to, those multicast address blocks are "special" as are the specific two multicast addresses you noted.
The importance of this, is network devices may not follow the usual rules and/or do things in a special way. For example, PIM DM might be used without the need for you to explicitly define it. Understand, I'm not saying what's is, or isn't, required, I'm just trying to get you to keep in mind, an open mind, whenever dealing with control protocols, they might not follow the usual rules.
03-24-2025 06:18 AM
Hello
@Mitrixsen wrote:
These multicast entries and autoRP in general operate under dense mode
Dense mode doesn't utilise any RP its a flood and learn MC type, meaning it just floods out MC throughout the network and any rtr that doesn't have an interested mc receiver attached will prune itself from the MC tree, AutoRP is Cisco's own proprietary discovery of a RP feature utilised in pim-sparse mode
03-24-2025 07:57 AM
Hello.
Is this incorrect, then?
To make Auto-RP work, a device must be designated as 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 devices by way of dense mode flooding.
03-24-2025 08:48 AM - edited 03-24-2025 08:58 AM
Hi @Mitrixsen ,
> The RP mapping agent then sends the consistent group-to-RP mappings to all other devices by way of dense > mode flooding.
This can only happen if the interfaces are configured as sparse-dense-mode on the mapping agent or if "ip pim autorp listener" is configured.
"ip pim autorp listener" is definitely the preferred way to deploy auto-rp, as it removes the need for dense mode from the entire network.
03-24-2025 09:03 AM
Hello @Harold Ritter
Thank you for the response. When I was studying about AutoRP today, my study resource mentioned the following:
So AutoRP uses Dense mode only if the Listener feature is enabled or the Sparse-Dense PIM mode is configured?
Thank you!
David
03-24-2025 09:20 AM
Hi @Mitrixsen ,
AutoRP uses dense mode always. To make it work properly you need to either configure sparse-dense mode or auto rp listener.
03-24-2025 10:13 AM
Hello
actually my explanation was lacking clarity- what i ment to say was when pim dense mode is only enabled then it has no requirement for any RP -however what i didn't mention that @Harold Ritter stated was the use for it when you have pim sparse -dense mode enabled as/when you do wish to incorporate RP and the auto discovery them.
03-24-2025 07:17 AM
Possibly your confusion is you're overlooking the actual multicast addresses being used.
If the forgoing isn't enough of a hint, consider the destination addresses used by an OSPF DR router.
03-24-2025 08:02 AM
The only difference between an IP used by an OSPF DR router and an IP used by PIM here that I can think of is that they are from different multicast ranges. OSPF uses the 224.0.0.5, 224.0.0.6 IPs from the local network range (224.0.0.0/24) which has a local-segment scope while PIM (AutoRP) here uses an IP from the 224.0.1.0/24 range.
03-24-2025 08:56 AM
True, they are from different /24 address range blocks but not what I'm trying to lead you to.
Another hint, consider UDP/TCP port numbers. One port number is the same as any other, right? But any special significance to the low end range of port numbers?
Likewise, any special significance of multicast address blocks 224.0.0.0/24 or 224.0.1.0/24?
Last hint, any special significance to 192.168.0.0/16, both for Classful and Classless IP?
03-24-2025 11:33 AM
Dave, BTW, what I was trying to lead you to, those multicast address blocks are "special" as are the specific two multicast addresses you noted.
The importance of this, is network devices may not follow the usual rules and/or do things in a special way. For example, PIM DM might be used without the need for you to explicitly define it. Understand, I'm not saying what's is, or isn't, required, I'm just trying to get you to keep in mind, an open mind, whenever dealing with control protocols, they might not follow the usual rules.
03-27-2025 02:28 AM
I understand, thank you for explaining this. I've received a ton of great answers regarding multicast here.
03-24-2025 09:34 AM - edited 03-24-2025 09:41 AM
Hi @Mitrixsen ,
Just one comment about the (*,G) you referred to in your original post. To refer back to a question you posted a couple of days ago, where you ask why we had a (*,G) entry in the context of dense mode if only the (S,G) is used in this context. The answer to that question was that the (*,G) was there for implementation consistency, but that it is not used for traffic forwarding.
The same would apply in this case.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide