cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
993
Views
4
Helpful
12
Replies

AutoRP operation and scope

Mitrixsen
Level 1
Level 1

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

Mitrixsen_0-1742816076851.png

I understand the discovery process, so to sum it up, the configured RP canditate announces itself by sending traffic to 224.0.1.39.

Mitrixsen_1-1742816093634.png

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:

Mitrixsen_2-1742816140803.png

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

2 Accepted Solutions

Accepted Solutions

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.

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

View solution in original post

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.

View solution in original post

12 Replies 12

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


 

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

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.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/imc-pim-xe-3e/imc_autorp.pdf

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.

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

Hello @Harold Ritter 

Thank you for the response. When I was studying about AutoRP today, my study resource mentioned the following:

listeenr.png

So AutoRP uses Dense mode only if the Listener feature is enabled or the Sparse-Dense PIM mode is configured?

Thank you!
David

Hi @Mitrixsen ,

AutoRP uses dense mode always. To make it work properly you need to either configure sparse-dense mode or auto rp listener.

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

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.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

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.

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?

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.

I understand, thank you for explaining this. I've received a ton of great answers regarding multicast here.

Harold Ritter
Spotlight
Spotlight

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.

Regards,
Harold Ritter, CCIE #4168 (EI, SP)