From: sabrina pittarel (sabri_esame@yahoo.com)
Date: Thu Nov 30 2006 - 20:51:28 ART
Rayn,
if you know the theory behind it, then you should be able to reply to
your original questions on your own.
Anyway the statement you made in your
email below is wrong:
"So, based on this, I would have to say that for any
given Multicast IP
address, there is going to be EXACTLY 32 duplicate MAC
address's"
I think you meant:
"So, based on this, I would have to
say
that any Multicast Mac addresse in the 0100.5exx.xxxx category
(which is the
range of addresses IEEE reserved for IP multicast
transmission) could be
associated to 32 different Class D Multicast IP
address"
or better:
"32
different Class D Multicast IP addresses maps into the same Multicast Mac
addresses"
So you should realize that the 224.0.0.x address range does
not make any difference.
Now do you understand the implication of the
aliasing? There are strong
implications in L2 switching of multicast packets
due to that.
In regular L2 switching, multicast traffic generates an L2
miss result
during the mac table lookup and it is gets flooded. So aliasing or
not,
always the same behavior you get.
This is if you do not have features,
like IGMP snooping or CGMP, that creates multicast entries in the L2 table.
IGMP snooping "snoops" IGMP packets and learn the multicast group
membership
on a port. For example it learns that on interface f0/0
there is a receiver
for group 224.1.1.1.
It then installs an entry in the L2 table for the
corresponding mac address:
0100.5e01.0101 -> f0/0
From this moment on,
mcast traffic received by the switch with that mac DA address will be bridged
out of f0/0 and not flooded.
Unfortunately we are not able to limit only
traffic for 224.1.1.1 to be
bridged out of f0/0 , but we'll also forward
traffic for all the 32
mcast ip address that alias to 0100.5e01.0101.
Now,
let's assume an host joins 225.0.0.1, do we want IGMP snooping to install an
0100.5e00.0001 -> f0/0
entry into the L2 table?
Of course not!
Otherwise even traffic for 224.0.0.1 will only be sent out of f0/0. And that
is not what we want.
So IGMP snooping is so intelligent to recognize
addresses that aliases
with the reserved mcast range and not to do anything
for them.
Hope this helps to clarify a little what all this fuss around
aliasing is.
Regards,
Sabrina
Sabrina
----- Original Message
---- From: Ryan <ryan95842@gmail.com> To: sabrina pittarel <sabri_esame@yahoo.com> Cc: ccielab@groupstudy.com Sent: Thursday, November 30, 2006 12:38:47 PM Subject: Re: Grasping the Multicast 32:1 duplicate MAC address issue...(use courier to view)
This is the same information I've read in a what seems like a dozen books and web pages. They all say that you only use last 23bits of the IP to make up the MAC address. Nothing new here. Yet, there is is this 32:1 overlap, but I've not found any documentation or book that goes beyond that to explain.
So if I try this out for myself for example:
Lets take a random Multicast IP address. 228.45.3.2 (I just typed in some numbers, so that's as random as were going to get)
Let's make this IP into a Multicast MAC address...
228.45.3.2
01:00:5e:xx:xx:xx
xxx.45.3.2 45 . 3 . 2 0010 1101.0000 0011.0000 0010 ^ 2 D: 0 3: 0 2 x010 1101.0000 0011.0000 0010
So if I've done my math right, 228.45.3.2 should be: 01:00:5e:2d:03:02
If I add a '128' to it to simulate the 1 in the 24th spot that gets excluded in the conversion,
228.173.3.2 should ALSO be: 01:00:5e:2d:03:02
So, based on this, I would have to say that for any given Multicast IP address, there is going to be EXACTLY 32 duplicate MAC address's. 224.y.x.x 224.(y+128).x.x 225.y.x.x 225.(y+128).x.x ... 238.y.x.x 238.(y+128).x.x 239.y.x.x 239.(y+128).x.x
So, what happens with well know Multicast IP's like the 224.0.0.x address's?
This would seem to mean that you could not use any Multicast address is y.0.0.x range or y.128.0.x range as it would conflict with the 224.0.0.xaddress's.
This correct?
-Ryan
On 11/29/06, sabrina pittarel <sabri_esame@yahoo.com> wrote: > > > > Hi Rayn, > the way the MAC Destination Address for a multicast packet is built is the following: > > the last 23 bits of the IP multicast address are copied into the last 23 bits of the MAC address, while the beginning of the MAC address is fixes and set to 0100.5e(xx.xxxx) > This leaves 9 bits of the IP multicast address (32-23 = 9) that are not reflected anyhow in the L2 MAC. These are the first 9 bits of the IP address. > Of these 9 bits 4 are fixed (1110b => class D address) but 5 are variable so all the combinations of these 5 bits (2^5) generates ip multicast addresses that matches the same mac. > > Hope this helps, > > Sabrina > > > > > > ----- Original Message ---- > From: Ryan <ryan95842@gmail.com> > To: ccielab@groupstudy.com > Sent: Wednesday, November 29, 2006 6:02:17 PM > Subject: Grasping the Multicast 32:1 duplicate MAC address issue... > > > > I'm a little confused by the Multicast duplicate MAC address issue... > > Is the 32:1 duplicate MAC address issue just for certain address's (32 > total)? > > 224.1.1.1 > 224.129.1.1 > 225.1.1.1 > 225.129.1.1 > ... > 238.1.1.1 > 238.129.1.1 > 239.1.1.1 > 239.129.1.1 > > Or does it apply to ANY Multicast address? So for any one Multicast address, > there are exactly 32 duplicates.... > > > > -Ryan > >
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:49 ART