All things related to multicast

[Amel Caldwell <>]

Alan--

The Apple SLP II (239.255.255.253) was what caused us the most grief and why
we chose to confine 239.255.0.0/16 to the subnets and not allow it on our
backbones.  Since you have Ciscoes, you could use the multicast boundary
statement on the user subnet interfaces to block inbound/outbound traffic at
that level.   Then the CGMP speaaking switches on your backbone would not see
this traffic.

Amel

On Fri, 3 Oct 2003, Alan Crosswell wrote:

>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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>