All things related to multicast

[Hugh LaMaster <>]

On Mon, 24 Jan 2000, Jeff Olenchek wrote:

> An RSP2. The traffic was coming in on a 16Mbyte VIP2 via a full-duplex
  ^^^^^^^
An RSP4 should be able to handle this much better without distributed routing.
An RSP2 could be overloaded, depending on just how fast DriveImage
can move data.  During DriveImage operation, it would be interesting
to see the output from "show proc cpu" and "show int".  It sounds
like the CPU on the RSP2 overloaded.  Also, although the models
may have changed, I think the "16 MByte" implies a VIP2-15 or -20,
which is not really fast enough to handle full-speed distributed
switching in my experience.  So, you really don't have a great 
choice in this case.


> The dropped RIP packets were noticed on a FDDI subnet which the router
> and our campus Unix boxes share.

Overloaded CPU is very likely given this configuration.


>       DriveImage an interesting multicast test tool, though ;-)
>       Sending 5000 pps to 230.0.0.1 could be considered a kind of 
>       DoS attack.
> 
> Exactly--The site in Sweden did contact our abuse group about this....

The TTL=255 seen below adds weight to the DoS viewpoint.


>       But, since I have seen similar routers handle equivalent 
>       forwarding loads without a problem, I'm wondering if there 
>       are some other factors involved.
> 
> It wouldn't surprise me if I misconfigured something...

No, I wouldn't say so.  Unfortunately, with an RSP2, the main
CPU probably won't be fast enough to handle this via fast switching,
and, with a VIP2-15/20, the VIP probably isn't fast enough to handle 
this load distributed.

> p.s. This is one of the packets captured via our sniffer:
> IP:   Time to live    = 255 seconds/hops
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I was afraid of that.  I can't understand why people do this.
That is, implicitly assume that it isn't routed, but, set the 
TTL high.  Sigh.

> IP:   Destination address = [230.0.0.1]

> UDP:  ----- UDP Header -----
> UDP:  
> UDP:  Source port      = 2222
> UDP:  Destination port = 2222

If this becomes a common problem, it may be necessary to filter
on this port #.


The situation is similar to what we have seen in the past
with some other protocols, with a high TTL causing LAN
protocols to be "joined" together, pulling traffic 
across to each other.   The new phenomenon here is that
the bandwidth is potentially somewhat high, making this a 
potentially serious problem when lots of LANs which use
this product are joined together.  Unfortunately, the
address and port usage doesn't fit the usual pattern,
but filtering may be necessary.


Comments/corrections welcome.



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