PIM-SM with BSR
Load multicast.init.cfg
Configure R2 and R4 to join (*, 239.1.1.1)
Configure CSR9 and XR4 as RPs for all IPv4 groups using BSR
Both CSR9 and XR4 should be BSRs as well
CSR9 should be the preferred BSR and Candidate RP
Use R1 and R3 as the sources to verify that multicast traffic is working.
Answer
Explanation
BSR was created as a standards-based mechanism for propagating RP information within a domain. It is now the preferred choice over the old Cisco-proprietary Auto-RP.
BSR works using native PIM messages that are flooded hop-by-hop. This does not require dense mode, which is a big advantage over Auto-RP.
In BSR, one single BSR (bootstrap router) is elected via the PIM BSR message type. The router with the highest priority, or highest IP address, is elected as the BSR within the PIM domain. A router is configured to be a candidate BSR as follows:
An IOS-XE router uses a default BSR priority of 0, while IOS-XR uses a default BSR priority of 1. This means that, by default, an IOS-XR router is always elected over an IOS-XE router. In our lab, we can simply use a priority of 2 on CSR9 to elect it as the BSR. The first parameter after the interface is the hash-mask-len, and is required. We will explore this later in this lab.
Previously on CSR9 we saw that XR4 was elected as BSR:
Now we see that CSR9 is elected:
We can also see this on XR4:
Another difference between BSR and Auto-RP is that the BSR propagates all RP mappings, not just the best RP for a given mapping. This is called the RP set. We can see this on any PIM router in the domain:
Currently, the RP candidates are left at their default values. What is somewhat annoying is that the lowest priority RP candidate is the best RP. This is completely opposite how priority works for the BSR election. (The elected BSR has the highest priority). IOS-XE’s default priority is 0 and IOS-XR’s default priority is 192. This means that an IOS-XE candidate RP will always be preferred over an IOS-XR candidate RP for the same mapping, by default. IOS-XE’s implementation predates the BSR RFC which specified that the default priority should be 192.
To see which router would be used as RP for a given group address, we can use the following command. I cannot find an equivalent command for IOS-XR.
This means that we don’t need to change priorities to use R9 as the primary RP.
Even though R9 is the primary RP due to the lower priority value, all routers will still build auto-tunnels for Registering to all RPs in the set:
A BSR message looks as follows. It is sent to the link-local PIM multicast address, and is flooded hop-by-hop by PIM routers. Notice that this message controls the BSR election and the RP set advertisement. For each RP range, all RPs are included. If a candidate BSR sees another BSR with a higher priority, it stops sending BSR messages.
The BSR learns of all RP mappings via unicast PIM RP advertisement messages. Since the BSR is elected within PIM itself, the candidate RP learns of the BSR’s unicast address. The candidate RP then sends its mapping information via a unicast message as we see below. (Note that this was taken before CSR9 took over as the BSR).
Failover Considerations
Above, we see that there is a default 150second hold time. Let’s test failover by shutting down Lo0 on CSR9:
Immediately, all routers remove R9 as the BSR and candidate RP. It appears that XR4 finds that R9 is no longer reachable in the IGP and therefore immediately becomes the BSR, and advertises a BSR mesage with itself as the Candidate RP.
Update: Actually, I don’t think this is because XR4 finds R9 is no longer reachable. This is because R9 sends a failover BSR message, allowing XR4 to immediately become the best BSR. R9 sends a C-RP mapping for holdtime = 0 to immediately expire its C-RP entry on any candidate BSRs, and sends a failover BSM message, setting its BSR priority to 0.
If we simulate a failure of CSR9 completely by shutting down Gi2, then all routers must simply wait for the BSR holdtime and C-RP holdtime to expire (2.5 minutes). Once the BSR holdtime expires, XR14 becomes the BSR. XR14 also loses any C-RP mapping for CSR9, and only advertises itself as a C-RP.
A more subtle failure is for CSR9 to simply stop advertising itself as Candidate RP.
In this situation, we again have immediate failover. CSR9 is still acting as BSR, so it immediately removes itself from the RP set and advertises a new BSR message with only XR4 as the C-RP.
Let’s now try disabling both CSR9’s BSR and C-RP advertisements.
Immediately, CSR9 sends a “failover” BSR message, reducing its BSR priority to 0.
Interestingly, in the above debug we also see how BSR flooding works. The BSR message must be received on the RPF interface. This prevents BSR messages looping around endlessly.
So immediately all routers will see XR4 as the BSR. However, the CSR9 C-RP mapping still needs to wait 2.5 minutes to time out.
To speed this up, we could try to lower the interval at which the C-RP advertisement is sent to the BSR. Since the BSR is R9, this is sent “internally” to itself. On IOS-XE, we can set this as low as one second, but only as low as 30 seconds on IOS-XR. The hold time appears to be 2.5 times the interval.
Unfortunately this does not help us in this case, because CSR9 itself is also the BSR. So when CSR9 fails as both the BSR and C-RP, all routers still have to hold the RP information for R9 for 2.5 minutes. There does not appear to be a way to tune the holdtime within the BSR message itself. The RP-C interval is only used for the C-RP advertisement that is unicast to the BSR.
If we set XR4 as the BSR, then we can try to use the C-RP interval to provide fast failover:
Interestingly, IOS-XR as BSR appears to set the C-RP holdtime in the BSR message. This was not the case on IOS-XE. However, XR4 is only sending BSR messages at 30 second intervals. This appears to be the lowest it can go, based on its C-RP interval. So on all other routers, the R9 RP times out after just 2 seconds.
This makes fast failover using a low timer on the BSR message difficult to implement. Instead, Anycast RP would provide faster failover, as the IGP drives the convergence, and you don’t need to worry about inter-operability issues like we do with BSR.
RP Load Sharing
Since the BSR advertises the entire RP set, all routers can alternate using RPs for group addresses. In order for this to work, all routers use the same formula to select the same RP for a given group.
This formula uses the group address, RP address, and the hash mask as input. The hash mask essentially means that only the first X bits in the group address are used. For example, if the hash mask is 30, then group addresses 239.0.0.0 through 239.0.0.3 are all reduced to 239.0.0.0 in the formula. This means that each range will resolve to the same RP. For example, range 239.0.0.0/30 is RP1 and 239.0.0.4/30 is RP2. The BSR controls the hash mask length.
I’ve reverted back to the original configuration. R9 is BSR again and advertises hash mask length 32. This means that every single group address has its own RP. We can confirm the hash mask length by looking at the elected BSR:
IOS-XE also gives us a command to run the RP formula and determine which RP is used for which group. The highest hash mask value is the best.
Currently all groups are picking R9 as the RP. This is because the priority must tie in order for the hash value to be used. R9 has priority 0, so it is always the best RP:
Let’s set R9’s priority to the RFC default of 192 as well.
Now the hash value selects XR4 for every other group.
By using a mask such as /24, every other range of /24 will use either RP.
For example, everything in 239.1.1.X is now using R9. Notice that the hash value is the same. This is because the group address is effecitively reduced to 239.1.1.0 in the equation, no matter the last octect.
Another range, such as 239.1.4.0/24, always uses XR4:
In my opinion, the hash mask is not very useful. I don’t see why it matters very much whether all /24s resolve to the same RP, or just every other group address uses a different RP. I think this adds too much complexity, and BSR could have simply just always used a /32 hash mask.
Note that the default hash-mask for IOS-XE is 0. This means that the group address is not used in the hashing function at all. The formula produces a large hash value for whichever RP has the lowest IP address.
Summary
BSR is not all that complex, but you must remember a few things:
A single BSR is elected, and the highest priority value is best.
IOS-XE uses a BSR prority value of 0 by default
IOS-XR uses a BSR prority value of 1 by default
All C-RP mappings are advertised as a set by the BSR. Each router uses the RP with the lowest priority value as best. If this ties, the hash value comes into play to select an RP.
IOS-XE uses a C-RP priority value of 0 by default, which is the best possible value.
BSR messages are flooded hop by hop, within PIM itself. To prevent flooding loops, an RPF check is implemented. The RPF check is based on the IP of the BSR. The BSR must have a valid RPF interface in order for other routers to accept the RP mappings.
Last updated
