From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Mon Apr 07 2008 - 20:34:38 ART
Just to clarify the point about RPs sending register stops: When
testing I found the RP rejected the encapculated multicast flow even
when it has joined the group itself, unless it has a neighbor which has
requested it. A pim neighbor sending a join works fine, perhaps an
incoming igmp request is also enough (can't remember), but a loopback
with igmp join-group did not elicit any icmp responses from the RP.
Paul Cosgrove wrote:
> Hi Arun,
>
> When multicast boundary is applied in between a receiver and the RP
> (assuming the source is beyond the RP), it can prevent the receiver
> getting traffic for a group. However if applied between a source and
> the RP it cannot prevent the multicasts getting through, and could
> actually cause high CPU utilisation on the DR and RP.
> Multicast boundary works for native multicast packets, but cannot
> block encapsulated multicasts such as register messages (or tunneled
> multicasts etc.).
> It will not prevent the RP receiving the register messages, so cannot
> prevent the multicast group reaching receivers beyond the RP. Those
> receivers will send unicast ICMP responses which be sent back to the
> source. The multicast boundary command will prevent the R2 sending
> native multicast packets to the RP, and prevent the RP establishing a
> SPT back to the source.
> Incidently I've seen RPs reply with register stop messages in response
> to encapsulated multicasts if they do not have pim neighbors which
> have requested the group. Try it with R0 shutdown and an igmp
> join-group on the RP instead and you will (hopefully) see what I mean
> with a debug ip pim.
>
> In the real world you would limit the generation of register messages
> on all your own routers, and make sure only your routers can send
> register messages to your RP (or RPs). I suppose you could also
> apply the multicast boundary to your RP, thereby preventing the
> decapsulated multicast group being sent on anywhere.
>
> Paul.
>
> Rich Collins wrote:
>>> How about using the command without the "in" parameter? Just "ip
>>>
>>>> multicast boundary 27" I assume you are not running SSM.
>>>>
>>>> Router(config-if)#ip multicast boundary 27 ?
>>>> filter-autorp Filter AutoRP packet contents
>>>> in Restrict (s,g) creation when this interface is the
>>>> RPF
>>>> out Restrict interface addition to outgoing list
>>>> <cr>
>>>>
>>>> -Rich
>>>>
>>>>
>>>> On 4/7/08, ccie getit <goal.ccie@gmail.com> wrote:
>>>>
>>>>> Hello All,
>>>>>
>>>>> I am trying to get "multicast boundary <> in" working and I need a
>>>>> few
>>>>> clarifications.
>>>>> Topology: R0--------R1--------R2(fa0/0)--------(fa1/1)R3
>>>>>
>>>>> I have pim sparse mode enabled on all the connected interfaces. with
>>>>> R1 as
>>>>> the RP
>>>>> I have clients configured on R0(ip igmp join-group for 236.1.1.1 and
>>>>> 226.1.1.1)
>>>>>
>>>>> Now I have configured "ip multicast boundary 27 in" on R2's fa0/0
>>>>> and I am
>>>>> trying to allow only group 236.1.1.1 from R3.
>>>>>
>>>>> My access-list for 27 is like this
>>>>> permit 224.0.1.39
>>>>> permit 224.0.1.40
>>>>> permit 236.1.1.1
>>>>> deny any
>>>>>
>>>>> I see that I am able to ping to 236.1.1.1 and also to 226.1.1.1, I
>>>>> was
>>>>> expecting only 236.1.1.1 to be permitted access(RPF suceess).
>>>>>
>>>>> Could you please let me know what I am missing here.
>>>>>
>>>>> Regards,
>>>>> Arun
>>>>>
>>>>>
>>>>> _______________________________________________________________________
>>>>>
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:50 ART