All things related to multicast

[Hugh LaMaster <>]

On Mon, 24 Jan 2000, Thomas Maufer wrote:

> Date: Mon, 24 Jan 2000 13:31:29 -0800
> From: Thomas Maufer 
> <>
> To: Jeff Olenchek 
> <>
> Cc: 
> 
> Subject: Re: PowerQuest DriveImage
> 
> -----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)

Interesting.  RSP2/4?  Was this with a VIP-2/{40,50} with
FastEthernet PA?  Was the router connected full-duplex to 
a switch, or, e.g., half-duplex to a hub?  Was the CPU
saturated, the VIP saturated, and/or the network saturated?
At this point, it is difficult to say whether the router
has a problem or not.  If some systems are on half-duplex
10 Mbps ethernet, then it wouldn't surprise me if the
"broadcast" traffic saturated the output and prevented
RIP from being received.  What were the relevant multicast
IOS configuration lines (e.g. ip multicast-routing distributed).
What was the configuration of the interface involved.  In short, 
could you provide more detailed information?

> >when a lan administator used a package called DriveImage. DriveImage
> >sends data to address 230.0.0.1/01-00-5e-00-00-01.

This is very strange.  I've seen DriveImage for sale at Fry's;
I'm trying to imagine why they would send the output to a 
multicast address in the first place.  It sounds like
someone took a shortcut for sharing data without understanding
how multicast is usually used/configured.  It might make
DriveImage an interesting multicast test tool, though ;-)
Sending 5000 pps to 230.0.0.1 could be considered a kind of 
DoS attack.

> >Is there any repository of information available that documents
> >the problems multicast enabled networks might encounter with
> >packages like DriveImage?

I don't know of any such repository, but, this isn't the first
such program.  I recall running into an old application which 
implicitly assumed multicast was unroutable, but, sent a 
high-speed data stream with TTL=255.  These things happen.
DriveImage sends its stream with TTL=1, I hope?  

> 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

Indeed, this is a legacy of the IPv4 multicast definition 
from the beginning.

> 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'm sure the router does realize that it isn't 224.0.0.1,
but, unfortunately, no doubt it has to do this in the driver, 
rather than the ethernet hardware.  But, the driver should
be able to throw away such packets at wire speed, I would 
think.  (Depends on the H/W configuration, though).

> 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").

I believe that some newer switches and "switching" routers do have the 
flexibility to filter such combinations, although I haven't actually
configured such a thing myself.

> 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.

Probably true, although, any software-based router will have 
this problem.  A "switching" router with wide ASICs and the
flexibility for the software to configure such combinations 
might be work better for this situation.

But, since I have seen similar routers handle equivalent 
forwarding loads without a problem, I'm wondering if there 
are some other factors involved.

> Just my $0.005

Likewise.



--
 Hugh LaMaster, M/S 233-21,    Email: 

 NASA Ames Research Center     Or:    

 Moffett Field, CA 94035-1000  Or:    

 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.