From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Sep 22 2004 - 12:17:55 GMT-3
Hi guys,
I found this while working on IE Lab 5, task 7.1 - 7.5
The requirement is for Auto-RP with R1 to be the MA and R1 and R5 to be RP's
for selected mcast groups.
In particular, R1 is to be the RP for groups 239.0.0.0 thru 239.255.255.255
and
R5 is to be the RP for groups 226.0.0.0 thru 238.255.255.255
In addition, R1 (the MA) should be configured such that it guarantees these
group to RP mappings - in other words, R1 should be configured
with the ip pim rp-announce-filter command to prevent either R3 or R5 from
becoming the RP for groups other than what was specified above.
In addition, R1 must be configured with the fewest number of acl entries as
possible.
After doing some binary math, here are the acl's needed on R1 with respect to
R5 (lo0 = 150.1.5.5 )
R1 (the MA)
ip pim send-rp-discovery Loopback 0 scope 16 <-- Makes R1 the MA
ip pim rp-announce-filter rp-list 50 group-list 51 <-- Specifies the address
of the RP & what groups it can be the RP for.
access-list 50 permit 150.3.5.5
access-list 51 deny 224.0.0.0 1.255.255.255
access-list 51 deny 239.0.0.0 0.255.255.255
access-list 51 perm 224.0.0.0 15.255.255.255
Now, look at acl 51. If you do the binary, you can see that, in fact, this
acl will allow mcast groups 226.0.0.0 thru 238.255.255.255
which is what the requirement specified. I soon discovered some interesting
things.
1) It's not enough to configure the MA with which RP can be used for which
mcast groups. The RP's config must be consistent with the MA's config. In
other words, if the RP is configured with the default mcast groups which is
all groups, the MA doesn't accept the groups that it is configured with, it
rejects that RP for all groups. I didn't like that.
2) If you use the same acl on the RP to specify for which groups it should be
the RP as was used on the MA above, it doesn't work. I especially didn't lilke
that. Apparently, the acl used in the command, ip pim send-rp-announce scope
16 group-list 50, is no good because it includes deny statements.
access-list 50 deny 224.0.0.0 1.255.255.255
access-list 50 deny 239.0.0.0 0.255.255.255
access-list 50 permit 224.0.0.0 15.255.255.255
Instead of the above the acl, the acl below is required.
access-list 50 permit 226.0.0.0 1.255.255.255
access-list 50 permit 228.0.0.0 3.255.255.255
access-list 50 permit 232.0.0.0 3.255.255.255
access-list 50 permit 236.0.0.0 1.255.255.255
access-list 50 permit 238.0.0.0 0.255.255.255
So, here are 2 questions:
A) Is there anyone who can verify or discredit the above finding regarding
deny entries in the acl being no good in this scenario?
B) Assuming this is true, why is that?
To me, it doesn't make sense that the first acl won't work, but the 2nd one
will. So, I'm wondering if anyone has a logical explanation for that.
Thanks, Tim
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:47 GMT-3