wg-multicast - Fwd: input on tightening up multicast filtering
Subject: All things related to multicast
List archive
- From: "Kevin C. Almeroth" <>
- To:
- Subject: Fwd: input on tightening up multicast filtering
- Date: Wed, 8 Dec 2004 17:04:29 -0800 (PST)
We should have some discussion on this... since there hasn't been
any on the list, I'm adding it to the agenda for Salt Lake City.
It would be worthwhile to have comments before, discuss during,
and post a final recommendation.
(Personally, I'm fine with all but (5)... simply because it a
general policy of blocking ranges of addresses that isn't
consistently followed makes for hard-to-debug problems if we
forget what we've blocked.)
-Kevin
> From: Matthew Davy
> <>
> Date: December 2, 2004 4:22:00 PM EST
> To: wg-multicast wg-multicast
> <>
> Subject: input on tightening up multicast filtering
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Last summer I gave a talk at Joint Techs on protecting multicast
> networks - see
> http://www.internet2.edu/presentations/jtcolumbus/20040720-Multicast-
> Davy.htm Since then I've had the opportunity to try out these
> suggestions on our campus network and see that they worked without
> causing problems for users (I think).
>
> This led me to think about whether or not some of these would be
> applicable to the Abilene network. I'm interested in hearing what
> everyone thinks. Here's a summary of what we did on the IU campus
> network...
>
> (1) Turned off MSDP data encapsulation.
>
> (2) Set per-source MSDP SA limit to 300. So no host on or off campus
> can send to more than 300 different group addresses.
>
> (3) Setting per-peer MSDP SA limits. We used to do this on the
> Abilene GSRs, but haven't implemented it very widely on the T640's for
> a variety of reasons.
>
> (4) Blocked MSDP, PIM, and multicast data packets for group range's
> whose corresponding ethernet MACs overlap with those associated with
> 224.0.0.0/24 (eg 224.128.0/24, 225.0.0/24, 225.128.0/24, etc).
>
> (5) Blocked MSDP, PIM, and multicast data packets for IANA reserved
> groups (ie 225/8-231/8, 234/8-238/8). This along with #4 goes a long
> way to reducing the impact of worms scanning in 224/4 space.
>
> (6) Blocked all multicast packets that are not IGMP, PIM or UDP. We
> blocked these right at the DR interfaces to the hosts.
>
> I don't have a particularly strong opinion on whether these make sense
> on Abilene or not, but I'm curious to see what the opinions on the
> list are.
>
> I should say however that I think these are all excellent things to
> implement on campus networks and I encourage everyone to consider
> deploying these to the extent these are feasible on your networks.
> I'll be glad to share our configs with you if that would be helpful.
>
> - - Matt
>
> Matthew Davy
> Chief Network Engineer, Indiana University
> University Information Technology Services / Abilene Network
> Operations Center
> 2711 East 10th Street, Bloomington IN, 47403
>
> / 812.855.7728
> PGP key fingerprint: A84D DFB6 9DD5 BEB4 1EF7 D713 956F F85C 6422 CBEB
- input on tightening up multicast filtering, Matthew Davy, 12/02/2004
- Re: input on tightening up multicast filtering, Charles R. Anderson, 12/08/2004
- <Possible follow-up(s)>
- Fwd: input on tightening up multicast filtering, Kevin C. Almeroth, 12/08/2004
- Re: Fwd: input on tightening up multicast filtering, John Kristoff, 12/08/2004
Archive powered by MHonArc 2.6.16.