# PIM-BiDir

Load **multicast.init.cfg**

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

Configure CSR9 as the RP for 239.1.1.0/24 and XR4 as the RP for 239.2.2.0/24. Advertise the RP mapping using BSR. Use BiDir for these groups.

## Answer <a href="#c126915e-b60e-445f-a147-7e795ed8e243" id="c126915e-b60e-445f-a147-7e795ed8e243"></a>

```
#R5-R10
ip pim bidir-enable

#XR4
multicast-routing
 address-family ipv4
  interface Loopback0 enable
!
ipv4 access-list XR4_BIDIR_GROUP
 10 permit ipv4 239.2.2.0/24 any
!
router pim
 address-family ipv4
  bsr candidate-bsr 1.0.0.14
  bsr candidate-rp 1.0.0.14 group-list XR4_BIDIR_GROUP bidir

#R9
int Lo0
 ip pim sparse-mode
!
ip access-l standard R9_BIDIR_GROUP
 permit 239.1.1.0 0.0.0.255
!
ip pim bsr-candidate lo0
ip pim rp-candidate Loopback0 group-list R9_BIDIR_GROUP bidir
```

## Explanation <a href="#id-37a29536-54bd-4802-90cf-98897e953040" id="id-37a29536-54bd-4802-90cf-98897e953040"></a>

BiDir is essentially an extension to PIM-SM. The RPT built from the receivers to the RP works exactly the same way. However, the PIM Register process is gone. Instead, multicast traffic is allowed to flow *up* the shared tree towards the RP. In order for this to work, the RPF check needs to be removed. A different loop prevent mechanism needs to be deployed. PIM-BiDir uses a spanning tree to enforce a loop free topology. You can think of this just as how classic STP works.

In PIM-BiDir, the “root port” is the BiDir Upstream port, which is the RPF interface towards the RP. The “Designated Ports” are elected via the DF (Designated Forwarder) election. This is a special PIM packet that each router originates on every link for every BiDir RP. A DF port is selected per-RP. Only one router can be elected DF on a given segment. The router with the best metric, or highest interface IP address is elected. The DF election PIM packet looks as follows:

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FQdFSnHt5gcLkuRIwBBp9%2Fimage.png?alt=media&#x26;token=1f1e9e99-0fe9-469e-8d99-b0c15b29a532" alt=""><figcaption></figcaption></figure>

Any ports that are not elected as DF on a router are placed into “blocking.” This is how a loop free topology is implemented in PIM-BiDir.

The benefit of PIM-BiDir is that there is no (S, G) state. This provides scalability when you have lots of senders and receivers. PIM-BiDir is suitable for multicast traffic such as video conferencing, in which every receiver is also a sender. All traffic is forwarded via the blanket (\*, G) PIM-BiDir entry.

The downside to PIM-BiDir is that the RP must be 100% in the traffic flow. You should place the RP in a central location, because traffic will never switchover to a (S, G) entry in PIM-BiDir.

To enable PIM-BiDir on IOS-XE we need an explicit global statement. This is not required on IOS-XR; PIM-BiDir is already enabled by default.

```
#IOS-XE
ip pim bidir-enable
```

The RP also must be associated with BiDir mode. This can be done statically, using AutoRP or using BSR. In this lab we use BSR.

```
#XR4
multicast-routing
 address-family ipv4
  interface Loopback0 enable
!
ipv4 access-list XR4_BIDIR_GROUP
 10 permit ipv4 any 239.2.2.0/24
!
router pim
 address-family ipv4
  bsr candidate-bsr 1.0.0.14
  bsr candidate-rp 1.0.0.14 group-list XR4_BIDIR_GROUP bidir

#R9
int Lo0
 ip pim sparse-mode
!
ip access-l standard R9_BIDIR_GROUP
 permit 239.1.1.0 0.0.0.255
!
ip pim bsr-candidate lo0
ip pim rp-candidate Loopback0 group-list R9_BIDIR_GROUP bidir
```

