Skip to Content.
Sympa Menu

wg-multicast - Re: PowerQuest DriveImage

Subject: All things related to multicast

List archive

Re: PowerQuest DriveImage


Chronological Thread 
  • From: Thomas Maufer <>
  • To: Jeff Olenchek <>
  • Cc:
  • Subject: Re: PowerQuest DriveImage
  • Date: Mon, 24 Jan 2000 13:31:29 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 13:31 -0600 2000-01-24, Jeff Olenchek wrote:

>We had a 7513/120-8.5.S melt (RIP packets would stop being sent)
>when a lan administator used a package called DriveImage. DriveImage
>sends data to address 230.0.0.1/01-00-5e-00-00-01.
>
>Is there any repository of information available that documents
>the problems multicast enabled networks might encounter with
>packages like DriveImage?
>
>Thank you,
> jeff Olenchek
> U of Wisconsin-Milwaukee



Jeff--

Well, I'm sure you see the problem, which is that if someone
picks *any* value between 224 and 239 in the first byte of a
class D address and then simply sets the least-significant
byte to "1", then the resulting multicast MAC address will be
0x01-00-5e-00-00-01. At the MAC layer, all these 32 IP class
D destination addresses look the same as the "all systems on
this subnet" multicast address (224.0.0.1).

To a layer-2-only device, there is no way to tell these 32
addresses apart, since they all map to the same MAC multicast
address...but to a layer-3 device (e.g., a router), it should
be possible for it to tell that it is not a member of the group
address that is in the IP Destination Address field, therefore
it will not process the packet. This sounds like it might be
a bug to me.

I don't think that CGMP or IGMP Snooping could help you here,
since the switches probably only get to make decisions based on
looking at the MAC Source and Destination Address fields. Since
224.0.0.1 is never joined, all switches would have to flood
0x01-00-5e-00-00-01 (unless it could peek at the IP layer and
see if the first 8 bits of the IP Destination address started
with "1110" but were not "1110 0000").

The easiest fix would be to get DriveImage's developers to set
some bit pattern in the second and third bytes of the IP address.
Even just making their software use 230.1.0.1 would be sufficient,
since it would not look like 0x01-00-5e-00-00-01 at the MAC layer
(it would be 0x01-00-5e-01-00-01). However, I still think that
the router should be able to drop this traffic without falling
over.

Just my $0.005,
Tom
- --
Thomas Maufer Ok, so what do we call this decade? |o|
Proposal: The "Naughties", which |o|
PGP Key Fingerprint (DSS): sounds like "twenties", "nineties", |o|
0E37 CE46 9D05 63C5 BD8C etc. Also, it lends itself to easy |o|
1242 5240 843D A36B FEB1 pronunciation, e.g., twenty-naughty- |o|
three. Finally, 2000 could be pro- |o|
nounced as simply twenty-naughty, |o|
similar to nineteen-ninety. |o|
____________________________________________________________________ |

-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5.2

iQA/AwUBOIzE0FJAhD2ja/6xEQJVYQCguE7sERekSYAooZRImVQUik2uQGoAn2eU
tQ6c+I1tO1OI17i9QHfWK9Bk
=WuGf
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.16.

Top of Page