Hi Rais,

So it appears my complete network (300 remote sites) is within a single multicast domain, and thus I should NOT need MSDP to disseminate "RP to source" information to the multiple Anycast RPs. Pim-SM should complete this task. I will remove MSDP and see how it goes.

Tks

Frank

Frank,

Using MSDP in Anycast-RP scenario has nothing to do with VRFs. The Anycast-RP is absolutely dependent on MSDP because otherwise, the entire network would become partitioned into several clusters, one for each RP, and the multicast traffic sourced from a sender in one particular cluster would not be distributed to other clusters. The MSDP is there to inform the RPs about existing multicast sources to individual groups, and if one cluster contains the multicast source for a particular group, the other RPs can send their PIM Join messages towards that source and extend the branch of the distribution tree to their own clusters.

So once again, Anycast-RP needs the MSDP as one of the fundamental protocols. PIM alone is not capable of handling this.

Best regards,

Peter

Hi Peter,

Thanks for assisting!

:

The authors of many multicast documents write as if everyone is a multicast expert when in fact most folks don't even bother implement multicast. I think the reason is due to the lack of clear documentation. Since folks are not implementing multicast, programmers are not writing apps; .... vicious cycle  --off my soapbox now......

:

Anyway, I do agree with most of your statements, but Cisco authored RFC 4610 states MDSP is not needed   [1st page in Abstract]   as PIM can accomplish the same task when Anycast-RP has been implemented. I understand this RFC 4610 is a "request for comment" dated 8-2006 but since Cisco doesn't date most of their technical documents it is really hard to tell who is doing what and when.

:

My original question was trying to nail down the definition of a "multicast domain" as this seems to be the key to understanding which protocol is needed where, when and why.

:

I run Bidir PIM, Anycast-RP, MSDP in a MPLS Hub and Spoke environment. For one-to-many application I source Video and for the many-to-many, I utilize a Whiteboard application (everyone can update simultaneously and changes are updated simultaneously to everyone, great remote-site collaboration tool).

:

Thanks again for your assistance

Frank

Ok, so the definition of a "Multicast Domain" is still a mystery to me - apparently to many folks out there as well. Never the less, I only needed to understand this term as I was unable to get consistent results in our multicast environment. We have multicast setup in two different configurations.

:

The first is multicast "many-to-many" and the second is multicast "one to many".

:

The One-to-many is your typical headquarters video streaming. HQ streams a video message out to the end-users. Only the HQ site can source multicast traffic and only the end-users can receive multicast -Eg. Radio station.

:

The many-to-many is a little more involved as anyone can source multicast and anyone can "join-in" and receive the multicast stream. Our network spans the entire US and several countries so traveling gets expensive. We need to collaborate simultaneously from many different locations. A whiteboard application [across the network] works very well for this type of need. Some folks initially used cameras for this setup but after the newness worn off folks stop using the cameras. Go figure.

:

As it turns out, we cannot use  MSDP or Anycast in our environment with the many-to-many setup - it does not function properly. . . . and well . . . .  is not supported as of April 11, 2012. Phantom RP is the key!!!! Failover works magically.

:

Our network is a Dual Hub and spoke (~ 300 spokes) MPLS environment. Hub and Spoke meaning spoke to spoke traffic MUST traverse one of the Hubs at all times. This is not DMVPN Phase 2 type of environment where the hub is only used to setup the connection and then spokes to spoke communicate directly. Hub and Spoke packets ALWAYS pass through the hub, ingress and egress.

:

Thanks again for the support.

Frank

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

I consider a multicast-domain much similar to a broadcast-domain, i.e. the span of a set of multicast packets.  In other words, if host A transmits multicast packets can host B obtain them (if it wants them)?

Unlike broadcast, which comprises only one broadcast (disregarding L2 vs. L3, directed broadcast, etc.), every multicast address could have it's own domain.  In fact, within the major address subdivisions of multicast addresses, there are expectations for different domain sizes, such as 224.0.0.0 to 244.0.0.255 for only local subnet usage.

By having multicast-domains, we can reuse the same multicast address without conflict as long as we insure the domains don't overlap.