At this point, we should see that all routers in the domain learn of the two RPs and the groups they are acting as RP for. We should also see that they are associated with BiDir mode.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FJ7UWEgHwM6hb7Y4w3VBR%2Fimage.png?alt=media&#x26;token=d9180bfb-6e94-40b1-b99f-45ea10b68c4d" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FFc46hUQHKptiFvP4R2l0%2Fimage.png?alt=media&#x26;token=5ff9045d-cd12-48db-be82-c80fd095d0e9" alt=""><figcaption></figcaption></figure></div>

On IOS-XR we can confirm that these two ranges are operating in BiDir mode:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FxNoEwk0KB9zgoW1ex604%2Fimage.png?alt=media&#x26;token=a9b74b2a-5179-407b-9d80-39e5deec1458" alt=""><figcaption></figcaption></figure></div>

The router learns that these ranges are BiDir, because there is a BiDir flag on the group range in the BSR message:

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FV5P9w8nSgvornF8W82am%2Fimage.png?alt=media&#x26;token=b637beea-85a0-4e2b-8cbb-f74bc29a3584" alt=""><figcaption></figcaption></figure>

Next, the DF election takes place on every segment to enforce the strict loop free topology. Let’s “zoom in” on the election between R7-XR1-XR4, because this has a potential for a loop.

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FKdl7XgCUggVKYuigb7M6%2Fimage.png?alt=media&#x26;token=e1ab10cc-0865-4d15-9de7-9a970a2d9a57" alt=""><figcaption></figcaption></figure>

Let’s look at the DF election for R9 as the RP. R7 identifies its interface towards XR4 as the best path to R9, so this is the BiDir upstream port (or “root port” in STP terms) - marked as **U**. R7 and XR4 share their route AD/metric towards R9 with each other, and XR4 wins the DF election - marked as **DF**. So far our topology looks like this:

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fp87HQ92zz1yaeIZWuiUn%2Fimage.png?alt=media&#x26;token=982d5795-1ec9-4654-a84c-8e4e477a0fb0" alt=""><figcaption></figcaption></figure>

Next, R7 and XR1 run the DF election process. XR1 and R7 both have a 110/3 (AD/metric) route towards R9, so XR1 wins for higher IP address. XR1’s BiDir upstream interface is the interface towards XR4. On the XR1-XR4 interface, XR4 wins the election, with a metric of 110/2 towards R9. Since R7’s interface towards XR1 is neither a upstream interface, nor DF, R7 is effectively “blocking” on this port. We now have enforced a loop free topology.

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FhPwDZSgDykLSO4TnVyzC%2Fimage.png?alt=media&#x26;token=f5eee4da-2b1a-41a6-bd7e-d7cae0c1c89b" alt=""><figcaption></figcaption></figure>

We can see the results of the DF election using the following commands:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F3jqaouYwDWLMQz1uhrH8%2Fimage.png?alt=media&#x26;token=40ed0ad2-b0ca-478d-81de-4f9a7c10a81b" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F2QS8yTDbuWtcW65AqTHP%2Fimage.png?alt=media&#x26;token=2a87e1b0-3eb6-4561-83d9-6d398dfacaa9" alt=""><figcaption></figcaption></figure></div>

To actually enforce the results of the DF election, and therefore achieve a loop free topology, only certain interfaces are added to the (\*, G) entry for the BiDir groups. For example, let’s look at (\*, 239.1.1.0/24) on R7:

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FpgoQ4opBK0mykfKKRqs6%2Fimage.png?alt=media&#x26;token=5ee6e5d3-385d-432f-98a1-dc1a9fd82bfe" alt=""><figcaption></figcaption></figure>

Above, the BiDir upstream is the interface towards XR4, as we identified previously. This is essentially an outgoing interface, as well as an incoming interface. Additionally, all ports for which the router is DF are added to the incoming interface list. A multicast packet arrive on this incoming interface is sent out the BiDir-upstream interface towards the RP. Notice that the interface towards XR1 is not present here. The loop free topology is enforced by only adding the upstream and DF ports to the incoming interface list. Traffic is not accepted on non-DF ports.

