All things related to multicast

[Bruce Curtis <>]

  If a university using your RP has a single subnet (no routers in  
it's internal network) then you can  block things as you mention and  
it won't affect the local multicast traffic.

  However if a university as routers in it's local network the best  
thing to do would be to have an RP at each university with local  
routers and run MSDP between the RPs.  If you are not serving too many  
universities you could consider using an MSDP mesh group.  To prevent  
bad things like unwanted norton traffic between universities you can  
then use msdp filters to prevent the advertising of some groups  
between MSDP peers.

  This is an example cisco config with MSDP filters.

ip msdp peer <x.x.x.x>  connect-source Loopback1
ip msdp sa-filter in 134.129.65.254 list msdp-block-norton-altiris
ip msdp sa-filter out 134.129.65.254 list msdp-block-norton-altiris


ip access-list extended msdp-block-norton-altiris
 remark altiris
 deny   ip any host 225.1.2.3
 remark Norton Ghost
 deny   ip any 224.77.0.0 0.0.255.255
 deny   ip any 226.77.0.0 0.0.255.255
 deny   ip any host 229.55.150.208
 remark link-local multicast
 deny   ip any 224.0.0.0 0.0.0.255
 remark administratively scoped local
 deny   ip any 239.0.0.0 0.255.255.255
 permit ip any 224.0.0.0 15.255.255.255

  And this is an example juniper config with MSDP filters

msdp {
        rib-group inet pim-rg;
        group NorthernLights_i2 {
            export MSDP-filter;
            import MSDP-filter;
            peer <x.x.x.x> {
                local-address <x.x.x.x>;
            }
        }
        group hecn-internal {
            mode mesh-group;
            export msdp-block-norton-altiris;
            import msdp-block-norton-altiris;
            local-address <x.x.x.x>;
            peer <x.x.x.x>;
            peer <x.x.x.x>;
            peer <x.x.x.x>;
        }
    }



policy-statement msdp-block-norton-altiris {
        term norton-altiris-groups {
            from {
                route-filter 224.77.0.0/16 orlonger;
                route-filter 225.1.2.3/32 exact;
                route-filter 226.77.0.0/16 orlonger;
                route-filter 229.55.150.208/32 exact;
                route-filter 239.0.0.0/8 orlonger;
            }
            then reject;
        }


 policy-statement MSDP-filter {
        term bad-groups {
            from {
                route-filter 224.0.1.2/32 exact;
                route-filter 224.0.1.3/32 exact;
                route-filter 224.0.1.8/32 exact;
                route-filter 224.0.1.22/32 exact;
                route-filter 224.0.1.24/32 exact;
                route-filter 224.0.1.25/32 exact;
                route-filter 224.0.1.35/32 exact;
                route-filter 224.0.1.39/32 exact;
                route-filter 224.0.1.40/32 exact;
                route-filter 224.0.1.60/32 exact;
                route-filter 224.0.2.1/32 exact;
                route-filter 224.0.2.2/32 exact;
                route-filter 224.77.0.0/16 orlonger;
                route-filter 225.1.2.3/32 exact;
                route-filter 226.77.0.0/16 orlonger;
                route-filter 229.55.150.208/32 exact;
                route-filter 234.42.42.40/30 orlonger;
                route-filter 234.142.142.42/31 orlonger;
                route-filter 234.142.142.44/30 orlonger;
                route-filter 234.142.142.48/28 orlonger;
                route-filter 234.142.142.64/26 orlonger;
                route-filter 234.142.142.128/29 orlonger;
                route-filter 234.142.142.136/30 orlonger;
                route-filter 234.142.142.140/31 orlonger;
                route-filter 234.142.142.142/32 exact;
                route-filter 232.0.0.0/8 orlonger;
                route-filter 239.0.0.0/8 orlonger;
            }
            then reject;

On Aug 15, 2008, at 2:51 AM, Pekka Savola wrote:

> Hi,
>
> We're providing anycast-RP service to universities.  The problem is  
> that some universities are sending a lot of junk to our anycast RP,  
> and in some cases this may cause quite a load on the RP routers.   
> This junk includes:
>
> 1) global source addresses, global but identifiable group addresses  
> (e.g.
>   norton ghost -like applications)
>
> 2) global source addresses, pretty much random group addresses (e.g.  
> by
>   various p2p softwares, rtp "broadcast" addresses some voip phones  
> are
>   using etc.)
>
> 3) private source addresses, group address either in category 1) or  
> 2).
>
> We can drop these at the RP end, but I'm wondering if there is any  
> BCP or just suggestions how the institutions should configure their  
> equipment not to spew junk at us.
>
> An "alternative" to this would be to connect sites just using MSDP  
> but this seems pretty heavyweight for most users. (And then they  
> couldn't use Linux as a DR because there is no software.)
>
> I guess 1) and 2) could be tackled by blacklisting non-allocated  
> IANA address space (but this will impair the use of local apps that  
> do use addresses in that range) in "ip pim rp-address x.x.x.x ACL".  
> 3) seems like a more difficult problem. You can't filter based on  
> source address in rp-address ACLs.  What are the other options?   
> Drop these in input ACL at the LAN border (may impair valid use of  
> intra-campus multicast)?  Some other means?
>
> I'd be interested in hearing experiences how folks have dealt with  
> this (or if they tried, failed, and just scrapped mcast or moved to  
> MSDP).
>
> Pekka Savola


---
Bruce Curtis                         

Certified NetAnalyst II                701-231-8527
North Dakota State University