All things related to multicast

[Mark Fullmer <>]

> Also, how about the TTL threshold on the (campus side) border
> routers to prevent egress of "local" traffic:
> 
> int FastEthernet0/0
>  ip address 11.11.11.11
>  ip access-group 111 in
>  ip access-group 111 out
>  no ip redirects
>  no ip directed-broadcast
>  no ip proxy-arp
>  ip pim sparse-mode
>  ip multicast boundary 1
>  ip multicast ttl-threshold 64
> 
> 
> ip msdp peer 10.10.10.10
> ip msdp sa-filter in 10.10.10.10 list 111
> ip msdp sa-filter out 10.10.10.10 list 111
> ip msdp ttl-threshold 10.10.10.10 64

I don't think this is going to fix the SA messages though.  For MSDP
SA announcements to be TTL scoped the router would need to keep track
of the TTL for the source.  This get complicated by expanding ring
searches where the TTL varies.

> The TTL threshold can also limit the effect of new pseudo-broadcast 
> groups that we haven't even thought about yet.  Since every AS 
> has a bunch of these services, what you end up with, despite 
> running PIM-SM, is a worldwide broadcast domain for these service
> advertisement/status multicast groups, with, potentially, hundreds 
> of thousands of sources.  Unfortunately, many of these services
> are either historical, or, are still being defined by folks who
> don't realize that multicast can be global.  I can't think of 
> any instances where it is desirable for that type of traffic
> to be broadcast worldwide.  

This is an issue, not just because of the PIM and MSDP processing involved
but the end users are seeing services show up that are on the other side
of the country.

> I know there are proposals for thresholds to be taken off of 
> non-scoped groups, but, unfortunately, people are not using
> 239.x.y.z addresses for these local services, and, they are 
> scattered throughout the 224.0.{0,1,2}.x address space...
> Also, a lot of end-users don't really understand 239.0.0.0 scoped
> addresses, and haven't configured sdr to handle local definitions,
> so, there is an educational aspect to this, too.

What about having a source admission policy (initially) at 
border routers?  For a source to send to a group outside their
PIM-SM domain (ie a campus) they need to register the source and
group which could trigger an update of the outgoing sa filter list.
Groups that get picked up from SAP.MCAST.NET would get added with
an 'any' for the source.

--
mark