From: omair naim (omairnaim1@hotmail.com)
Date: Tue Apr 08 2008 - 03:15:41 ART
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> >>>>> > >>> >>
This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:50 ART