With reference to multicast domains; the bulk of multicast documentation seems to make this statement and at the same time fail to clarify the term “multicast domain”.
If I have 300 remote sites communicating over a telecom provided MPLS cloud, each remote site has a different unique BGP Autonomous System number (ASN), would this be considered 300 multicast domains?
If I have 300 remote sites communicating over a telecom provided MPLS cloud, each remote site is configured with the same BGP Autonomous System number (ASN), would this be considered 1 multicast domain?
Is the term “multicast domain” based on, and references BGP Autonomous System?
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.
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.
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).
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.
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.
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.
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 18.104.22.168 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.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...