All things related to multicast

[Hugh LaMaster <>]

On Wed, 14 Jul 1999, ken lindahl wrote:

> even so, i too would like to see general consensus on which of these
> groups is appropriate to restrict to campus and which are appropriate to
> announce.

There has been a huge increase recently in this kind of traffic, 
and, the top three definitely should be filtered ASAP.



> On Tue, 13 Jul 1999, Mark Fullmer 
> <>
>  wrote:
> >Top 5 groups for 128.32.0.224 (Berkeley)
> >-----------------------------
> >
> >224.0.1.22 261   SVRLOC.MCAST.NET
> >224.0.1.35 254   SVRLOC-DA.MCAST.NET
> >224.0.1.24 84    MICROSOFT-DS.MCAST.NET

These three, clearly, especially 224.0.1.22 & 35, which 
have gotten extremely voluble recently, no doubt due 
to some new software release.  We're now seeing 
thousands per hour.

> >224.0.1.32 21    MTRACE.MCAST.NET

Clearly, mtrace is traffic which should *not* be filtered,
although, I'm not sure about the implications of 
filtering source announcements vs. the actual traffic.
Perhaps Bill Fenner could give us some help there.
Anyway, skip this one.


> >Top 5 groups for 171.64.0.71 (Stanford)
> >-----------------------------
> >
> >224.0.1.35 205   SVRLOC-DA.MCAST.NET
> >224.0.1.22 158   SVRLOC.MCAST.NET

Same top two.

> >224.0.1.2 120    SGI-DOG.MCAST.NET

This one definitely needs to be filtered.  Certain SGI
applications also use it for organization-level data sharing.
However, we don't see enough to be concerned for performance
reasons.

> >224.0.1.60 59    HP-DEVICE-DISC.MCAST.NET

Should be filtered.  Tons of these now.

> >224.0.1.24 46    MICROSOFT-DS.MCAST.NET

I see this in the top 4:

224.0.1.22
224.0.1.35
224.0.1.24
224.0.1.60

I would also add at least 224.0.1.2 and one I haven't seen yet,
but which I have seen many bursts of traffic for from time
to time, 224.0.2.2 (SunRPC - port 111).


While we are on the subject, although the "expanding ring search"
component contributes a few from many places, a few sites seem
to contribute an extraordinary number, making me think those
sites have removed their multicast TTL thresholds.  NASA still 
adheres to the concept that an enterprise/AS should have an 
multicast TTL threshold of 64.  I notice that Stanford, UC Berkeley, 
and LBL don't seem to have such thresholds any more, and, much
of the traffic in the above groups reaching NASA seems to be coming 
from those sites.  So, since I'm pretty sure those sites all had
thresholds in the past, is there a reason they were removed?  I 
realize/agree that people should be using admin scoped addresses 
if that is what they need, but, there is a lot of other junk out 
there similar to the above four groups.  e.g. rwho traffic and others, 
and without a threshold, the filtering list necessary could be very
long.  

>From my perspective, 

 "no ip ip multicast ttl-threshold 64"

considered harmful.  Comments?  Disagreements?  etc.


-Hugh LaMaster


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