We can also see this on XR1. All of its interfaces are either DF or upstream ports, so all are present in the incoming interface list. Only the BiDir-upstream port is present in the outgoing interface list:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FW6dTV5EjVbz7wJHdZ9d5%2Fimage.png?alt=media&#x26;token=d93b9b57-b007-456a-a065-69db96a34d8b" alt=""><figcaption></figcaption></figure></div>

Let’s examine what happens when we start sending multicast traffic. R1 pings 239.1.1.1:

```
#R1
ping 239.1.1.1
```

R7 accepts the traffic as it arrives on an incoming interface in the (\*, 239.1.1.0/24) entry, and R7 forwards to XR4. R7 does *not* add a (S, G) entry for this. XR4 does the same, and forwards towards R9. R9 finds no interested receivers for (\*, 239.1.1.1) so R9 drops the traffic. We can see this in a pcap. The ping is seen taking three hops: R1-R7, R7-XR4, XR4-R9:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FDArIDe2EKzryT42uMZgV%2Fimage.png?alt=media&#x26;token=2a086def-dd86-450b-be31-764bb657f518" alt=""><figcaption></figcaption></figure></div>

This is another downside of PIM-BiDiR - there is no PIM Register Stop. So R9 cannot let a FHR know that it has no interested receivers. Instead, this traffic will use up unnecessary bandwidth in the network. It will always be sent all the way to the RP, and then dropped at the RP.

Let’s now join a receiver, using R2. R2 must run PIM-BiDir mode as well. It will automatically learn of the RPs via BSR too. Without using BiDir mode, R5 will sense that R2 is not running BiDir. R5 notices the lack of the BiDir capability flag set in the PIM Hello. R5 will not forward traffic to R2 even though it receives an IGMP join from R2. This is because R5 sees that R2 is a PIM neighbor but it is not participating in the DF election, so R5 must err on the side of caution in order to not form a loop. Keep in mind this is all done just to see an ICMP reply from R2. You could alternatively just watch the mfib counters on R5 and not run PIM on R2 at all.

```
#R2
ip multicast-routing distributed
ip pim bidir-enable
!
int gi2.525
 ip pim sparse-mode
 ip igmp join-group 239.1.1.1
```

On R5, we see that a (\*, G) state was created. The interface that R5 received the IGMP report on is added to the OIL. The RPF interface is inherited from the (\*, 239.1.1.0/24) entry and is both an IIF and outgoing interface.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FPdgVphzZsWC5vfjfTyMW%2Fimage.png?alt=media&#x26;token=9393a183-0ecb-4d6f-950f-f51969797e7f" alt=""><figcaption></figcaption></figure></div>

A PIM Join makes its way to R9. This is the exact same process as in regular PIM-SM.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FZcUGjtk8hLbWEdqC07NO%2Fimage.png?alt=media&#x26;token=87f799ee-4f7a-455d-8e1c-cf0f46ff7266" alt=""><figcaption></figcaption></figure></div>

In PIM-BiDir, (\*, G) state only exists on the shared tree between the RP and receivers as in normal PIM-SM. Traffic is forwarded from sources only based on a blanket (\*, G) entry such as (\*, 239.1.1.0/24).

R1 pings 239.1.1.1 and receives a reply from R2:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fysi55Oi2dbKd7tLf6KYw%2Fimage.png?alt=media&#x26;token=787e438e-47fc-4fea-9366-d52c89f3f98a" alt=""><figcaption></figcaption></figure></div>

On routers between the sender and the RP, there is no (S, 239.1.1.1) or even (\*, 239.1.1.1) state. All traffic is forwarded via the (\*, 239.1.1.0/24) entry:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FWTR0JjLJ02wQZYmIxERF%2Fimage.png?alt=media&#x26;token=d96e995c-456a-4dc5-80a0-3b3a9d231c68" alt=""><figcaption></figcaption></figure></div>

On routers between the RP and the receiver, the (\*, G) state is present due to the PIM Join process.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fb6xAWzQmJJzNKMW8xT3d%2Fimage.png?alt=media&#x26;token=a5b484cd-810f-45ac-8ca5-15e0cf3ac755" alt=""><figcaption></figcaption></figure></div>

