All things related to multicast

["Wallace, Steven S" <>]

Hugh, does the following change address your immediate concerns?  I think it
makes more sense to filter SA coming in to Abilene rather than our current
practice of just restricting outbound SA.  If this looks good we can
implement tonight or morning.  

Current configuration:

ip msdp peer 134.68.3.1
ip msdp sa-filter out 134.68.3.1 list 111
access-list 111 deny   ip any 239.0.0.0 0.255.255.255
access-list 111 permit ip any any

Proposed configuration:

ip msdp peer 134.68.3.1
ip msdp sa-filter in 134.68.3.1 list 111
access-list 111 deny   ip any 239.0.0.0 0.255.255.255
access-list 111 deny   ip any 224.0.1.22 255.255.255.255
access-list 111 deny   ip any 224.0.1.35 255.255.255.255
access-list 111 deny   ip any 224.0.1.24 255.255.255.255
access-list 111 deny   ip any 224.0.1.60 255.255.255.255
access-list 111 deny   ip any 224.0.1.2 255.255.255.255
access-list 111 deny   ip any 224.0.2.2 255.255.255.255
access-list 111 permit ip any any


> -----Original Message-----
> From: Hugh LaMaster 
> [mailto:]
> Sent: Wednesday, July 14, 1999 4:47 PM
> To: ken lindahl
> Cc: Mark Fullmer; Multicast WG Internet2
> Subject: Re: So we need some scoping for non-global I2 
> multicast groups
> 
> 
> 
> 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*.
> 
> 
> 
> 
> 
>