From: Ryan (ryan95842@gmail.com)
Date: Thu Nov 30 2006 - 21:14:24 ART
That's funny that you quote that. I had just finished reading that section
and was trying to get confirmation of what I thought was happening. In
previous books, it had not been explained in this fashion, so after reading
this, I was a little confused. I originally had thought that there was only
exactly 32 IP's that were overlapped, but this section indicated that not to
be true.
I was also confused about the last part with the host having to be Layer 3
aware. Sabrina explained that IGMP is 'smart' enough to do this for the
224.0.0.x network.
Ryan
On 11/30/06, Antonio Soares <amsoares@netcabo.pt> wrote:
>
> Hi Ryan,
>
> I think this excerpt from one of the MCast Bibles (Developing IP Multicast
> Networks) may help you:
>
> "It should be obvious that this 32:1 address ambiguity can cause some
> problems. For example, a host that wants to receive multicast group
> 224.1.1.1 will program the hardware registers in the network interface
> card
> (NIC) to interrupt the CPU when a frame with a destination multicast MAC
> address of 0x0100.5E00.0101 is received. Unfortunately, this same
> multicast
> MAC address is also used for 31 other IP multicast groups. If any of these
> 31 other groups are also active on the local LAN, the host's CPU will
> receive interrupts any time a frame is received for any of these other
> groups. The CPU will
> have to examine the IP portion of each received frame to determine whether
> it is the desired group, that is, 224.1.1.1. This can have an impact on
> the
> host's available CPU power if the amount of "spurious" group traffic is
> high
> enough.
>
> In addition to having a possible negative impact on hosts' CPU power, this
> ambiguity can also cause problems when trying to constrain multicast
> flooding in Layer 2 LAN switches based solely on these multicast MAC
> addresses."
>
> So hosts need to examine L3 information to avoid the L2 ambiguity.
>
> Regards,
> AMS
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Ryan
> Sent: quinta-feira, 30 de Novembro de 2006 20:39
> To: sabrina pittarel
> Cc: ccielab@groupstudy.com
> 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.xaddress'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
>
> _______________________________________________________________________
> 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