WB1 8.19 BSR - Multiple RP Candidates

8.19 BSR - Multiple RP Candidates

• Configure SW2 and SW4 to advertise themselves as RP candidates for all
multicast groups.
• R5 should distribute this information and instruct all routers to loadbalance
multicast groups between the two RPs.
• Use the maximum possible hash mask length to evenly distribute the load
across the RPs.

--------------------------------------------------------------------------------------------------

As mentioned in the previous task, BSR protocol distributes multicast group
ranges along with the RP-Set information. This allows the multicast routers to
effectively load-balance among multiple RPs using a special procedure. This
procedure is deterministic, and ensures that for a given group ALL multicast
routers will select the same RP. This is needed to make sure a source for a given
group will not register to an RP that is not selected for this group. Here is how the
procedure works.

Input: Group Address (G), RP-Set (R1, R2… Rn), Mask (distributed by BSR).

1) Among the routers in the RP-Set, select those that have the numerically
lowest priority values. By default all cRPs advertise a priority of zero, so they all
are eligible. You may adjust the priority and take some of the RPs out of service
gracefully.

2) For every RP IP address, calculate the hash function value:

value1 = Hash(G&Mask, R1), value2 = Hash(G&Mask, R2) … valueN =
Hash(G&Mask,Rn).

Notice that the Group IP address is ANDed with the Mask value. The mask value
is propagated by the BSR using the hash-mask-length parameter. Thus, only
first hash-mask-length bits of the Group are used to calculate the hash value.
The default value is zero – i.e. the group IP address is ignored when computing
the hash value and all groups map to the same RP.

3) Select the RP with the highest hash function value for a given group. If the
values are the same, select the RP with the highest IP address.

Using this “pseudo-random” selection procedure, the whole multicast address
space is partitioned among different RPs. Every RP will get approximately 2^[32-
hash-mask-length] groups assigned, provided that there is enough RPs to
evenly distribute the load.

BSR protocol implements an automatic failover procedure. If any one of the RPs
were to fail, the BSR will exempt it from bootstrap messages and automatic
failover will occur. The failover delay is based on the RP/BSR advertisement
intervals. Naturally, if there are redundant BSRs, and the primary fails, the
secondary would revive and take its role.

In this task, odd/even groups are distributed among two RPs, both covering the
same group ranges, based on the hash mask length of 31 bits. This ensures the
load is evenly distributed among the two RPs.

R5:
no ip pim rp-candidate Loopback0
ip pim bsr-candidate Loopback0 31

SW2:
ip pim rp-candidate Loopback0

SW4:
ip pim rp-candidate Loopback0

--------------------------------------------------------------------------------------------------

You can quickly find which RP will be selected for a given group by using the
show ip pim rp-hash command. For example:


Rack1R5#show ip pim rp-hash
*Mar  2 09:44:34.539: PIM-BSR(0):  RP 150.1.10.10, 1 Group Prefixes, Priority 0, Holdtime 150
Rack1R5#show ip pim rp-hash 239.1.1.1
  RP 150.1.10.10 (?), v2
    Info source: 155.1.108.10 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:01:08, expires: 00:02:21
  PIMv2 Hash Value (mask 255.255.255.254)
    RP 150.1.10.10, via bootstrap, priority 0, hash value 989207280
    RP 150.1.8.8, via bootstrap, priority 0, hash value 718054422

Rack1R5#show ip pim rp-hash 239.1.1.2
  RP 150.1.8.8 (?), v2
    Info source: 155.1.58.8 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:01:32, expires: 00:01:57
  PIMv2 Hash Value (mask 255.255.255.254)
    RP 150.1.10.10, via bootstrap, priority 0, hash value 1093093598
    RP 150.1.8.8, via bootstrap, priority 0, hash value 1364246456
Rack1R5#

Notice the RP selected for the group and the hash function values.