Release Note
BSR RP election incompatibility with RFC2362

This release note was copied from CSCdy56806 for
the sake of readers without CCO accounts. It applies
to all Cisco IOS releases supporting BSR (12.0, 12.1, 12.2, ...)
09/2002

------------------------------------------------------------
The Cisco IOS implementation of PIM BSR (Bootstrap Router)
is incompatible with the specification in RFC2362 with
respect to the selection of an RP from a set of candidate
RPs: RFC2362 specifies that the RP has to be selected as
follows (RFC2362, 3.7):

   2. Highest Priority (lowest configured priority value)
   3. If 1. ties: Highest Hash function value
   4. If 2. ties: Highest IP address

In Cisco IOS, RP selection always includes a first step:
   1. Longest match on the announced group prefix

In result, this can lead to inconsistent RP selection
between Cisco and non-Cisco RFC2362 compliant routers
in the same domain if multiple RPs with partially overlapping
group address ranges are configured. Such inconsistent
RP selection can lead to disconnectivity between sources and
receivers in the PIM domain: A source may register with
one RP and a receiver may join towards another RP for the
same group, in result never seeing traffic from the source.

Example:

     access-list 10 permit 224.0.0.0  7.255.255.255 
     ip pim rp-candidate ethernet1 group-list 10 priority 20

     access-list 20 permit 224.0.0.0 15.255.255.255
     ip pim rp-candidate ethernet2 group-list 20 priority 10

The candidate RP on ethernet0 announces the longer group prefix
224.0.0.0/5 with a lower priority of 20, the candidate RP
on ethernet2 announces the shorter group prefix 224.0.0/4 with
a higher priority of 10. For all groups that match both
ranges (eg: 224.0.0.0/5) Cisco IOS will always select
the candidate RP on ethernet1 because of the longer announced
group prefix, a fully RFC2362 compliant router will always
select the candidate RP on ethernet2 because of the higher
priority.

Workaround:
To avoid this interoperability issue, do not configure
different candidate RPs to announce partially overlapping
address prefixes, but instead make sure that the address
prefixes that you want to announce from more than one
candidate RP have always the same lengths. For the above
example, this would mean to change the configuration as follows:

     access-list 10 permit 224.0.0.0  7.255.255.255 
     ip pim rp-candidate ethernet1 group-list 10 priority 20

     access-list 20 permit 224.0.0.0  7.255.255.255
     access-list 20 permit 232.0.0.0  7.255.255.255
     ip pim rp-candidate ethernet2 group-list 20 priority 10

The candidate RP on ethernet2 will now announce not 
224.0.0.0/4 but instead 224.0.0.0/5 and 232.0.0.0/5 which
also adds up to 224.0.0.0/4, but which makes it use the same
group prefix length of 5 as the candidate RP on ethernet 1.
In result, both Cisco IOS and RFC2362 compliant routers will
select the same RP (the one on ethernet2).

Note: This RFC2362 incompatibility in Cisco IOS will not
be fixed because the exclusion on the longest match prefix
rule (0.) in RFC2362 results in scalability and configuration
flexibility issues. The current draft version rewrite of 
RFC2362 which is meant to obsolete RFC2362 does include step 1.
From draft-ietf-pim-sm-v2-new-05.txt, section 4.8.1 (p100):

>    Implementation note: the bootstrap mechanism described in RFC
>    2362 omitted step (1) above.  However of the implementations
>    we are are of, approximately half performed step (1) anyway.
>    It should be noted that implementations of BSR that omit step
>    1 will not correctly interoperate with implementations of this
>    specification when used with the BSR mechanism described in
...  the updated version of the BSR mechanism.

As described above there is a simple configuration
workaround for this incompatibility!


.