Multicast: AutoRP and DM Fallback

omarmontes · ‎10-22-2009

Hi guys!

Trying to understand this features, correct me if im wrong in this:

If the AutoRP feature is enabled in a Sparse Mode only network, you should use AutoRP Listener so the 224.0.0.39 and 224.0.0.40 groups are able to work as Dense Groups.

But, if AutoRP is enabled in a Sparse-Dense network, you should use NO DM Fallback, not to make it work, but to avoid that other groups (besides .39 and .49) work in Dense mode. Is this right? if you configure no ip dm-fallback, would the AutorRP groups still work?

I've seen people configuring no "ip dm-fallback" in conjuction with "autorp listener", and I just dont see the point.

thanks in advance for any info!

Giuseppe Larosa · ‎10-22-2009

Hello Omar,

your understanding is correct

if you have ip pim sparse-dense-mode this helps to solve the startup problem of AutoRP:

that is how to allow AutoRP addresses that are 224.0.1.39 and 224.0.1.40 (notice 224.0.0.x are link local ) to allow to build dense-mode trees for these two groups.

Then, after AutoRP messages have been propagated to all routers all groups that have an RP

(you can check this with

sh ip pim rp mapping)

are treated as sparse mode.

if you have candidate RPs that cover the whole multicast address space the command

no ip pim dm-fallback

is not stricly needed unless you want to be sure that in any case even if all RP devices fail no dense-mode user groups exist.

see

http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_04.html#wp1013545

ip pim autorp-listener

this an alternate way to solve the problem of propagation in dense mode of groups 224.0.1.39 and 224.0.1.40

ip pim autorp listener

To cause IP multicast traffic for the two Auto-RP groups 224.0.1.39 and 224.0.1.40 to be Protocol Independent Multicast (PIM) dense mode flooded across interfaces operating in PIM sparse mode, use the ip pim autorp listener command in global configuration mode. To disable this feature, use the no form of this command.

see

http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_04.html#wp1012925

in this way you can use AutoRP with interfaces using ip pim sparse-mode.

I would use BSR that is standards based instead of Auto-RP.

BSR uses PIM messages with destination 224.0.0.13 and hasn't problems in a sparse only environment.

So if this is a new setup I would suggest to consider BSR.

Hope to help

Giuseppe

omarmontes · ‎10-23-2009

Thanks for the input!

But, when doing this in the Lab: If I configure all interfaces in SDM, and if dm-fallback is NOT activated, then AutoRP wont work :(. I thought it should.

In order to make it work with SDM, i found the following combinations:

- NO IP DM fallback needs AutoRP listener

- IP DM fallback configured (default), then you don't need the listener feature.

The deal here is that I though that AutoRP Listener was only needed when using Sparse only mode, but is also required with SDM if Fallback is not enabled.

And that makes me wonder: whats the difference between using:

- sparse only

- sparse-dense with DM Fallback disabled

Because both of them needs AutoRP listener enables in order to work.

Confused :(

Giuseppe Larosa · ‎10-23-2009

Hello Omar,

what devices are using and with what IOS image?

according to command reference user notes for ip pim dm-fallback:

>>

Use this command to prevent a router from falling back into PIM-DM when the RP becomes unavailable. This command also causes the router to block all multicast traffic for groups not specifically configured with an RP.

When IP multicast is used in mission-critical networks, you should avoid the use of PIM-DM. PIM makes the determination as to whether a multicast group operates in PIM-DM or PIM sparse-dense mode based solely on the existence of RP information in the group-to-RP mapping cache. If Auto-RP is configured or a bootstrap router (BSR) is used to distribute RP information, there is a risk that RP information can be lost if all RPs, Auto-RP, or the BSR for a group fails due to network congestion. This failure can lead to the network either partially or fully falling back into PIM-DM.

If a network falls back into PIM-DM, dense mode flooding will occur. Routers that lose RP information will switch all existing states into dense mode and any new states that must be created for the failed group will be created in dense mode.

>>

and also:

Command Default

PIM dense mode fallback is enabled. That is, a multicast group in the absence of rendezvous point (RP) information will fall to dense mode, regardless of the interface mode configuration.

if no ip pim fall-back blocks autoRP as you see in your tests is doing something that is not documented in the notes.

Hope to help

Giuseppe

omarmontes · ‎10-23-2009

After waiting a little while, it looks like "no ip pim dm-fallback" did not blocked AutoRP groups.

But I'm curious about what you said "doing something that is not documented"

If the group has no RP (and groups 224.0.1.39, 224.0.1.40 dont have an RP at first) and DM Fallback is enabled, this two groups should work as Dense Mode.. but if DM Fallback is disabled (like in my test), then it should be blocked, right?

Like you said:

"PIM dense mode fallback is enabled. That is, a multicast group in the absence of rendezvous point (RP) information will fall to dense mode, regardless of the interface mode configuration."

So the opposite is true? if it is NO enabled, then it wont fall to dense.. so should it be blocked?

Giuseppe Larosa · ‎10-23-2009

Hello Omar,

I wanted to mean that if

no ip pim dm-fallback

would block AutoRP this should be written clearly in the notes.

I'm happy to see that autoRP groups are an exception as it should be expected.

documentation says that

no ip pim dm-fallback

blocks any (user) group missing an RP to fallback to dense mode and as a result of this it blocks it.

Hope to help

Giuseppe

omarmontes · ‎10-23-2009

Thanks to you! I agree that this two groups should be an exception (and according to the test, they are), as they are not user generated.

Thanks again for the time