Hello fellow networking savants. Hope you are all well, working towards your goals and certifications. For myself, I’ve been busy. A hungry busy if you will. Hungry for the next best thing.

Today I will be discussing Bootstrap router. Multicast is a weak spot for me so I thought it would be good to write about it.

Let’s get into it.

BSR is a standards based solution that shares RP information, it performs the same function as Auto-RP (Cisco proprietary) and uses the same concept of cRP or candidate RP.

There are two roles in BSR:

Candidate BSR – Similar function to the Mapping Agent (MA) in Auto-RP, shares information that it receives from all candidate RPs.

Candidate RP – The routers advertising themselves as a potential Rendezvous Point (RP).

Where BSR differs from Auto-RP is how it shares its information with other multicast routers in the network.

There can only be one active BSR in a multicast network and it’s election is based on highest priority, and if the priorities are the same among multiple BSRs the router with the highest IP address will be elected at the BSR.

BSR messages are sent to all routers on a hop-by-hop basis, sending its messages to the multicast address 224.0.0.13 with a TTL of 1. When a multicast router receives this message it resends this message out all PIM enabled interfaces.

All multicast routers will eventually know about the source address of the BSR through these messages. The messages also include group range-to-RP set mapping. (more on this later)

Candidate RPs will know the address of the BSR and will register its self via a unicast packet to the BSR.

Once the BSR receives the registration messages from the cRPs, it will include all cRPs in its BSR messages and share them to all multicast routers. This differs from Auto-RP, Auto-RP picks only the best RP for every group.

Let me show you what some of this theory looks like on the command line.

Enable multicast routing on all routers and enable PIM sparse mode on all Ethernet segments for R4,R5,R8,R10

R8 has formed PIM neighbors with R5 and R10. All routers have their appropriate neighbors.

I’ll make R8 and R10 candidate RPs

I’ll make R5 the BSR, but before I do that I am going to turn on debug ip pim bsr for R5,R8 and R10.

From R5s debug output, you can see that it received both R8s and R10s RP registration.

From R4s perspective, it knows about the BSR at R5 and the two RPs at R8 and R10.

Notice that R4 is seeing both R8 and R10 as possible RPs for the 224.0.0.0/4 group. This is known as the group range-to-RP set mapping. This was included in the BSR messages that R5 generates.

We’ll have to check the rp-hash for the 224.0.0.0/4 group to know who is the RP.

R10 is the RP for 224.0.0.0/4. How was this determined?

1. If the RPs advertise for the same group (in our case) prefer the one with the lower priority. Default it 0.
2. Look for the highest hash value if priorities are the same.
3. Highest IP address will be preferred if priority and hash values are the same.

R10 won the election based on having the higher IP in this case.

The hash value is an interesting feature that allows us to load balance our groups between RPs.

The hash value is based on a 32-bit value. By default this hash value is 0. So this means the hash value will be calculated on the IP address of the RP.

Lets change the hash mask length to be 31 on R5 the BSR.

Lets view R4 to see what this has changed.

R4 now see R10 as the RP for the 239.1.1.1 group and R8 as the RP for the 239.1.1.2 group. Changing the hash mask value has allowed us to load balance our groups.

We can also confirm this from a data plane perspective. I’ll join R4 to two different groups.

I joined R4 to group 224.1.1.1 and 224.1.1.2, notice the RPs for both (*,G) groups.

Mike