Configuring Multicast routing with PIM Sparse-Mode (Part 3): Bootstrap Router (BSR)
In the previous multicast post we configured the RP statically. If we have a lot of routers this solution is not going to be scalable because we have to configure the address of the RP manually on every router. To dynamically select the RP we have 2 methods to choose from: Cisco Auto-RP, or BSR. BSR is the industry standard and it is part of the PIMv2 protocol. Its main advandatage over AutoRP is that BSR doesn't need to use dense-mode flooding to distribute RP information. Just like Auto-RP BSR has two roles: Candiate BSR (Mapping Agent in Auto-RP) and Candidate RPs. Now let's take a look how BSR works and how we can configure it by using the same topology as in the previous labs:
Just as in the previous labs: I've already enabled ip muticast-routing distributed globally and configured ip pim sparse-mode on every interface on each CSR. First let's configure CSR2 as our candidate RP:
CSR2(config)#ip pim rp-candidate lo0 group-list 1CSR2(config)#ip pim rp-candidate lo0 group-list 1 priority ? <0-255> Priority value
We usually use the loopback interfaces for the RP address, we can also restrict which multicast groups we want CSR2 to be the RP for by configuring a standard ACL:
CSR2(config)#access-list 1 permit 239.0.0.0 0.255.255.255
Here we configure CSR2 to be an RP for the 239.0.0.0/8 address block.
CSR2(config)#ip pim rp-candidate lo0 group-list 1 priority 100
We can also configure a priority with the RP: with BSR we actually prefer the lower priority, so lower priority RPs are preferred to higher priority RPs. (Actually that's not always true we'll see it later.) So I issued this command above and I got the following message:
Warning: PIMv2 not configured on Loopback0, Candidate-RP not advertised
We actually have to enable PIM SM on the loopback interface as well:
CSR2(config)#int lo0CSR2(config-if)#ip pim sparse-mode
Now we have a candidate RP, but this command above just by itself doesn't do anything: we need a BSR, a router which is going to be advertising the address of the RP (or multiple RPs). So let's make CSR1 the BSR:
CSR1(config)#ip pim bsr-candidate loopback 0 ? <0-32> Hash Mask length for RP selection <cr> <cr>CSR1(config)#ip pim bsr-candidate loopback 0 32 ? <0-255> Priority value for candidate bootstrap router <cr> <cr>CSR1(config)#ip pim bsr-candidate loopback 0 32 1 ? accept-rp-candidate BSR RP candidate filter <cr> <cr>CSR1(config)#ip pim bsr-candidate loopback 0 32 1
Here just like with the RP candidate, we also have to enable PIM SM on the looback interface. We can associate a hash mask length with the BSR (more on this later), and a priority. Unlike the RPs we can only have a single active BSR, and the higher priority BSR is preferred. We can also restrict with an ACL from which addresses does the BSR accept the the candidate RP advertisements. Now after issuing this command, CSR1 starts sending the Bootstrap messages to 224.0.0.13 by using PIM itself. Neighboring PIM routers learn the address of the BSR and simply forward these messages (after the RPF check) to other routers. Unlike Auto-RP, BSR doesn't require dense-mode flooding, to distribute BSR or RP information, this feature is included in the PIMv2 protocol itself. After the routers learn the BSR address, the candidate RP sends an announcement to the BSR. Notice that this message is actually unicast:
Then the BSR starts advertising the RP's address periodically for the 239.0.0.0/8 block in PIM Bootstrap messages:
Now all routers running PIM have learned who the RP is, let's verify on CSR3:
CSR3#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 10.1.1.1 (?) Uptime: 00:04:23, BSR Priority: 1, Hash mask length: 32 Expires: 00:01:50CSR3#show ip pim rp mapping PIM Group-to-RP MappingsGroup(s) 239.0.0.0/8 RP 10.2.2.2 (?), v2 Info source: 10.1.1.1 (?), via bootstrap, priority 100, holdtime 150 Uptime: 00:03:22, expires: 00:02:23
What if we want to configure multiple RPs for both redundancy and load-balancing purposes? Let's configure CSR3 as an RP-candidate as well, but this time for the whole multicast address block and with lower priority (remember lower priority takes precedence over higher priority):
CSR3(config)#ip pim rp-candidate lo0 priority 1
Now the BSR (CSR1) is actually advertising both RPs address in the Bootstrap messages for their respective multicast address block and priority:
CSR5#show ip pim rp mapping PIM Group-to-RP MappingsGroup(s) 224.0.0.0/4 RP 10.3.3.3 (?), v2 Info source: 10.1.1.1 (?), via bootstrap, priority 1, holdtime 150 Uptime: 00:01:19, expires: 00:01:58Group(s) 239.0.0.0/8 RP 10.2.2.2 (?), v2 Info source: 10.1.1.1 (?), via bootstrap, priority 100, holdtime 150 Uptime: 00:07:51, expires: 00:01:57
So the PIM routers can decide individually which RP to use. But actually to which RP sends CSR5 his PIM Join? Let's take a look: R6 sends and IGMP Membership Report to CSR5 for the group address of 239.1.1.1:
R6(config-if)#ip igmp join-group 239.1.1.1
This triggers a PIM Join from CSR5 towards the RP to build the (*,G) tree. Although CSR1 has lower priority (which is preferred), actually CSR5 sends his PIM Join towards CSR2:
CSR5 does this because CSR2's multicast group block is more specific (239.0.0.0/8) than CSR1's (224.0.0.0/4). So the logest match (more specific block) is considered first, if they are equal the priority is the next tiebreaker: the RP with the lower priority is chosen over the high priority RP. If the priorities are also equal then the RP with the highest hash value is chosen: the routers use the hash mask lenght (provided by the BSR) and other inputs to calculate the hash function. Let's take a look how it works:
CSR2(config)#no ip pim rp-candidate lo0 group-list 1 priority 100CSR3(config)#no ip pim rp-candidate lo0 priority 1CSR2(config)#ip pim rp-candidate lo0CSR3(config)#ip pim rp-candidate lo0
I removed the current RP configuration from both CSR2 and CSR3, and configured both routers as RP candidates for the whole multicast address block with equal priorities (which is 0 by default):
CSR5#show ip pim rp mapping PIM Group-to-RP MappingsGroup(s) 224.0.0.0/4 RP 10.2.2.2 (?), v2 Info source: 10.1.1.1 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:00:31, expires: 00:02:05 RP 10.3.3.3 (?), v2 Info source: 10.1.1.1 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:00:38, expires: 00:02:02
Now if CSR5 wants to select an RP for a multicast address the output of the hash function is going to be the tiebreaker. Let's take a look how it works: currently the hash mask length is 32 bits as it was configured on the BSR earlier. Let's check on CSR5 which RP is serving which multicast group:
CSR5#show ip pim rp-hash 239.0.0.0 RP 10.3.3.3 (?), v2 Info source: 10.1.1.1 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:05:47, expires: 00:01:58 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 366972248 RP 10.3.3.3, via bootstrap, priority 0, hash value 1758768107CSR5#show ip pim rp-hash 239.0.0.1 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 846936589 RP 10.3.3.3, via bootstrap, priority 0, hash value 150795642CSR5#show ip pim rp-hash 239.0.0.2 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 336300150 RP 10.3.3.3, via bootstrap, priority 0, hash value 1516489993CSR5#show ip pim rp-hash 239.0.0.3 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 1859758227 RP 10.3.3.3, via bootstrap, priority 0, hash value 467962368CSR5#show ip pim rp-hash 239.0.0.4 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 1349121788 RP 10.3.3.3, via bootstrap, priority 0, hash value 2045262735CSR5#show ip pim rp-hash 239.0.0.5 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 1379882929 RP 10.3.3.3, via bootstrap, priority 0, hash value 199693086CSR5#show ip pim rp-hash 239.0.0.6 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 799555098 RP 10.3.3.3, via bootstrap, priority 0, hash value 43867309CSR5#show ip pim rp-hash 239.0.0.7 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.255) RP 10.2.2.2, via bootstrap, priority 0, hash value 408012343 RP 10.3.3.3, via bootstrap, priority 0, hash value 1647749028
For 239.0.0.0 CSR3 is the RP because the highest hash value is preferred, for 239.0.0.1 CSR2 is the RP, for 239.0.0.2 CSR3 again. Each multicast group is served by a different RP. So if you have many multicast groups, that need to be served, and they are relatively close to each other the best option for load balancing is the 32 bit hash mask. Otherwise with lower hash mask length the result is difficult to predict, it can be completely random, your best option is to experiment with it. But let's take another example: we configure a second BSR. Unlike the RP, we can only have a single active BSR: higher priority is preferred here, in case of a tie the BSR with a higher IP address is preferred.
We make CSR4 the active BSR since it's going to have a higher priority than CSR1:
CSR4(config)#ip pim bsr-candidate lo0 ? <0-32> Hash Mask length for RP selection <cr> <cr>CSR4(config)#ip pim bsr-candidate lo0 30 ? <0-255> Priority value for candidate bootstrap router <cr> <cr>CSR4(config)#ip pim bsr-candidate lo0 31 200
Let's verify it on CSR5:
CSR5#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 10.4.4.4 (?) Uptime: 00:00:17, BSR Priority: 200, Hash mask length: 31 Expires: 00:01:52
Now CSR4 is the active BSR and the hash mask length is now 31 bits. Let's take a look how does this change the RP selection for CSR5:
CSR5#show ip pim rp-hash 239.0.0.0 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 366972248 RP 10.3.3.3, via bootstrap, priority 0, hash value 1758768107CSR5#CSR5#show ip pim rp-hash 239.0.0.1 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 366972248 RP 10.3.3.3, via bootstrap, priority 0, hash value 1758768107CSR5#CSR5#show ip pim rp-hash 239.0.0.2 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 336300150 RP 10.3.3.3, via bootstrap, priority 0, hash value 1516489993CSR5#CSR5#show ip pim rp-hash 239.0.0.3 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 336300150 RP 10.3.3.3, via bootstrap, priority 0, hash value 1516489993CSR5#CSR5#show ip pim rp-hash 239.0.0.4 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 1349121788 RP 10.3.3.3, via bootstrap, priority 0, hash value 2045262735CSR5#CSR5#show ip pim rp-hash 239.0.0.5 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 1349121788 RP 10.3.3.3, via bootstrap, priority 0, hash value 2045262735CSR5#CSR5#show ip pim rp-hash 239.0.0.6 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 799555098 RP 10.3.3.3, via bootstrap, priority 0, hash value 43867309CSR5#CSR5#show ip pim rp-hash 239.0.0.7 | beg PIMv2 PIMv2 Hash Value (mask 255.255.255.254) RP 10.2.2.2, via bootstrap, priority 0, hash value 799555098 RP 10.3.3.3, via bootstrap, priority 0, hash value 43867309
Now the hash value is the same for 239.0.0.0 and 239.0.0.1 multicast groups, and again the same for 239.0.0.2 and 239.0.0.3 etc... In this example groups between 239.0.0.0 - 239.0.0.5 are served by CSR3, and 239.0.0.6 and 239.0.0.7 are served by CSR2. It can be seen that the 32 bit hash mask was a better option for 1:1 load balancing for these addresses. Generally if you have many multicast groups the best option is the 32 bit hash mask. The value of the hash is very difficult to predict, the RP's IP address and the multicast group address are also used as inputs for the hash function. The best option is just to experiment with it, like I did above, but in most of the cases the 32 bit hash mask will be the best option.