# PIM-SM with BSR

Load **multicast.init.cfg**

```
#IOS-XE
config replace flash:multicast.init.cfg
 
#IOS-XR
configure
load bootflash:multicast.init.cfg
commit replace
y
```

* 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 <a href="#id-21737669-18f3-4cdd-9e28-68f5e7c93b89" id="id-21737669-18f3-4cdd-9e28-68f5e7c93b89"></a>

```
#XR4
multicast-routing
 address-family ipv4
  interface Loopback0 enable
!
router pim
 address-family ipv4
  bsr candidate-bsr 1.0.0.14
  bsr candidate-rp 1.0.0.14

#R9
int Lo0
 ip pim sparse-mode
!
ip pim bsr-candidate lo0 32 2
ip pim rp-candidate lo0

#R2
! If you want the router to respond to ICMP for testing, we must enable PIM
ip multicast-routing distributed
!
! Additionally, an RP address must be configured so that the "host" has a valid RPF
! interface for the received multicast traffic.
ip pim rp-address 9.2.5.5  
!
int gi2.525
 ip pim sparse-mode
 ip igmp join-group 239.1.1.1

#R4
! If you want the router to respond to ICMP for testing, we must enable PIM
ip multicast-routing distributed
!
! Additionally, an RP address must be configured so that the "host" has a valid RPF
! interface for the received multicast traffic.
ip pim rp-address 11.4.13.13
!
int GigabitEthernet2.543
 ip pim sparse-mode
 ip igmp join-group 239.1.1.1
```

## Explanation <a href="#a82ec3a1-48b5-4fc7-b041-4475d40a78a8" id="a82ec3a1-48b5-4fc7-b041-4475d40a78a8"></a>

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:

```
#IOS-XE
ip pim bsr-candidate lo0

#IOS-XR
router pim
 address-family ipv4
  bsr candidate-bsr <IP addr>
```

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.

```
#R9
int Lo0
 ip pim sparse-mode
!
ip pim bsr-candidate lo0 32 2
```

Previously on CSR9 we saw that XR4 was elected as BSR:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fyg5jNZP1yCk3002JGvsj%2Fimage.png?alt=media&#x26;token=27176d64-7dfb-46c3-8468-66dfdc3a6c68" alt=""><figcaption></figcaption></figure></div>

Now we see that CSR9 is elected:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FUvOJZDRXxymIwUNB4bxr%2Fimage.png?alt=media&#x26;token=1bc4ef8e-9c5f-4607-96e7-611e9a302ca9" alt=""><figcaption></figcaption></figure></div>

We can also see this on XR4:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FmvSOoaR19wJI3vu8SkQb%2Fimage.png?alt=media&#x26;token=72b76694-395f-44fb-9441-218ecb0a376e" alt=""><figcaption></figcaption></figure></div>

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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FGPrMc1A246PQacpGk0bg%2Fimage.png?alt=media&#x26;token=93f470ca-4d79-47c8-9db0-f92bc485e847" alt=""><figcaption></figcaption></figure></div>

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.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F5UInMcd2hopCgLJ2QRst%2Fimage.png?alt=media&#x26;token=1acc6cc3-240e-4a7e-b2ef-17489eef03bd" alt=""><figcaption></figcaption></figure></div>

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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FJHeOshiDuZMdMZmEgJSo%2Fimage.png?alt=media&#x26;token=c5fda539-081b-4171-abdc-ac3885b2f6bb" alt=""><figcaption></figcaption></figure></div>

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.

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fplzmtl7nzFpqBAGGjStm%2Fimage.png?alt=media&#x26;token=e0213266-1455-4d7b-a1a4-ed2dff3c1a31" alt=""><figcaption></figcaption></figure>

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).

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FCl0sovcCOdyPiyxQtLrV%2Fimage.png?alt=media&#x26;token=6a4f5df9-9f4a-43a2-bd2f-16fb32eddef4" alt=""><figcaption></figcaption></figure>

### Failover Considerations <a href="#de3e8289-f324-4d2c-85d4-60f80cdee59a" id="de3e8289-f324-4d2c-85d4-60f80cdee59a"></a>

Above, we see that there is a default 150second hold time. Let’s test failover by shutting down Lo0 on CSR9:

```
#CSR9
int Lo0
 shut
```

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.

```
#CSR9
int Lo0
 no shut
!
! Wait for CSR9 to be advertised as C-RP again
no ip pim rp-candidate Loopback0
```

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.

```
#CSR9
no ip pim bsr-candidate Loopback0
no ip pim rp-candidate Loopback0
```

Immediately, CSR9 sends a “failover” BSR message, reducing its BSR priority to 0.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F8nJEFe9vzkqX42sLIBN4%2Fimage.png?alt=media&#x26;token=d4ff17b3-fb92-45b7-ad44-830763f768f3" alt=""><figcaption></figcaption></figure></div>

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fy3GdHwS28q9vw7ecUnss%2Fimage.png?alt=media&#x26;token=3faf655b-d424-49d5-a4d8-55def4e01a00" alt=""><figcaption></figcaption></figure>

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.

```
#IOS-XE
ip pim rp-candidate Loopback0 interval <1-16383 seconds>

#IOS-XR
router pim
 add ipv4
  bsr candidate-rp 1.0.0.14 interval <30-600 seconds>
```

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:

```
#XR4
router pim
 address-family ipv4
  bsr candidate-bsr 1.0.0.14 priority 3

#CSR9
ip pim rp-candidate Loopback0 interval 1
```

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.

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FMRCJxJpUYJFJFEM8nILM%2Fimage.png?alt=media&#x26;token=b718e68c-5610-4981-8fd8-d0e9323e14c2" alt=""><figcaption></figcaption></figure>

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 <a href="#f419dfbf-fc49-4586-86c0-396d2738d5f3" id="f419dfbf-fc49-4586-86c0-396d2738d5f3"></a>

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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F0ktInt09JUcLFOjuTi3T%2Fimage.png?alt=media&#x26;token=d3ea4c91-faed-4d16-83ca-f18b14f0f59c" alt=""><figcaption></figcaption></figure></div>

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:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fd5Ozeio1AAuTWs66h6Dh%2Fimage.png?alt=media&#x26;token=4a48e162-8d36-4ceb-920a-7c04d1f90d2d" alt=""><figcaption></figcaption></figure></div>

Let’s set R9’s priority to the RFC default of 192 as well.

```
#CSR9
ip pim rp-candidate lo0 priority 192
```

Now the hash value selects XR4 for every other group.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FxmFJPyeOrVKy6LM9nuMB%2Fimage.png?alt=media&#x26;token=f3aa6c9d-6c89-4d5a-a767-dd9b4ff8eb2a" alt=""><figcaption></figcaption></figure></div>

By using a mask such as /24, every other range of /24 will use either RP.

```
#CSR9
ip pim bsr-candidate lo0 24 2
```

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.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FtmmirlLd9y0KUuBQzmlI%2Fimage.png?alt=media&#x26;token=9cd2685d-c124-40ab-b3c8-4590be0c0671" alt=""><figcaption></figcaption></figure></div>

Another range, such as 239.1.4.0/24, always uses XR4:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FS1AHBIEm9nK01a4F9j4h%2Fimage.png?alt=media&#x26;token=7663c44a-5769-4655-9f8c-41286e5d7b41" alt=""><figcaption></figcaption></figure></div>

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 <a href="#id-86169d8b-4cc7-4f67-a5d4-b376fa82f2f4" id="id-86169d8b-4cc7-4f67-a5d4-b376fa82f2f4"></a>

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.
