# Profile 13 w/ PE RP

Load **basic.startup.config.with.cpim.and.bgp.cfg**

```
#IOS-XE
config replace flash:basic.startup.config.with.cpim.and.bgp.cfg
Y

#IOS-XR
configure
load bootflash:basic.startup.config.with.cpim.and.bgp.cfg
commit replace
y
```



BGP ipv4/mvpn and mLDP is already enabled in the core.



Using profile 13 (MP2MP tree with BGP overlay and BGP AD), configure the core to only use SPT trees. A PE should never signal a (\*, G) type 6 route. Configure PE1 as the RP using BSR.





































## Answer <a href="#id-81a3769c-a763-47d8-ac0b-d257e9991fcb" id="id-81a3769c-a763-47d8-ac0b-d257e9991fcb"></a>

```
#CE1
no ip pim rp-candidate GigabitEthernet3
no ip pim bsr-candidate GigabitEthernet3 0

#PE1
int lo100
 vrf forwarding CUSTOMER
 ip add 1.1.1.100 255.255.255.255
 ip pim sparse-mode
!
router bgp 100
 add ipv4 vrf CUSTOMER
  redistribute conn
!
ip pim vrf CUSTOMER bsr-candidate lo100
ip pim vrf CUSTOMER rp-candidate lo100
!
vrf definition CUSTOMER
 vpn id 100:1
 add ipv4
  mdt default mpls mldp 20.20.20.20
  mdt overlay use-bgp spt-only
  mdt auto-discovery mldp

#PE2
vrf definition CUSTOMER
 vpn id 100:1
 add ipv4
  mdt default mpls mldp 20.20.20.20
  mdt overlay use-bgp spt-only
  mdt auto-discovery mldp

#PE3
vrf CUSTOMER
 vpn id 100:1
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf CUSTOMER add ipv4 
 mdt so lo0
 mdt default mldp ipv4 20.20.20.20
 bgp auto-discovery mldp
!
route-policy USE_MLDP
  set core-tree mldp-default
end-policy
!
router pim vrf CUSTOMER add ipv4
 mdt c-multicast-routing bgp suppress-shared-tree-join
 rpf top route-policy USE_MLDP
```



## Explanation <a href="#id-9742b5ca-f8cc-43d7-8d98-7bf726b89efc" id="id-9742b5ca-f8cc-43d7-8d98-7bf726b89efc"></a>

Using the **spt-only** keyword on IOS-XE and **suppress-shared-tree-join** on IOS-XR causes the PE to never translate a (\*, G) entry into a BGP type 6 route.

```
#IOS-XE
vrf definition CUSTOMER
 add ipv4
  mdt overlay use-bgp spt-only

#IOS-XR
router pim vrf CUSTOMER add ipv4
 mdt c-multicast-routing bgp suppress-shared-tree-join
```



This can be used to help scale the mVPN. In order for this to work, one of the PEs must be the RP. This is because the RP will receive PIM Registers for active sources and must generate a type 5 SA route to allow ingress PEs to learn of new sources in order to build (S, G).



First, verify that the CEs learn of the new RP, PE1. A common mistake is to forget to redistribute the loopback into the BGP VRF on PE1. If you fail to do this, the BSR messages will be denied on all routers due to failing the RPF check. (Also note, for some reason the last time I did this, I had to **wr mem** and reload PE1 for the BSR propagation to work).

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FThe3l5Y55Xqu6UTyYeKC%2Fimage.png?alt=media&#x26;token=bb659622-53cb-4e0d-bbdf-37e5712a7e70" alt=""><figcaption></figcaption></figure></div>



Join an ASM group from C3:

```
#C3
int gi0/1
 ip igmp join-group 239.3.3.3
```



PE3 installs this as MRIB state, but a type 6 BGP route is not generated.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FbBFaHEmJ92RIu0OBu4Az%2Fimage.png?alt=media&#x26;token=01206d78-2fb0-4545-80e4-1ae49c55587c" alt=""><figcaption></figcaption></figure></div>



The RP, PE1, therefore has no (\*, G) state. This helps for scalability, as there is no (\*, G) signalling in the core. (\*, G) states are confined to the receiver-site only.



But how does PE3 learn of an active source then? Let’s configure C2 as the source.

```
#C2
ping 239.3.3.3 repeat 100 time 1
```



As C2 starts sending, CE2 unicasts a PIM Register to PE1. Even though PE1 has no receivers for this group, it still sources a type 5 BGP S-A message. This is analagous to MSDP SAs.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FEnZglz969Z5Q4a1c1Bai%2Fimage.png?alt=media&#x26;token=c007e749-1623-4069-b470-c1c553049e93" alt=""><figcaption></figcaption></figure></div>



PE3 learns of the source via this type 5 route, and issues a type 7 route to join a (S, G) rooted at the source. We’ve replaced the PIM Register and SPT switchover process with BGP routes.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F1ZDTZ8aKpfXuG6lZGTOk%2Fimage.png?alt=media&#x26;token=66277949-2159-4e40-9ac9-27031b844e15" alt=""><figcaption></figcaption></figure></div>



Unforunately we don’t see any replies. PE2 is not actually forwarding the traffic onto the default MDT, despite having the Lspvif in the OIL. This appears to be a bug. **(Note 5/18/24**: This appears to be working this time. The Lspvif is 2 instead of 0.)

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FhsFXtHW0qcuJf0pfLAPG%2Fimage.png?alt=media&#x26;token=c66dec3b-ee37-47cd-bf44-5e76da6e4033" 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%2FtqoJzgpX1M31uz1aTfsy%2Fimage.png?alt=media&#x26;token=081da7ee-8ac2-4f2d-92ad-447c4ec828c0" alt=""><figcaption></figcaption></figure></div>



However, if we make PE3 the ingress PE, this works correctly:

```
#C2
int gi0/1
 ip igmp join-group 239.2.2.2
```

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FcsrKYWDs3YnJg405iwDX%2Fimage.png?alt=media&#x26;token=2ae7143d-5b5c-46a3-8c72-c223cf3783d2" alt=""><figcaption></figcaption></figure></div>



## What happens if the RP is in a customer site? (Not on a PE) <a href="#id-8d9a57a8-437e-481e-abfd-20fa920eb872" id="id-8d9a57a8-437e-481e-abfd-20fa920eb872"></a>

If the RP is in a customer site, traffic will not work if receivers are located in a remote site. The RP will never have any (\*, G) state, and will send Register Stops to the FHR of the sender. The remote site never learns of the active source.



However, if a receiver is present in the same site as the RP, then it would work. The RP in that case _does_ have (\*, G) state, so it joins a (S, G) rooted at the sender. This causes a type 5 route to be generated, which the remote site uses to learn of the active source and join the (S, G) tree.
