In ine workbook they have first created negative mapping in MA.
on RP the acl is something like this
Access-list 1 deny 224.110.110.110
access-list 1 permit 224.0.0.0 15.255.255.255
In MA it appears as (-) 224.110.110.110
and filtering works fine .
the trick here is the acl on RP must match the acl on MA .
if PR advertises his willingness to serve complete block say 224.0.0.0/4
MA cannot do filering on specific subset of groups here. That is if
Candidate RP's adveritsements overlap with denied groups entires block
will be denied.
So on GNS i split up the advirtisments on RP.
Let say 224.0.0.0 7.255.255.255
and 232.0.0.0 7.255.255.255
and on ma i matched exaclty and denied it from advertisments and it
worked as expected.
On Wed, Mar 27, 2013 at 7:24 AM, ccie99999 <ccie99999_at_gmail.com> wrote:
> Actually I've never seen this filter working fine on dynagen/gns3..
> are you using real-gear?
>
> I've just re-tested this in my lab and debbugging ip pim auto-rp I always
> have this:
>
> Auto-RP(0): Received RP-discovery packet of length 48, from 155.1.146.6,
> RP_cnt 1, ht
> Auto-RP(0): Update (224.0.0.0/4, RP:155.1.146.6), PIMv2 v1
>
> doesn't matter if my acl is something like yours or this one:
>
>
> Standard IP access list 2
> 10 deny 224.110.110.110
> 20 permit any (2 matches)
>
> I'm filtering on MA of course.
>
> I think it's just a dynagen issue.
> According to INE vol 1 I should get something like this:
>
> Rack1R5#debug ip pim auto-rp
>
> Auto-RP(0): Filtered -224.110.110.110/32 for RP 150.1.10.10
>
> Auto-RP(0): Update (232.0.0.0/5, RP:150.1.10.10), PIMv2 v1
>
> Auto-RP(0): Update (224.0.0.0/4, RP:150.1.10.10), PIMv2 v1
>
> someone else can help here and confirm what I've written?
>
>
>
>
>
> On Mon, Mar 25, 2013 at 8:21 PM, Imran Ali <immrccie_at_gmail.com> wrote:
>
>> when i split RP announcements with group list containing two
>> statements
>> 224.0.0.0 7.255.255.255
>> 232.0.0.0 7.255.255.255
>>
>> AND started filting on ma and it was successfull.
>>
>> i need confirmation if this is noramal .... MA can filter only if
>> candidate RP announcements maches exaclty the filtering acl by MA .else
>> entire block is blocked :)
>>
>>
>>
>>
>> On Mon, Mar 25, 2013 at 11:02 PM, Imran Ali <immrccie_at_gmail.com> wrote:
>>
>> > Hi all.
>> >
>> > i have a basic topology ... R3------R1
>> >
>> > R3 is advertising himself as rp for complete block ...
>> > ip pim send-rp-announce lo 0 scope 10 interval 5
>> >
>> > R1 the mapping agent ..wants to filter groups from R3 ...ie R3
>> sould
>> > only service 232.0.0.0 7.255.255.255
>> >
>> > so here what i did on R1 the MA
>> > R1#conf t
>> > Enter configuration commands, one per line. End with CNTL/Z.
>> >
>> > R1(config)#access-list 2 deny 224.0.0.0 7.255.255.255
>> >
>> > R1(config)#access-list 2 permit 232.0.0.0 7.255.255.255
>> > R1(config)#exit
>> >
>> > ip pim autorp listener
>> > ip pim send-rp-discovery FastEthernet0/0 scope 10
>> > ip pim rp-announce-filter rp-list 1 group-list 2
>> >
>> > R1#show ip pim rp map
>> >
>> > PIM Group-to-RP Mappings
>> > This system is an RP-mapping agent (FastEthernet0/0)
>> > R1#show ip pim rp map
>> >
>> > PIM Group-to-RP Mappings
>> > This system is an RP-mapping agent (FastEthernet0/0)
>> >
>> > R1#show access-lists
>> > Standard IP access list 1
>> > 10 permit 13.0.0.3 (140 matches)
>> >
>> > Standard IP access list 2
>> > 10 deny 224.0.0.0, wildcard bits 7.255.255.255 (20 matches)
>> > 20 permit 232.0.0.0, wildcard bits 7.255.255.255
>> >
>> > As you can see denying only a subset of 224.0.0.0 is making it
>> > deny complete block ...
>> >
>> > is this normal behavior ??
>> >
>> > Can any one try the same requirmnet and see if it works
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> @ccie99999
> https://twitter.com/ccie99999
Blogs and organic groups at http://www.ccie.net
Received on Wed Mar 27 2013 - 07:50:14 ART
This archive was generated by hypermail 2.2.0 : Wed Apr 03 2013 - 19:06:19 ART