Mcast traffic switching with 32:1 macaddress overlap

[nedk12345]

Hi i have a basic question on frame switching on layer 3 device. once tree is built when actual data traffic is sent from the source towards receivers than on a layer 3 device which does not have directly attached receivers that device looks up s,g and forwards out interface in oil. What happens to frame at layer 2 when it gets encapsulated in ethernet frame. Does traffic gets encapsulated in ethernet frame header on each hop with the source mac of the layer 3 device which is forwarding it at that instant and the dst is the mcast mac address of the group. if so than there is 32:1 macaddress overlap than how is it possible that if there is other groups that also resolves to same mac traffic can overlap and can be forwarded to those duplicate groups also. How does that device know to use only interface in the oil list from a layer 2 point and not to forward for those other groups.

[Giuseppe Larosa]

Hello Ned,

your understanding is correct:

the L3 multicast routing capable device encapsulates the multicast packet in a multicast frame with MAC SA = router MAC and MAC DA = multicast mac address for groups like G.

the L2 device by using IGMP snooping or in other ways like old CGMP can lbuild a L2 port oilist for multicast MAC and cannot discriminate between group G and the other 31 multicast addresses.

The result is suboptimal L2 forwarding with traffic sent to interested receivers and to receivers interested to other traffic that uses a group that maps to the same multicast MAC address.

This scenario is considered not common, in any case it is left to the network administrators to take care to avoid this overlapping of L3 multicast addresses that are resolved in the same MAC in a specific vlan.

It is enough to change one bit in the last 23 significant bits to ensure unique MAC addresses so it is possible to avoid this scenario.

Hope to help

Giuseppe

[nedk12345]

Hello Giuseppe, does a device that do not have receivers connected directly also run igmp snooping. i was aware of this scenario on devices that have receivers connected on directly but was unsure on devices that do not have receivers connected directly and are just part of the mcast distribute tree. how do those kind of devices make decision when frame is encapsulated in layer 2 on which address to forward out of if there are multiple groups which resolve to same mac. on layer 3 they make decision based on the oil in the S,G but after that they have to encapsulate into ethernet and forward frame. how is it that those devices do not get mixed up in this 32:1 overlap or do they also get mixed up and if there are 2 or more groups which share the same mac than does that udp mcast data packet get sent out to all of them as well. thanks

[Jon Marshall]

nedk12345 wrote:
Hello Giuseppe, does a device that do not have receivers connected directly also run igmp snooping. i was aware of this scenario on devices that have receivers connected on directly but was unsure on devices that do not have receivers connected directly and are just part of the mcast distribute tree. how do those kind of devices make decision when frame is encapsulated in layer 2 on which address to forward out of if there are multiple groups which resolve to same mac. on layer 3 they make decision based on the oil in the S,G but after that they have to encapsulate into ethernet and forward frame. how is it that those devices do not get mixed up in this 32:1 overlap or do they also get mixed up and if there are 2 or more groups which share the same mac than does that udp mcast data packet get sent out to all of them as well. thanks

IGMP snooping would need to be run on intermediate devices as well otherwise an intermediate switch would have to flood multicast packets to all ports.

If you have 2 multicast groups that overlap in terms of the 32:1 scenario then every network switch would treat them as the same group. As Giuseppe said, it is up to the network admin to make sure that this overlap doesn't occur.

Edit - just to clarify. This overlap only occurs at L2 not L3.

Jon

[nedk12345]

Hello Jon, my knowledege was that IGMP is only between receivers and their first hop gateways so if so than why would a switch that does not have connected receivrs need to run igmp as in the core switch which does not have any hosts on it so it would only need to run pim. on 2nd portion it means that if the macaddress resolves to 2 or more mcast ip addresses than the core switch will flood out all the ports that it has learnt that mac from. if so than what is the oil list in s,g meant for. thx

[Jon Marshall]

nedk12345 wrote:
Hello Jon, my knowledege was that IGMP is only between receivers and their first hop gateways so if so than why would a switch that does not have connected receivrs need to run igmp as in the core switch which does not have any hosts on it so it would only need to run pim. on 2nd portion it means that if the macaddress resolves to 2 or more mcast ip addresses than the core switch will flood out all the ports that it has learnt that mac from. if so than what is the oil list in s,g meant for. thx

CoreSW1 -> SW1 -> SW2

in the above clients in vlan 10 are connected to SW2. The default-gateway for vlan 10 is on CoreSW1. So you can see why SW1 would need to run IGMP snooping. It may not have any directly connected receivers, receivers here meaning end devices, but it is in the path from the clients to their default-gateway.

if so than what is the oil list in s,g meant for. thx

The oil is relevant at L3. So the oil is to do with routing multicast packets. This is not the same as the L2 issue we are talking about. For example the CoreSW1 has 10 vlans. Only 4 of these vlans have multicast receivers. So the oil will restrict the multicast traffic to these 3 vlans ie. the multicast traffic will not be forwarded on the other 6 vlans. So that's the purpose of the oil.

What we are talking about is once the traffic has been routed onto a vlan ie. in our example, one of the 4 vlans, then within that the L2 overlap, IGMP snooping etc. become relevant.

Jon

[nedk12345]

jon.marshall wrote:
CoreSW1 -> SW1 -> SW2
in the above clients in vlan 10 are connected to SW2. The default-gateway for vlan 10 is on CoreSW1. So you can see why SW1 would need to run IGMP snooping. It may not have any directly connected receivers, receivers here meaning end devices, but it is in the path from the clients to their default-gateway.

yes i understand that first hop gateway will need IGMP however what if such

client y.y.y.y

|

SW3

|

DIST3

|

CORE1 -> DIST1 -> SW1 -> client x.x.x.x

