The previous article in our multicast series focused on the concepts and configuration of Auto RP – the Cisco proprietary way of announcing RP information. In this article, we will focus on BSR (Bootstrap Router) which is the industry standard of disseminating RP mappings.

BSR uses a similar concept with Auto RP with some minor differences. We have learned that Auto RP uses Dense mode for candidate RPs to announce themselves to the mapping agents and the mapping agents use dense mode as well to announce RP mappings to other routers. BSR uses a method of flooding PIM messages on a per hop basis. When a router receives a candidate RP announcement through these PIM messages, it verifies the announcement through an RPF check. It will validate if the announcement was received on the interfaces that has the shortest path back to the RP where this PIM message originate. If it passes the RPF check, it will flood this PIM message on all interfaces configured with PIM.

BSR also has its concept of the Mapping Agents (MA) and it’s basically called the bootstrap router. Like the MA, this device listens to candidate RP announcements but it doesn’t elect the best RP for a specific multicast group. It builds information on the candidate RPs for every multicast group range. This information is disseminated the same way as the process of candidate RP announcements – through PIM messages flooding. BSRs can be configured with priority that will be included in the BSR messages. The default priority is 0 and the higher the priority, the more preferred the BSR. If the priority is the same, then the one with a higher IP address will be more preferred. If one BSR receives another BSR with a better priority than it has, it will stop its own BSR announcements. This router will only resume sending messages once it stops hearing these BSR announcements that have better priority than it has. The routers will then receive the messages from the best BSR router and the routers themselves will elect the best RP.

Now let’s proceed to configure BSR on our lab. The tasks will be the following:

  1. Configure ‘ip pim sparse-mode’ on all of the interfaces of all routers.
  2. R3 and R4 should be configured as candidate RP for all multicast groups. R1 and R2 will be the bootstrap routers. All the messages should be sourced from the Loopback0 interface.
  3. Make sure R3 becomes the RP for all multicast groups. R1 should also become the BSR. Do not configure R1 and R3 to accomplish this.
  4. R4 should become the RP for multicast group 239.1.1.0/24.
  5. Ensure that R6 does not receive or learn any RP information.

Task 1: Configure ‘ip pim sparse mode’ on all of the interfaces of all routers.

R1(config)#ip multicast-routing
R1(config-if)#int fa0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#int fa0/1
R1(config-if)#ip pim sparse-mode
R1(config-if)#int fa1/0
R1(config-if)#ip pim sparse-mode

R2(config)#ip multicast-routing
R2(config)#int fa0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int fa0/1
R2(config-if)#ip pim sparse-mode
R2(config-if)#int fa1/0
R2(config-if)#ip pim sparse-mode

R3(config)#ip multicast-routing
R3(config)#int fa0/0
R3(config-if)#ip pim sparse-mode
R3(config-if)#int fa0/1
R3(config-if)#ip pim sparse-mode

R4(config)#ip multicast-routing
R4(config)#int fa0/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#int fa1/0
R4(config-if)#ip pim sparse-mode

R5(config)#ip multicast-routing
R5(config)#int fa0/0
R5(config-if)#ip pim sparse-mode

R6(config)#ip multicast-routing
R6(config)#int fa0/0
R6(config-if)#ip pim sparse-mode

Before we go ahead with task 2, let’s verify and make sure all the PIM neighborships are there.

R1#sh ip pim neigh
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
15.15.15.5        FastEthernet0/0          00:06:30/00:01:37 v2    1 / DR S
13.13.13.3        FastEthernet1/0          00:08:01/00:01:38 v2    1 / DR S
14.14.14.4        FastEthernet0/1          00:07:17/00:01:21 v2    1 / DR S

R2#sh ip pim neigh
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      S - State Refresh Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
24.24.24.4        FastEthernet0/0          00:08:02/00:01:35 v2    1 / DR S
23.23.23.3        FastEthernet0/1          00:08:32/00:01:36 v2    1 / DR S
26.26.26.6        FastEthernet1/0          00:06:23/00:01:17 v2    1 / DR S

Task 2: R3 and R4 should be configured as candidate RP for all multicast groups. R1 and R2 will be the bootstrap routers. All the messages should be sourced from the Loopback0 interface.

R3(config)#ip pim rp-candidate Loopback0
Warning: PIMv2 not configured on Loopback0, Candidate-RP not advertised
R3(config)#int Loopback0
R3(config-if)#ip pim sparse-mode
R3(config-if)#
*Mar  1 00:21:41.823: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 3.3.3.3 on interface Loopback0
R3(config-if)#ip pim rp-candidate Loopback0


