All things related to multicast

[Alan Crosswell <>]

I am attempting to block site local scope (239.255/16) *within* my 
domain.  At my border I block 239/8.  The key issue here is how to 
constrain this traffic to subnets (my internal policy decision which I 
am allowed to make for 239.255/16) without breaking CGMP so that this 
noise doesn't get flooded to all switch ports of my CGMP-speaking 
switches.  I suspect this same issue would apply to IGMP-snooping switches.

Take a look around at how much 239.255.255.250 port 1900 you are seeing 
on your campuses.  A lot of useless upnp noise.
/a

Ronan Kelly wrote:
> Hi all,
>
> We are using the config below.
> I just want to confirm something, we are blocking 239/8.
> You guys were mentioning 239.255/16.
> I thought 239/8 was the private address range, hence why we block that 
> on the edge of our AS.
> Is this correct?
>
> Ronan
>
>
> interface POS3/0
> description
> bandwidth 2500000
> ip address 62.40.103.230 255.255.255.252
> no ip unreachables
> no ip directed-broadcast
> ip pim bsr-border
> ip pim sparse-mode
> ip multicast boundary 24
> no ip mroute-cache
> ipv6 address 2001:798:2019:10AA::2/126
> --More--
> Standard IP access list 24
>    deny   224.0.1.39
>    deny   224.0.1.40 (5 matches)
>    deny   239.0.0.0, wildcard bits 0.255.255.255
>    permit 224.0.0.0, wildcard bits 15.255.255.255
>
> Mark Quigley wrote:
>
> > 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
> > > >
> > > >
> > > >     
> > >
> > >   
> >
> >
> >
> >