BSR

The Bootstrap Protocol, a standards based protocol defined by RFC 5059, is the replacement for the Cisco proprietary Auto-RP. As you should remember, Auto-RP required PIM Dense Mode operation in order to propogate Rendezvous Point location information as well as RP mapping information. This could be considered as a design flaw as it requires you to run a multicast protocol that most networks do not run today. The Bootstrap Protocol, rather than spreading its RP information via PIM-DM multicast, shares the RP/Group mappings via PIM messages on a hop-by-hop basis. The flooding procedure utilizes reverse path forwarding: when a router receives a BSR message, it applies RPF check, based on the source IP address in the packet. If the RPF check succeeds, the message is flooded out of all PIM-enabled interfaces until all routers in the domain learn the information.

Central to the Bootstrap Protocol is the Bootstrap Router, or BSR. The BSR listens and accumulates candidate RP announcements, performing a role similar to the Auto-RP Mapping Agent. Unlike the Auto-RP MA, the BSR does not elect the best RP for every group range it learns about, but instead builds a set of candidate RPs. The BSR then shares this information with other PIM routers via PIM messages.

PIM BSR Operates in two phases.

  1. BSR Discovery. Every router configured as BSR floods bootstrap messages and listens to other BSR candidates. The BSR that hears another BSR with a higher priority gives up its role of the BSR. Eventually there is only one BSR, and every router in the domain, including the candidate RPs learn about it.
  2. RP Discovery. Every RP unicasts its own address and the configured group ranges to the BSR. Eventually, BSR learns of every RP and continuously keeps flooding the new information through the domain, every 60 seconds by default.

The command to set up a candidate RP in IOS is ip pim rp-candidate < PIM-Enabled-Interface > [group-list] [interval] [priority < 0-255 >].

If you omit all optional arguments, the router will start advertising itself as the RP for all groups. You may specify the list of groups using the group-list argument. All entries in this list are “positive”, if you compare them to Auto-RP functionality. You cannot use “negative” groups, singnaling dense-mode forwarding. RP priority value is used only when the routers select the best RP for a given group, and lower values are preferred. The default RP priority is zero (which is against standard, which specifies 192) and is the highest possible value. You may rarely want to change the priority value for a candidate RP, possibly only in cases when you want to gracefully take the RP out of service.

The command to set up a BSR in Cisco IOS is ip pim bsr-candidate < Interface-Name > [hash-mask-length] [priority].

The priorty field is used to elect a single BSR for the PIM domain. If a BSR hears a message with higgher priority (or if tied a higher IP address), it immediately stops its own BSR advertisements. By default, the priority of zero is advertised in all BSR messages and the IP address of the interface used to source the BSR messages is used as a tie-breaker – the higher IP is preferred. If there are multiple BSRs, they constantly listen to other BSR messages flooded through the domain and stop sending their own information if they detect a better BSR candidate. This is based on a timer time of 130 seconds. This election process ensures BSR uniqueness in the domain while maintaining redundancy in case if the primary BSR fails.

We will look at the hash-mask-length in our next topic.

Multiple RP Candidates

We saw previously that a BSR router shares a RP-Set with all PIM listeners. This is different than Auto-RP, where the Mapping Agent would select the RP-to-Group mapping and only share that with PIM listeners. With the Bootstrap method, it puts the burden on the PIM router to select the RP to use for a particular group. There must be some method for all PIM routers to use in selecting these mappings or else the mappings would not be the same and load-balancing might not occur as intended.

So, ultimately the bootstrap messages containing Group to RP-set mappings are received by every multicast router in the domain and used to populate their RP caches. It’s up to the routers to select the best matching RP from the sets advertised by the BSR router. It is important that all routers select the same RP for the same group, otherwise the multicast sources might miss receivers. In order to make full use of Group to RP-set information routers might want to select different RPs for different groups. As mentioned previously, the load balancing procedure must yield the same result on all routers, to maintain synchronous mapping. Here is how load balancing decision procedure works.

  1. Among the routers in the RP-Set received from the BSR, select those that have the numerically lowest priority values. By default all candidate RPs advertise priority of 0, so they are all eligible.
  2. For every RP IP address, calculate the hash function value1 = Hash (GroupAddress AND Mask, RP1), value2 = Hash (GroupAddress AND Mask, RP2)… valueN = Hash (GroupAddress AND Mask, RPn). Chose the RP with the highest hash value. If tied, select the RP with the highest IP address.

Notice that the Group ID is anded with the BSR hash mask value. Thus only the first has-mask-length bits of the Group ID address are used to calculate the hash value. Using the “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. Notice that the default mask length value is zero – i.e. the group IP address is ignored when computing the hash value and all groups map to the same RP. So you can control the load balancing by properly setting the BSR Hash mask. The hash-mask is an 8-bit value. The RP with the highest hash function value for a given group is selected as the RP for the group (tiebreaker is highest IP address).

Multiple BSR Candidates

Routers that are Candidate BSRs in a PIM domain are usually also and Candidate RPs. They typically identify themselves by means of an IPv4 or IPv6 address, which is typically that of a loopback interface.

Each C-BSR is assigned a priority between 0 and 255, with the default being 0. As soon as a router is configured as a C-BSR it sets a bootstrap timer to 130 seconds and listens for a Bootstrap message. These Bootstrap messages advertse the originator’s priority and BSR IP address. When a C-BSR receives a Bootstrap message, it compares the originator’s priority with its own priority. If the originator has a higher priority, the receiver resets its bootstrap timer and continues to listen. If the receiver’s priority is higher, it declares itself the BSR and begins sending Bootstrap messages every 60 seconds. If the priorities are equal, the higher BSR IP address is the tie-breaker.

If a C-BSR’s 130-second bootstrap timer expires, the router assumes that there is no BSR, declares itself the BSR, and begins sending Bootstrap messages every 60 seconds.