From: Ivan (ivan@iip.net)
Date: Mon Apr 23 2007 - 08:50:40 ART
rp-announce filtering act like ordinary ACL. MA check each statement one to
one in enter order.
First check against rp-list.
permit) If item permit to rp-list -> next check is group-list.
permit) If group permit then MA advertise mapping
deny) if group deny then MA forbid this mapping
deny) If item deny at rp-list -> MA check the next ip pim rp-announce-filter
statement
Once we see inside work, trying to explain what happen in Your example
Bradley.
> 1) If you want to filter out a specific RP (notice this DENIES, not accepts
the announcements as the DocCD states):
> > R4(config)#do sri pim
> > ip pim send-rp-discovery Loopback104 scope 16
> > ip pim rp-announce-filter rp-list 1 group-list 2
> > R4(config)#do sri access
> > access-list 1 permit 172.16.103.1
> > access-list 2 permit 231.1.1.1
> > R4(config)#do sh ip pi rp
> > Group: 231.1.1.1, RP: 172.16.101.1, v2, v1, uptime 00:02:50, expires
> > 00:02:05
Two cRP (172.16.103.1 & 172.16.101.1) announce the same group.
Attention !!!! I think they announce 224/4 not 231.1.1.1/32.
Suppose first message from R1 - MA see (224/4, RP:172.16.101.1)
MA check is there any statement with RP equal 172.16.101.1. NO !
Permit any advertisment from it.
After that MA receive (224/4, RP:172.16.103.1) from R3.
R4 see that ACL 1 permit check advertisment from R3 and that adv permit only
if match 231.1.1.1/32. But R3 announce 224/4 - this explicitly "deny any" by
ACL1
Therefore you see such mapping at R4.
> 2) If you want to accept announcements from just one RP and deny the rest
> (at least one way of doing this):
>
> R4(config)#do sri pim
> ip pim send-rp-discovery Loopback104 scope 16
> ip pim rp-announce-filter rp-list 1 group-list 2
> R4(config)#do sri access
> access-list 1 deny 172.16.101.1
> access-list 1 permit any
> access-list 2 deny 231.1.1.1
> R4(config)#do sh ip pim rp
> Group: 231.1.1.1, RP: 172.16.101.1, v2, v1, uptime 00:16:32, expires
> 00:02:27
The same logic here.
Announce from R1 (224/4, RP:172.16.101.1) not checked by MA. Such as deny
statement in rp-list. And permit any adv from this cRP.
Announce from R3 (224/4, RP:172.16.103.1) checked by MA, but acl 2 deny any
advertisment from it.
acl 2 deny 231.1.1.1
acl 2 deny any.
Therefore you see R1 as RP again.
The big deal in understanding this mechanism is debug ip pim autorp command.
On Sunday 22 April 2007 20:39, Riapolov, Bradley wrote:
> Thanks to all for the input. Below is the summary for those who are
> interested:
>
> DocCD says:
> (http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/himc
>_r/mlt_i2h.htm#wp1069977) "...The following example configures the router to
> accept RP announcements from RPs in access list 1 for group ranges
> described in access list 2: ip pim rp-announce-filter rp-list 1 group-list
> 2
> access-list 1 permit 10.0.0.1
> access-list 1 permit 10.0.0.2
> access-list 2 permit 224.0.0.0 192.168.255.255..."
>
> According to Cisco's example, the MA should accept RP accouncements from
> RPs in ACL1 destined to Multicast groups in ACL2. This does not appear to
> be the case on my rack!!! If someone can get this to work this way, please
> email me - I would like to find out what I am doing wrong. Here is what I
> have found (I have labbed it up, debugged it every step of the way and this
> is how it worked on my rack):
>
> 1) If you want to filter out a specific RP (notice this DENIES, not accepts
the announcements as the DocCD states):
> > R4(config)#do sri pim
> > ip pim send-rp-discovery Loopback104 scope 16
> > ip pim rp-announce-filter rp-list 1 group-list 2
> > R4(config)#do sri access
> > access-list 1 permit 172.16.103.1
> > access-list 2 permit 231.1.1.1
> > R4(config)#do sh ip pi rp
> > Group: 231.1.1.1, RP: 172.16.101.1, v2, v1, uptime 00:02:50, expires
> > 00:02:05
>
> 2) If you want to accept announcements from just one RP and deny the rest
> (at least one way of doing this):
>
> R4(config)#do sri pim
> ip pim send-rp-discovery Loopback104 scope 16
> ip pim rp-announce-filter rp-list 1 group-list 2
> R4(config)#do sri access
> access-list 1 deny 172.16.101.1
> access-list 1 permit any
> access-list 2 deny 231.1.1.1
> R4(config)#do sh ip pim rp
> Group: 231.1.1.1, RP: 172.16.101.1, v2, v1, uptime 00:16:32, expires
> 00:02:27
>
> I would like to be proven wrong if I am (and will take it like a man :) ) -
> I am sure we will all learn in the process. I am usually not in the habit
> of going against the DocCD, but would like to know if I misunderstand the
> topic. Also, please lab this up. The scenario is tricky since both
> 172.16.101.1 and 172.16.103.1 are announcing they are the RP - so the MA
> (172.16.104.1) will want to choose 172.16.103.1 because of the higher ip!
> The end result is to advertise 172.16.101.1 as the RP of choice and block
> other RPs.
>
> -----Original Message-----
> From: ivan [mailto:ivan@iip.net]
> Sent: Sunday, April 22, 2007 9:57 AM
> To: ccielab@groupstudy.com; Riapolov, Bradley
> Cc: Narbik Kocharians
> Subject: Re: RP-filtering - what am i missing?
>
>
>
> RP filtering is extraordinary thing (IMO). If you want to filter all group
> from all fake RP except CRP 172.16.103.1 and group 231.1.1.1
>
> Filter must look like
> ip pim send-rp-discovery Loopback104 scope 16
> ip pim rp-announce-filter rp-list 1 group-list 2
> ip pim rp-announce-filter rp-list 3 group-list 4
> R4(config)#do sri access
> access-list 1 permit 172.16.103.1
> access-list 2 permit 231.1.1.1
> access-list 3 permit any
> access-list 4 deny any
>
> MA listen update from CRP 172.16.103.1 and permit to advrtise information
> about 231.1.1.1 group. Also MA listen advertisment from any CRP (ACL3) but
> deny advertising any information (ACL4) from this CRP.
>
> On Saturday 21 April 2007 22:00, Riapolov, Bradley wrote:
> > interesting observation. Thank you. I finally got this to work with a
> > lot simpler config - thanks everybody. All you have to do is just filter
> > the traffic you do not want.
> >
> > R4(config)#do sri pim
> > ip pim send-rp-discovery Loopback104 scope 16
> > ip pim rp-announce-filter rp-list 1 group-list 2
> > R4(config)#do sri access
> > access-list 1 permit 172.16.103.1
> > access-list 2 permit 231.1.1.1
> > R4(config)#do sh ip pi rp
> > Group: 231.1.1.1, RP: 172.16.101.1, v2, v1, uptime 00:02:50, expires
> > 00:02:05
> >
> >
> >
> > -----Original Message-----
> > From: Narbik Kocharians [mailto:narbikk@gmail.com]
> > Sent: Saturday, April 21, 2007 11:59 AM
> > To: Riapolov, Bradley
> > Cc: ccielab@groupstudy.com
> > Subject: Re: RP-filtering - what am i missing?
> >
> >
> > This is what i found when i tried filtering. If the RP was claiming to be
> > the RP for only two Mcast groups, the downstream router (The mapping
> > agent) was able to filter one of the groups. But if the RP was the RP for
> > all groups i could not filter one of the group addresses successfuly.
> >
> > On 4/21/07, Riapolov, Bradley < BRiapolo@wm.com> wrote:
> >
> > Two RPs ( 172.16.101.1, 172.16.103.1), R4 is mapping and has elected the
> > highest ip as the acting RP. Now, I would like to test RP-FILTERING with
> > the intent to make 172.16.101.1 the RP - it does not work, why - am I
> > missing how this is supposed to work? When I run debug ip pim auto-rp,
> > filtering does not happen!
> > R4#sri pim
> > ip pim send-rp-discovery Loopback104 scope 16
> > ip pim rp-announce-filter rp-list 1 group-list 2
> > ip pim rp-announce-filter rp-list 3 group-list 4
> > R4#sri access-list
> > access-list 1 permit 172.16.101.1
> > access-list 2 permit 224.0.0.0 15.255.255.255
> > access-list 3 deny any
> > access-list 4 deny any
> >
> > R4(other routers show the same info) #sh ip pim rp
> > Group: 231.1.1.1, RP: 172.16.103.1, v2, v1, uptime 00:11:55, expires
> > 00:02:0
> >
> > Thank you,
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> > <http://www.groupstudy.com/list/CCIELab.html>
> >
> >
> >
> >
> >
> > --
> > Narbik Kocharians
> > CCIE# 12410 (R&S, SP, Security)
> > CCSI# 30832
> > Network Learning, Inc. (CCIE class Instructor)
> > www.ccbootcamp.com <http://www.ccbootcamp.com> (CCIE Training)
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue May 01 2007 - 08:28:37 ART