|            

DIST2

|

SW2

|

src z.z.z.z

recevr client x.x.x.x default gateway is DIST1 than i do not think CORE1 need IGMP. Would that be correct. src default gw is DIST2 than on CORE1 what if mcast packet comes from src x.x.x.x and s,g on CORE1 says to forward out to DIST1 but when encapsulate in ethernet the mcast mac also is being asked for by another receiver that is of DIST3 but the l3 mcast group address is differnet than what step will happen on CORE1 when L2 encapsulation happen. will packet get sent to DIST3 even if client y.y.y.y was asking for another mcast ip group but because of 32:1 overlap the mac is the same. how does core1 know that at L2 layer it only will forward out interface that is going to DIST1 only. thanks

[Jon Marshall]

nedk12345 wrote:
jon.marshall wrote:
CoreSW1 -> SW1 -> SW2
in the above clients in vlan 10 are connected to SW2. The default-gateway for vlan 10 is on CoreSW1. So you can see why SW1 would need to run IGMP snooping. It may not have any directly connected receivers, receivers here meaning end devices, but it is in the path from the clients to their default-gateway.
yes i understand that first hop gateway will need IGMP however what if such
client y.y.y.y
|
SW3
|
DIST3
|
CORE1 -> DIST1 -> SW1 -> client x.x.x.x
|             
DIST2
|
SW2
|
src z.z.z.z
recevr client x.x.x.x default gateway is DIST1 than i do not think CORE1 need IGMP. Would that be correct. src default gw is DIST2 than on CORE1 what if mcast packet comes from src x.x.x.x and s,g on CORE1 says to forward out to DIST1 but when encapsulate in ethernet the mcast mac also is being asked for by another receiver that is of DIST3 but the l3 mcast group address is differnet than what step will happen on CORE1 when L2 encapsulation happen. will packet get sent to DIST3 even if client y.y.y.y was asking for another mcast ip group but because of 32:1 overlap the mac is the same. how does core1 know that at L2 layer it only will forward out interface that is going to DIST1 only. thanks

Correct in what you say in your example. DIST1, DIST2, SW1, SW2 all need IGMP snooping, CORE1 does not.

And if DIST3 requests a different multicast group but one that overlaps at L2 then no, CORE1 would not forward src z.z.z.z packets to DIST3 because from CORE1 to DIST3 the multicast packets are routed based on L3 multicast addresses.

Jon

[nedk12345]

jon.marshall wrote:
And if DIST3 requests a different multicast group but one that overlaps at L2 then no, CORE1 would not forward src z.z.z.z packets to DIST3 because from CORE1 to DIST3 the multicast packets are routed based on L3 multicast addresses.
 Jon

if it does it at L3 but does it not still needs to encapsulate frame in ethernet header at L2 and at L2 mac of that group still overlaps so what mechanism does CORE1 use from L2 point to know that it will only forward out interface to DIST1 and knows not to forward out the interface to DIST3 where duplicate is because at L2 ethernet header mac is the same for both sides. thanks

[Jon Marshall]

nedk12345 wrote:
jon.marshall wrote:
And if DIST3 requests a different multicast group but one that overlaps at L2 then no, CORE1 would not forward src z.z.z.z packets to DIST3 because from CORE1 to DIST3 the multicast packets are routed based on L3 multicast addresses.
 Jon
if it does it at L3 but does it not still needs to encapsulate frame in ethernet header at L2 and at L2 mac of that group still overlaps so what mechanism does CORE1 use from L2 point to know that it will only forward out interface to DIST1 and knows not to forward out the interface to DIST3 where duplicate is because at L2 ethernet header mac is the same for both sides. thanks

Because the decision has already been made as to which interface(s) to forward the packets out of. So yes it will then add the frame header but it already knows it needs to be sent to DIST1 only.

Compare this with a L2 switch that cannot use the L3 multicast group address and so only has the mac-address to forward the traffic. Without IGMP snooping it would have to forward out of all ports.

That's why i said in a previous post that it was important whether your CORE1 switch was acting as a L2 switch or a L3 switch. The following discussion has been based on it acting as a L3 switch but if it was a L2 switch then you would indeed need IGMP snooping enabled.

Jon

[nedk12345]

see below

[Giuseppe Larosa]

Hello Ned,

for L2 switches that are providing a layer 2 service to multicast routers there are approaches similar to IGMP snooping:

RGMP

PIM snooping

these deal with vlans where connected devices are not end users but routers that can be multicast capable or not.

see

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/snooppim.html

PIM snooping is the more modern approach.

RGMP had been introduced before

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/rgmp.html

the idea here is to have the L2 acting switch to snoop PIM messages to understand for each router what groups it is interested in.

this requires of course L3 and above intelligence so the overlapping issue should not affect these specialized multicast forwarding tecniques.

Hope to help

Giuseppe

[nedk12345]

jon.marshall wrote:
Because the decision has already been made as to which interface(s) to forward the packets out of. So yes it will then add the frame header but it already knows it needs to be sent to DIST1 only. 

I had difficulty to understand how that decision is part of the L2 Frame and is implicated in the L2 Frame. There is no place for interfaces in the ethernet frame.  Is it not that forwarding decision is based on dst mac and if that is the case than since its 32:1 overlap than it should be sent out all the interfaces where that mac is being learnt from which will be both DIST3 and DIST1 as both clients x.x.x.x and y.y.y.y are subscribers for that group.

That's why i said in a previous post that it was important whether your CORE1 switch was acting as a L2 switch or a L3 switch. The following discussion has been based on it acting as a L3 switch but if it was a L2 switch then you would indeed need IGMP snooping enabled.
Jon

I always wanted to know from L3 perspective on Core1 and not L2. thanks