From: Gupta, Gopal (NWCC) (gopal.gupta@hp.com)
Date: Wed Feb 06 2008 - 15:13:59 ARST
If you need to filter the bogus RPs from advertising then you need to
filter on the MA otherwise filtering on the RPs itself is more than
enough.
HTH
Gops
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Dan Holme
Sent: Wednesday, February 06, 2008 05:47
To: gs-ccie
Subject: Auto-RP group filtering
Importance: Low
Hello folks
In a lot of workbook scenarios where one RP is allocated for one block
of multicast groups and another RP for the rest, there is typically
filtering on the RPs themselves, to ensure the RPs only send the
relevant groups in their announcements to the mapping-agent. This is
fine.
ie. ip pim send-rp-announce loopback0 scope 16 group-list 1
access-list 1 permit 224.0.0.0 7.255.255.255
However, in these workbooks, there is also matching filtering on the
mapping-agent, acting as an ingress filter to the announcements from the
RP(s).
ie. ip pim send-rp-discovery loopback0 scope 16
ip pim rp-announce-filter rp-list R1 group-list 1
access-list 1 permit 224.0.0.0 7.255.255.255
ip access-list standard R1
permit 150.1.1.1
My question is, providing you are not trying to filter out bogon or
unnecessary groups within announcements that you don't have control
over, what is the point in putting the filtering on both ends?
I feel like I'm missing something, but I'm probably just being paranoid
:-) It seems it could add a little unnecessary configuration time in the
lab. The filtering works just fine when I only filter the egress RP
announcements from the actual RP(s) themselves.
D
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2008 - 16:54:47 ARST