All things related to multicast

[Mark Quigley <>]

We have "ip multicast boundary" configured on our pnwgp link. The docs
state:

Use this command to configure an administratively scoped boundary on an
interface to filter multicast group addresses in the range defined by the
access-list argument. A standard access list defines the range of addresses
affected. When this command is configured, no multicast data packets are
allowed to flow across the boundary from either direction. Restricting
multicast data packet flow enables reuse of the same multicast group address
in different administrative domains.

Our filter looks like:
ip access-list standard multicast-boundary
 deny   224.0.1.39
 deny   224.0.1.40
 deny   239.0.0.0 0.255.255.255
 permit any

Good luck
-
Mark Quigley                                   (208) 885 6721 ph
Information Technology Services    (208) 885 7539 fax
University of Idaho                          

Moscow ID 83844-3155                  http://www.uidaho.edu/~markq
----- Original Message ----- 
From: "Amel Caldwell" 
<>
To: "Alan Crosswell" 
<>
Cc: "wg-multicast" 
<>
Sent: Thursday, October 02, 2003 2:45 PM
Subject: Re: constraining that pesky 239.255/16 traffic in a CGMP Borg


> Alan--
>
> I modified our inbound spoofing filters to deny ip any 239.255.0.0
0.0.255.255
> before permitting the local subnet traffic out.  I don't know the
> ramifications on CGMP on this approach though.
>
> Amel
>
> On Thu, 2 Oct 2003, Alan Crosswell wrote:
>
> >I want to define site-local as the same as link-local to constrain all
> >the hokey SSDP and other 239.255/16 traffic on my campus.  Can anyone
> >suggest the "right" way to do this?  I've tried blocking registers to
> >the RP with "ip pim accept-register" which results in a syslog for each
> >register attempt that is ignored, causing a lot of clutter.
> >
> >I've also tried "ip igmp access-group" on the individual router
> >interfaces since I really don't want to know about these groups.
> >However, this has wierd CGMP ramifications it seems:  membership reports
> >seem to cause the switch to get a CGMP join for the GDA.  v2 leaves
> >however do not cause a CGMP leave to make it to the switch, so the
> >static cam entry hangs aroud forever.
> >
> >/a
> >
> >
>
>