From: Rich Collins (nilsi2002@gmail.com)
Date: Thu Feb 12 2009 - 21:41:39 ARST
Hi,
I labbed this up myself as well.
The filter auto-rp saves you a couple of lines in your access list.
For example you want to allow 224.0.0.0 - 225.255.255.255 across the
boundary but not the auto-rp groups. You can make a simple access
group for this range but forbid the auto-rp within this range.
access-list 12 permit 224.0.0.0 1.255.255.255
!
interface FastEthernet2/0
ip address xxxx
ip pim sparse-dense-mode
ip multicast boundary 12 filter-autorp
Some debugging and a ping will show this effect:
06:08:42: Auto-RP(0): Send RP-Announce packet on FastEthernet1/0
06:08:42: Auto-RP: Announcement packet, group 224.0.0.0 with mask
240.0.0.0 removed because of multicast boundary for group 0.0.0.0 with
mask 0.0.0.0
06:08:42: Auto-RP(0): Send RP-Announce packet on Loopback0(*)
06:09:04: IP(0): s=23.23.23.2 (FastEthernet1/0) d=224.6.6.6
(FastEthernet2/0) id=74, ttl=254, prot=1, len=100(100), mforward
06:09:04: IP(0): s=12.12.12.2 (FastEthernet1/0) d=224.6.6.6
(FastEthernet2/0) id=74, ttl=253, prot=1, len=100(100), mforward
-Rich
On Thu, Feb 12, 2009 at 11:58 AM, Hobbs <deadheadblues@gmail.com> wrote:
> Hi Gaurav,
>
> I just quickly labbed these scenarios and this is my understanding,
> please chime in if I am mistaken:
>
> Solution 1: You are preventing joins for the AUTO-RP groups, so in
> effect it does what you are tasked with. Since the upstream device
> prevents the downstream device from joining those groups, it will not
> forward AUTO-RP messages out of that interface.
>
> Solution 2: You are actually preventing the AUTO-RP messages from
> being sent to the downstream router. You are also preventing any
> mroute state for any group.
>
> Solution 3: I think this accomplishes the same as #1 because you are
> preventing the AUTO-RP groups from being joined by the downstream
> router.
>
> It looks like the filter-autorp keyword works on groups that were
> denied by the ACL. So if you are going to deny everything anyway, then
> filter-autorp is redundant. ANd if you are going to prevent the
> AUTO-RP groups from being joined, the filtering AUTO-RP messages for
> the other groups is again redundant.
>
> That being said, they all seem to solve your task. If I had a choice,
> I don't know what I would pick... :)
>
> -hth
>
>
> On Thu, Feb 12, 2009 at 8:06 AM, GAURAV MADAN <gauravmadan1177@gmail.com> wrote:
>> HI All
>>
>> I have a task that says multicast AUTO-RP announce and discovery messages
>> should not be sent out f0/0
>>
>> Sol 1
>> ************
>> access-li 11 deny 224.0.1.39
>> access-li 11 deny 224.0.1.40
>> access-li 11 per any
>>
>> int f0/0
>> ip multicast boundary 11
>>
>> Sol 2
>> ********
>> access-li 12 deny 224.0.0.0 0 15.255.255.255
>> acess-li 12 per any
>>
>> int f0/0
>> ip multicast boundary 12 filter-autorp
>>
>> As far as i understand ; In sol2 i dont want any multicast traffic coming in
>> this interface and also i am denying auto-rp announce and discovery messages
>> out this interface.
>> Am i right ?
>>
>> Sol 3
>> *********
>>
>> access-li 11 deny 224.0.1.39 access-li 11 deny 224.0.1.40
>> access-li 11 per any
>>
>> int f0/0
>> ip multicast boundary 11 filter-autorp
>>
>> I am really confused with this "filter auto-rp " keyword now
>>
>>
>> Can someone explain the meaning of 3 sols given above
>>
>> Thnx in advance
>> gaurav madan.
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:11 ARST