RE: rp-announce-filter

From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Sat Dec 10 2005 - 16:50:29 GMT-3


If the candidate RP (cRP) asks for 228/8 and 229/8 but the MA is
allowing only 228/8 then the MA will filter the 229/8 and the cRP will
be the RP for just 228/8. If the cRP asks for say 224/4 but the MA is
only allowing 228/8 then the cRP's 224/4 announcement will be filtered
by the MA and the cRP will not be the RP for any groups.

HTH,

Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
 
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
 
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Cham
Sent: Saturday, December 10, 2005 10:33 AM
To: Schulz, Dave
Cc: nobody@groupstudy.com; Cisco certification
Subject: Re: rp-announce-filter

Dave

Looking at the explanation given in the IE solutions guide, my
understanding is that the RP has to request precisely what the MA is
filtering the RP for. If they don't match the MA will not map the RP
to any group  It all or nothing??

R8 is asking to be the RP for two groups 228 and 229, but the MA is
saying I have you down only for 229. So, my understanding it that as
this does not match precisely what the MA is mapping. R8 should not be
the RP for anything. But instead what I see is that it is mapping only
for the group they do agree on?? 229??

I suppose I need a sanity check is this expected behavior??

Thanks

On 12/10/05, Schulz, Dave <DSchulz@dpsciences.com> wrote:
>
>
> Cham -
>
> I believe that everything is working as it should with your R8
RP....as it
> is allowing the 229 group and filtering the 228 from this specific RP.
Are
> you expecting a different result?
>
> Dave
>
> -----Original Message-----
> From: nobody@groupstudy.com
> To: Cisco certification
> Sent: 12/10/2005 8:35 AM
> Subject: RE: rp-announce-filter
>
> Hi group,
>
> Just looking for some clarification on the ip pim rp-announce-filter
> command.
>
> R8-----------R10-------------R9
>
> R8
> ip pim send-rp-announce Loopback0 scope 16 group-list 20
> !
> access-list 20 permit 228.0.0.0 0.255.255.255
> access-list 20 permit 229.0.0.0 0.255.255.255
>
> R10
> ip pim send-rp-discovery Loopback0 scope 16
> ip pim rp-announce-filter rp-list R9_as_RP_only group-list 20
> ip pim rp-announce-filter rp-list R8_as_RP_only group-list 30
> !
> !
> ip access-list standard R8_as_RP_only
> permit 150.1.8.8
> ip access-list standard R9_as_RP_only
> permit 150.1.9.9
> access-list 20 permit 225.0.0.0 0.255.255.255
> access-list 20 permit 226.0.0.0 0.255.255.255
> access-list 30 permit 229.0.0.0 0.255.255.255
>
> R9
> ip pim send-rp-announce Loopback0 scope 16 group-list 10
> !
> access-list 10 permit 225.0.0.0 0.255.255.255
> access-list 10 permit 226.0.0.0 0.255.255.255
>
> I also have sparse-dense-mode on all ints and loopbacks. When R9 is
> requesting to be the RP for groups in ACL 10 and R10 is permitting R9
> as the RP for the groups for ACL 20  this works fine as I expected.
>
> My understanding is that if the RP is not requesting the same as what
> the MA is filtering the MA will discard all requests from the RP? By
> the "same" I mean nothing more - nothing less?? What I see is that R8
> is requesting to be the RP for groups in ACL 20 and the MA permitting
> R8 to be the RP for only some of the groups it is asking for?
>
> What I then see is the MA accepting this and just filtering the
> 228.0.0.0/8 group as this is no permitted within the R10s ACL30  I
> thought that this should not happen R10 should drop all requests from
> R8 as they do not match with what it is filtering?? I am trying to
> understand IE lab 5 tasks 7.1.-7.6?
>
> *Dec 10 13:23:05.295: Auto-RP(0): Received RP-announce, from
> 150.1.8.8, RP_cnt 1, ht 181
> *Dec 10 13:23:05.295: Auto-RP(0): Filtered 228.0.0.0/8 for RP
150.1.8.8
> *Dec 10 13:23:05.295: Auto-RP(0): Update (229.0.0.0/8, RP:150.1.8.8),
> PIMv2 v1
> *Dec 10 13:23:05.295: Auto-RP(0): Received RP-announce, from
> 150.1.8.8, RP_cnt 1, ht 181
> *Dec 10 13:23:05.295: Auto-RP(0): Filtered 228.0.0.0/8 for RP
150.1.8.8
> *Dec 10 13:23:05.295: Auto-RP(0): Update (229.0.0.0/8, RP:150.1.8.8),
> PIMv2 v1
> R10#sh ip pim
> *Dec 10 13:23:11.739: Auto-RP(0): Received RP-announce, from
> 150.1.9.9, RP_cnt 1, ht 181
> *Dec 10 13:23:11.739: Auto-RP(0): Update (225.0.0.0/8, RP:150.1.9.9),
> PIMv2 v1
> *Dec 10 13:23:11.739: Auto-RP(0): Update (226.0.0.0/8, RP:150.1.9.9),
> PIMv2 v1
> *Dec 10 13:23:11.739: Auto-RP(0): Received RP-announce, from
> 150.1.9.9, RP_cnt 1, ht 181
> *Dec 10 13:23:11.739: Auto-RP(0): Update (225.0.0.0/8, RP:150.1.9.9),
> PIMv2 v1
> *Dec 10 13:23:11.739: Auto-RP(0): Update (226.0.0.0/8, RP:150.1.9.9),
> PIMv2 v1
> *Dec 10 13:23:12.463: Auto-RP(0): Build RP-Discovery packet
> *Dec 10 13:23:12.463: Auto-RP: Build mapping (225.0.0.0/8,
> RP:150.1.9.9), PIMv2 v1,
> R10#sh ip pim r
> *Dec 10 13:23:12.463: Auto-RP: Build mapping (226.0.0.0/8,
> RP:150.1.9.9), PIMv2 v1.
> *Dec 10 13:23:12.463: Auto-RP: Build mapping (229.0.0.0/8,
> RP:150.1.8.8), PIMv2 v1.
> *Dec 10 13:23:12.463: Auto-RP(0): Send RP-discovery packet on
> GigabitEthernet4/0/0 (2 RP entries)
> *Dec 10 13:23:12.463: Auto-RP(0): Send RP-discovery packet on
> FastEthernet0/0/0 (2 RP entries)
> *Dec 10 13:23:12.463: Auto-RP: Send RP-discovery packet on Loopback0
> (2 RP entries)
>
> Thanks,
> Cham
>
>



This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3