This is what makes PIM-BiDir scalable: all traffic is forwarded based on (\*, G/32) or (\*, G/X) entries. (S, G) entries are never created.

Let’s briefly look at XR as the LHR. We’ll join the same group on R4.

```
#R4
ip multicast-routing distributed
ip pim bidir-enable
!
int GigabitEthernet2.543
 ip pim sparse-mode
 ip igmp join-group 239.1.1.1
```

We’ll now look at the MRIB on XR3. The IA flag means “inherit accept,” so the (\*, G) entry inherits all the acceptance interfaces found in the blanket (\*, G/X) entry. The interface towards R4 is added to the OIL for the specific (\*, G) entry.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FrsxKt0XvitZjegazImkq%2Fimage.png?alt=media&#x26;token=cd5a7f34-2de2-4773-a2c0-478d9b2a8f6d" alt=""><figcaption></figcaption></figure></div>

In many ways, PIM-BiDir is actually more simple than PIM-SM. There is no PIM Register or Register stop process, there is no (S, G) tree the RP must join, and there is no SPT switchover process. The complexity just comes from the loop free topology enforcement, which uses a DF election process and ensures that no non-DF/upstream interfaces are added to the incoming interface list.

Let’s also test the reverse direction. We’ll set R1 to join 239.1.1.1.

```
#R1
ip multicast-routing distributed
ip pim bidir-enable
!
int gi2.517
 ip pim sparse-mode
 no ip igmp ver 3
 ip igmp join-group 239.1.1.1
```

R9 now has three interfaces added to the OIL. One interface towards each receiver.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FY1vN4i69zQl7VFsNBUSR%2Fimage.png?alt=media&#x26;token=c5d52760-f760-4494-984f-326b708b0a3e" alt=""><figcaption></figcaption></figure></div>

When R2 pings 239.1.1.1, we see a reply from R1, R2 (itself) and R4:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fh2lRW5ogNEHXwafCV0KF%2Fimage.png?alt=media&#x26;token=02fd6831-2389-465e-88fc-0abd708ff093" alt=""><figcaption></figcaption></figure></div>

### What happens if a router in the path does not have BiDir enabled? <a href="#f97658ce-e479-4ec8-85e1-eab5ffb3f0e8" id="f97658ce-e479-4ec8-85e1-eab5ffb3f0e8"></a>

Let’s disable BiDir on R10:

<figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FdCTJIKMxYWTmN0CD4z4T%2Fimage.png?alt=media&#x26;token=d93c5e45-c99b-4501-9d4b-b784f51e6b23" alt=""><figcaption></figcaption></figure>

```
#R10
no ip pim bidir-enable
```

R10 shows us that it still learns of the RPs and that they are in BiDir mode, but warns us that BiDir is disabled locally.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FV6dKaWNXwwuaMsAA20qh%2Fimage.png?alt=media&#x26;token=acabd227-8988-4503-8677-4ccc9886f2ff" alt=""><figcaption></figcaption></figure></div>

R10 still has the mroute states, but these are not functioning correctly. R10 can only add its own BiDir upstream to the incoming interface list, because it is not running DF election on its interfaces.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FNuRcHGrApWCt3pMItGbK%2Fimage.png?alt=media&#x26;token=2dd8c96c-32af-4f79-a8c7-c92a161cd2c8" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FmqrJ3G7RFLUmIgmRBUQC%2Fimage.png?alt=media&#x26;token=aac86fa9-e3da-43cd-8447-e063ed9c507e" alt=""><figcaption></figcaption></figure></div>

Additionally, R5 cannot send a PIM Join towards R10 for the (\*, 239.1.1.1) entry. This appears to be because R5 knows that R10 is not BiDir capable, so it will not use its as the RPF neighbor. Strangely, R5 does still use R10 as the RPF neighbor for the /24 entries.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FaGWcXDiSTKgVk3tItZ6b%2Fimage.png?alt=media&#x26;token=9a73c62a-27d6-4173-8d9b-f52a6a6a828d" alt=""><figcaption></figcaption></figure></div>

