From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Tue Apr 08 2008 - 05:27:48 ART
Hi Omair,
IGMP is sent from receivers to devices on their same subnet, it does not
pass over multiple hops and I do not think it is a factor in this scenario.
While the reference states that "no multicast data packets are allowed
to flow across the boundary", this is really referring to native
multicast packets, rather than encapsulated/tunneled multicast packets.
Paul.
omair naim wrote:
> Usage Guidelines
> Use this command to configure an administratively scoped boundary(not meant
> for blocking igmp group) 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.
> If you configure the filter-autorp keyword, the administratively scoped
> boundary also examines Auto-RP discovery and announcement messages and removes
> any Auto-RP group range announcements from the Auto-RP packets that are denied
> by the boundary ACL. An Auto-RP group range announcement is permitted and
> passed by the boundary only if all addresses in the Auto-RP group range are
> permitted by the boundary ACL. If any address is not permitted, the entire
> group range is filtered and removed from the Auto-RP message before the
> Auto-RP message is forwarded. > Date: Tue, 8 Apr 2008 00:34:38 +0100> From:
> paul.cosgrove@heanet.ie> To: nilsi2002@gmail.com> CC: ccielab@groupstudy.com>
> Subject: Re: regarding "ip multicast boundary <xyz> in"> > 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> >
> _______________________________________________________________________>
> Subscription information may be found at: >
> http://www.groupstudy.com/list/CCIELab.html
> _________________________________________________________________
> Discover the new Windows Vista
> http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
>
> _______________________________________________________________________
> 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