From: Ryan (ryan95842@gmail.com)
Date: Thu Nov 30 2006 - 21:07:38 ART
Thanks Sabrina,
I guess my questions was not clear from the beginning, but you have
clarified it and confirmed what I thought was the case, but was not sure.
What I should have said is:
"For any given Multicast Mac address, there will be 32 different Class D
Multicast IP
address's associated."
I guess this is where I found so much confusion in the various books. They
don't word it this way.
Thanks for taking the time to explain.
-Ryan
On 11/30/06, sabrina pittarel <sabri_esame@yahoo.com> wrote:
>
> 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
> >
> >
> _______________________________________________________________________
> >
> Subscription information may be found at:
> >
> http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> ________________________________
> Access over 1 million songs - Yahoo! Music
> Unlimited.
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
> Want to start your own
> business? Learn how on Yahoo! Small Business.
>
> _____________________________________________________________________________
> _______
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:49 ART