Multicast Addressing Scheme

[paddyxdoyle]

Hi,

I've been asked to implement a Multicast addressing scheme for the University i am currently working at and would be grateful if someone could confirm my thinking as i haven't done a lot with Multicast before.

We have 6 main sites at the University that are currenrtly being moved over to a 10.* based addressing scheme with /12 masks:

site 1 - 10.16.0.0 /12

site 2 - 10.32.0.0 /12 etc...

Looking at the Multicast addressing RFC 2365, it would appear that local Multicast addressing needs to be allocated from 239.192.0.0 255.252.0.0 so i am thinking of taking the second octet of the 10.* scheme and using it in the 3rd of the Multicast scheme so we have some kind of addressing structure and allocating the Multicast addressing with /12 masks as follows:

site 1 = 239.192.16.0 /20

site 2 = 239.192.32.0 /20 etc..

Am i on the right track here?

TIA

Paddy

[paddyxdoyle]

Following on from the above as i ran out of time earlier :(

Can i use addressing from 239.0.0.0 /8 or does it have to be from the 239.192.0.0 255.252.0.0 range.

I can't see why using 239 /8 would be a problem as all the multicasting will be taking place on a private network?

Thanks

PJD

[szahid · Accepted solution]

Patrick :

The most important thing that you have to understand is unlike Unicast IP and MAC address that do not have any corelation, multicast mac is actually driven from multicast ip and it is no 1 to 1 mapping . We use only 23 bits from Multicast ip to drive a multicast mac . 4 bits are unique to class D which leaves 5 bits .What all of this means is there could be 32 different Multicast IP addresses that can end up having the same mac address. Now where you need to exercise caustion is you need to make sure that you select multicast IP addresses such that they never map to well known multicast mac addresses like 01-00-5e-00-00-01. For example , if you use a Multicast ip of 239.0.0.13 , it will result in multicast mac of 01-00-5e-00-00-0d which is the same mac address used by PIM which has a multicast ip of 224.0.0.13. So how can you avoid such a situation ? You can avoid such a situation by selecting a Multicast ip whose second and 3rd octects are always non-zero. That will always result in a mac address that wont collide with a well known mac address .So I would suggest that you go with 239.192.0.0 range instead of 239/8.

Hope this helps.

Salman

[paddyxdoyle]

Salman,

Firstly many thanks for the information.

As usual, this leads me on to further questions about implementing multicast in our routed environment :)

As mentioned previously we have 6 main sites on the network, which are connected together using 100 Mbps LAN Extension circuits, they are not in a full mesh but each site is connected to two others so there is some kind of resilience. There are also smaller satellite sites connecting into each of the main sites using WAN links from 2 Mbps serial connections up to 10 Mbps LAN extensions.

As the multicast addressing scheme is going to be based loosely on the 10.* scheme and we will be using sparse mode I am thinking of manually configuring rendezvous points at each major site so all local site multicast traffic (from the satellite sites to the main site) at each location is controlled at the major site router as this is more than likely where the servers supplying multicast services will be located, is this the correct way to go?

If we are using PIM on all the WAN links between all sites, my understanding is that clients at any site will be able to use multicast services from servers at any site as PIM will populate the multicast routing tables on all routers with PIM enabled interfaces, and IGMP will control the queries and reports from around the network populating the multicast groups wherever they reside in the network - does this sound correct?

Also is it best to use CGMP between the LAN and WAN, I’ve read that its much less resource intensive than IGMP snooping, does the fact that we are using IGMP on the WAN which I believe is enabled by default when using PIM have any issues with using CGMP between the LAN and WAN?

We have some pretty old switches at some of the network campuses (1900's), these are all being replaced in the next 8 months or so with 3750's. It looks like the 1900's support CGMP, however when looking at the support matrix for multicast the 6000 series switches don't support CGMP and we will be looking to put these into our main sites at the network core. Does this mean that there is a move towards IGMP snooping over CGMP, can both be implemented at the same time. I think there is a push to get multicasting working here quickly so we might have to go with CGMP to start and then move over to IGMP snooping, any thoughts on this would be appreciated

TIA

Paddy

[szahid]

_ you can define RPs statically , but that may not scale in the long term. You may want to look at Anycast RP implementation.

- Make sure PIM is enabled on all RPF interfaces and all possible interfaces which are going to receive multicast. Sometimes , people do not enable pim on some of the interfaces and those interfaces happen to be RPF interfaces for some sources resulting in software forwarding.

- Use IGMP snooping on platforms that allow tha . CGMP is much older technology.The platforms that implemet IGMP snopping so that in hardware so there should not be any performance hit whatsoever. There are some switches like 2900xl/ 3500xl switches that cannot do IGMP snooping at all and thats where you will just be restricted to CGMP>

- CGMP and IGMP snooping can both be used in the campus. Please take a look at this link for further info.

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800b0871.shtml

thanks

Salman Z.