# Profile 29

Load **top1.vpnv4v6.srv6.configured.cfg**

```
#IOS-XR
configure
load top1.tree-sid.init.cfg
commit replace
y

#IOS-XE
config replace flash:top1.tree-sid.init.cfg
Y
```

PIM is already enabled on the PE-CE links. CSR3 and CSR4 have joined SSM group (1.1.1.1, 232.1.1.1).

Configure XR9 as PCE for XR5-XR8. Use a partitioned MDT via SR Tree-SID that is signaled via mVPN.

##

##

## Answer <a href="#f263dd5a-2e2a-47ee-9f7e-5798cc3adc30" id="f263dd5a-2e2a-47ee-9f7e-5798cc3adc30"></a>

```
#XR9, XR10
router bgp 100
 address-family ipv4 mvpn
 !
 neighbor-group RRC
  address-family ipv4 mvpn
   route-reflector-client

#XR9
pce
 address ipv4 10.0.0.9
 !
 segment-routing
  traffic-eng
   p2mp
    label-range min 15100 max 15200
!
router isis 1
 distribute link-state

#XR1-8
router isis 1
 add ipv4
  router-id lo0
!
segment-routing traffic-eng
 pcc pce address ipv4 10.0.0.9

#XR5-8
router bgp 100
 mvpn
 address-family ipv4 mvpn
 !
 neighbor-group RR
  address-family ipv4 mvpn
  !
 !
 vrf CUSTOMER
  address-family ipv4 mvpn
!
route-policy USE_SR_TREESID
 set core-tree sr-p2mp
end-policy
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf CUSTOMER add ipv4
 mdt so lo0
 mdt partitioned segment-routing mpls
 bgp auto-discovery segment-routing
!
router pim vrf CUSTOMER add ipv4
 mdt c-multicast-routing bgp
 rpf topology route-policy USE_SR_TREESID
```

## Explanation <a href="#id-49cbff0c-0cdb-4c62-a898-2e3951ead399" id="id-49cbff0c-0cdb-4c62-a898-2e3951ead399"></a>

Profile 29 uses SR-p2mp policies with partitioned MDTs. This is the same as with profile 14, except SR p2mp trees are used as opposed to mLDP trees.

In partitioned MDT, each PE sources a (\*, \*) S-PMSI route. Only interested receivers join a given PE’s partitioned MDT. This makes state in the core more optimal. With default MDT, you have a full mesh of default MDTs at all times, even if there is no multicast traffic present. With partitioned MDTs, the p2mp policies are only created as needed.

Notice that all PEs participating in the VPN source a type 3 wildcard S-PMSI route:

<div align="left"><figure><img src="/files/gPRTz1SGdb77VZMtZcr9" alt=""><figcaption></figcaption></figure></div>

XR7 and XR8 have interested receivers for (1.1.1.1, 232.1.1.1). The source 1.1.1.1 is behind XR5. Therefore they wish to join XR5’s partitioned MDT. Each type 3 route has the leaf-info-required flag set. So XR7 and XR8 create type 4 routes to signal interest in joining XR5’s (\*, \*) S-PSMI tree.

<div align="left"><figure><img src="/files/5TOiyOZ3XY4dsRscVNiS" alt=""><figcaption></figcaption></figure></div>

Now that XR5 has interested receivers, it signals the p2mp policy at the PCE. Note that this is the only p2mp policy created at this point. This is what makes partitioned MDTs so scalable.

<div align="left"><figure><img src="/files/tPgtjt2sl8byOatL4ct6" alt=""><figcaption></figcaption></figure></div>

Using constraints and FRR with partitioned MDTs is not any different from how they are used with default MDTs. You simply set the color and enable FRR on the partitioned MDT. There is no option for using an RPL as you saw with data MDTs, because this only controls the single (\*, \*) type 3 S-PMSI route.

```
multicast-routing
 vrf CUSTOMER
  address-family ipv4
   mdt partitioned segment-routing mpls color 10 fast-reroute lfa
```

Additionally, data MDTs can be used with this profile too. They work exactly the same way as we saw in the previous lab.

## Further Reading/Watching <a href="#id-7f4b1578-725c-497b-ba0d-88a0c3a4deb0" id="id-7f4b1578-725c-497b-ba0d-88a0c3a4deb0"></a>

<https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-9/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-79x/configure-sr-tree-sid.html>

<https://www.youtube.com/watch?v=wgOke3amhDY>

## A note on IPv6/MVPN <a href="#id-41b79060-40ee-40e8-8baf-782adaba89a4" id="id-41b79060-40ee-40e8-8baf-782adaba89a4"></a>

IPv6/mVPN does not appear to be supported with SR Tree-SID. Perhaps this will come in a future version.

```
RP/0/RP0/CPU0:XR5(config)#show config fail
Sat Feb 10 23:11:50.506 UTC
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.


multicast-routing
 vrf CUSTOMER
  address-family ipv6
   bgp auto-discovery segment-routing
!!% Invalid address-family: AF 'ipv6' not supported
   !
   mdt partitioned segment-routing mpls
!!% Invalid address-family: AF 'ipv6' not supported
```

## Flex-Algo <a href="#id-67b44b99-1dd0-4460-b921-f9e0184a07c6" id="id-67b44b99-1dd0-4460-b921-f9e0184a07c6"></a>

Using flex-algo in the ODN policy also does not appear to work. But this seems to be a general limitation with PCE in general. As far as I know, flex-algo cannot be used as a constraint when the policy is delegated to a PCE. (**Update 10-17-24:** Flex-algo can be used as a constraint on a general PCE-calculated policy since version 7.3.1 I believe).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/mvpn-sr/profile-29.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.