Traffic can flow neither down or up the shared tree.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F7TH9DfWtVsawW9udzJVv%2Fimage.png?alt=media&#x26;token=666495d3-0be5-4552-9f2b-6c4efd9934a9" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FCvnI1JoDH6MuWjELhQXC%2Fimage.png?alt=media&#x26;token=ed26e045-805b-4669-a068-af45daca057c" alt=""><figcaption></figcaption></figure></div>

### What if R10 enables PIM-BiDir but treats the group as non-BiDir? <a href="#id-68e986e7-46cb-4657-a1b2-17fd22f10c78" id="id-68e986e7-46cb-4657-a1b2-17fd22f10c78"></a>

What if R10 does enable PIM-BiDir but it treats 239.1.1.0/24 as non-BiDir? Let’s test this out by removing BSR in our network so we can define the RP statically on each router.

```
#R5-R10, R1-R2
ip pim bidir-enable
ip pim rp-address 1.0.0.9 bidir

#XR1-4
router pim
 address-family ipv4
  rp-address 1.0.0.9 bidir

#XR4
router pim
 address-family ipv4
  no bsr candidate-bsr 1.0.0.14
  no bsr candidate-rp 1.0.0.14 group-list XR4_BIDIR_GROUP bidir

#R9
no ip pim bsr-candidate lo0
no ip pim rp-candidate Loopback0 group-list R9_BIDIR_GROUP bidir
```

After the RP information cached from BSR times out, we should be left with only a single static RP mapping on all routers.

On R10 we’ll now set the RP as non-bidir mode:

```
#R10
no ip pim rp-address 1.0.0.9 bidir
ip pim rp-address 1.0.0.9
```

The same symptoms appear. R5 sees that R10 is not participating in a DF election for RP 1.0.0.9. So R5 does not use R10 as the RPF neighbor for its (\*, 239.1.1.1) entry. Therefore traffic downstream from the RP does not get delivered to R2. Additionally, traffic cannot travel upstream through R10, because R10 has no (\*, G) state to match the traffic against.

### A note on using PIM-SM with PIM-BiDir <a href="#id-270f790f-fbe1-4fa3-82fb-059ac8540905" id="id-270f790f-fbe1-4fa3-82fb-059ac8540905"></a>

PIM-SM and PIM-BiDir can co-exist in the network without any issues. However, on IOS-XE you cannot use the same loopback as the RP for both SM and BiDir at the same time. This is because the command **show ip pim rp-candidate Lo0** will override the previous command. For example:

```
ip pim rp-candidate Loopback0 group-list PIM_SM
ip pim rp-candidate Loopback0 group-list PIM_BIDIR bidir
```

This becomes just:

```
ip pim rp-candidate Loopback0 group-list PIM_BIDIR bidir
```

Instead, you need to use two separate loopbacks:

```
ip pim rp-candidate Loopback0 group-list PIM_SM
ip pim rp-candidate Loopback1 group-list PIM_BIDIR bidir

```

Note that this is also the case for static RP and AutoRP.

```
ip pim rp-add 1.0.0.9 PIM_SM
ip pim rp-add 1.0.0.9 PIM_BIDIR bidir  <---- This just replaces the previous command

ip pim send-rp-announce lo0 scope 255 group-list PIM_SM
ip pim send-rp-announce lo0 scope 255 group-list PIM_BIDIR bidir <---- This just replaces the previous command
```

However, on IOS-XR, this is not an issue. You can reuse the same loopback address for both modes.

```
router pim
 address-family ipv4
  rp-address 1.0.0.14 PIM_SM
  rp-address 1.0.0.14 PIM_BIDIR bidir
  auto-rp candidate-rp Loopback0 scope 255 group-list PIM_SM interval 60
  auto-rp candidate-rp Loopback0 scope 255 group-list PIM_BIDIR interval 60 bidir
  bsr candidate-rp 1.0.0.14 group-list PIM_SM priority 192 interval 60
  bsr candidate-rp 1.0.0.14 group-list PIM_BIDIR priority 192 interval 60 bidir
```