R4(config-if)#int Loopback0     
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit  
R4(config)#ip pim rp-candidate Loopback0


R1(config)#int Loopback0     
R1(config-if)#ip pim sparse-mode
R1(config-if)#ip pim bsr-candidate Loopback0

R2(config-if)#interface Loopback0
R2(config-if)#ip pim sparse-mode 
R2(config-if)#ip pim bsr-candidate Loopback0

Similar to Auto RP, the Loopback0 or the source of the BSR messages should be configured as a PIM interface, otherwise it will generate a warning message. Let’s check which router has been elected as the BSR and the RP mappings.

R6#sh ip pim bsr-router
PIMv2 Bootstrap information
  BSR address: 2.2.2.2 (?)
  Uptime:      00:06:42, BSR Priority: 0, Hash mask length: 0
  Expires:     00:01:27
R6#sh ip pim rp map
R6#sh ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:07:48, expires: 00:02:28
  RP 3.3.3.3 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:08:00, expires: 00:02:08

As mentioned, the default priority of BSR is 0 and if there is a tie, then the one with the highest IP address will be elected as the BSR. In our case it’s R2 with the IP address of 2.2.2.2. R4 was elected as the RP. Take note that in BSR, the RP has priority but in Auto RP there is no section in the configuration to configure this priority.

Task 3: Make sure R3 becomes the RP for all multicast groups. R1 should also become the BSR.

R1(config)#ip pim bsr-candidate Loopback0 0 255
R4(config)#ip pim rp-candidate Loopback0 priority 255

R6#sh ip pim bsr-router 
PIMv2 Bootstrap information
  BSR address: 1.1.1.1 (?)
  Uptime:      00:03:23, BSR Priority: 255, Hash mask length: 0
  Expires:     00:01:46
R6#sh ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:24:10, expires: 00:01:54
  RP 4.4.4.4 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 255, holdtime 150
         Uptime: 00:24:35, expires: 00:01:33

As seen in the output above, we configured R1 to have a priority of 255. (The zero before the 255 is the hash length. This is used to ensure that all multicast routers will select the same RP for a given group. We will not discuss this in this article.) In the bootstrap router, the higher the priority the more preferred the bootstrap router is. However in the case of the candidate RP it’s the reverse. The lower the priority the more preferred. Configuring R4 with a higher priority made R3 become the RP for all the multicast groups.

Task 4: R4 should become the RP for multicast group 239.1.1.0/24.

R4(config)#access-list 1 permit 239.1.1.0 0.0.0.255               
R4(config)#ip pim rp-candidate Loopback0 group-list 1 priority 255

R6#sh ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:34:37, expires: 00:02:25
Group(s) 239.1.1.0/24
  RP 4.4.4.4 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 255, holdtime 150
         Uptime: 00:02:15, expires: 00:02:25

Similar to the Auto RP, you can configure an access-list and specify it after the group-list configuration. R4 becomes the RP for 239.1.1.0/24 and in case R4 fails, R3 can resume as the RP as it is the RP for 224.0.0.0/4 that includes 239.1.1.0/24 in its scope.

Task 5: Ensure that R6 does not receive or learn any RP information .

R2(config-if)#int fa1/0
R2(config-if)#ip pim bsr-border

Let’s check if R2 is still receiving the messages and ip pim rp mappings.

R2#sh ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:46:28, expires: 00:01:32
Group(s) 239.1.1.0/24
  RP 4.4.4.4 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 255, holdtime 150
         Uptime: 00:14:07, expires: 00:02:16

Now let’s go to R6 and check it until the timer expires.

R6#sh ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:43:09, expires: 00:00:51
Group(s) 239.1.1.0/24
  RP 4.4.4.4 (?), v2
    Info source: 1.1.1.1 (?), via bootstrap, priority 255, holdtime 150
         Uptime: 00:10:48, expires: 00:00:36

Once the timer expires, there will be no more mappings as R6 doesn’t hear anymore BSR messages from R2.

R6#sh ip pim rp mapping
PIM Group-to-RP Mappings

By configuring ‘ip pim bsr-border’ on the interface facing R6 on R2, the BSR messages are no longer flooded in or out of the interface. This is an effective way of protecting your multicast network or separating the multicast domain by creating this boundary or border. In Auto RP, this is done through multicast boundary command but in BSR, it is very much simple to implement.

References:

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ip-multicast/whitepaper_c11-508498.html

http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html