Profile 28

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 default tree via SR Tree-SID that is signaled via BGP mVPN/ipv4.

Answer

#XR1-10
router isis 1
 add ipv4 uni
  router-id lo0

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

#XR1-8
segment-routing traffic-eng
 pcc
  pce address ipv4 10.0.0.9

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

#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
 address-family ipv4
  interface Loopback0
   enable
 !
 vrf CUSTOMER
  address-family ipv4
   mdt source Loopback0
   bgp auto-discovery segment-routing
   mdt default segment-routing mpls
!
router pim
 vrf CUSTOMER
  address-family ipv4
   rpf topology route-policy USE_SR_TREESID
   mdt c-multicast-routing bgp

Explanation

A more scalable method of creating SR P2MP trees is using a default MDT. The benefit of this profile is that the configuration is the same for all PEs, whether they are roots or leafs.

First we enable BGP ipv4/mvpn. Then the PCE must simply be configured with the range of labels to use for P2MP policies that are requested by roots. In this lab we use a range out of the SRLB.

#XR9
pce
 address ipv4 10.0.0.9
 segment-routing
  traffic-eng
   p2mp
    label-range min 15400 max 15600

Each PE is configured in the familiar mVPN way. An RPF RPL sets the core-tree to sr-p2mp. BGP is used for c-multicast routing and auto-discovery. The default MDT uses SR. I find this approach much more logical that the previous static profile 27.

route-policy USE_SR_TREESID
  set core-tree sr-p2mp
end-policy
!
multicast-routing
 address-family ipv4
  interface Loopback0
   enable
 !
 vrf CUSTOMER
  address-family ipv4
   mdt source Loopback0
   bgp auto-discovery segment-routing
   mdt default segment-routing mpls
!
router pim
 vrf CUSTOMER
  address-family ipv4
   rpf topology route-policy USE_SR_TREESID
   mdt c-multicast-routing bgp

When the SR p2mp trees are setup dynamically, the root of each tree requests the PCE to setup the tree. The root is responsible for informing the PCE of the leafs of the tree.

For example, XR5 requests that the PCE calculate a p2mp policy rooted at itself with leafs XR7 and XR8. You can see in the wireshark capture that the “enterprise-specific information” ends with 10.0.0.7 and 10.0.0.8 in hex, which must be the leafs.

With profile 28, we use a default MDT. So each PE will preform this task for the tree rooted at itself. Each PE has the responsibility of keeping the policy updated as leaf PEs are added or removed. The root PE knows which leaf PEs are participating via BGP mVPN. Since we are simply using a default MDT, all routers discovered via type 1 routes are added to each PE’s p2mp tree rooted at itself.

NOTE: From here on out, XRv9K is required to get the correct output. This profile appears to be broken on XRd.

We should see one default tree per PE on every PE. For example, XR5 has three p2mp policies - one rooted at itself, and two for which it is a leaf.

Using the show mrib mpls forwarding command, we can see the labels associated with each tree:

We can also see the p2mp policies on the PCE itself. You can use the root keyword to filter the output to trees rooted at a particular PE.

Note that profile 28 supports PCE redundancy, because the PEs are the ones initiating the calculation of the p2mp policies. The PE can delegate the path computation to only one PCE at a time. To do this, the PCCs must enable the PCE HA group functionality. The PCEs must also have a state-sync session with each other. This feature is only available in 7.8.1+, but my XRv9000 is 7.7.1.

The tree rooted at the PE can be verified with two commands:

• show mvpn vrf CUSTOMER database segment-routing

• show mvpn vrf CUSTOMER context

The trees the PE is acting as a leaf for can be verified using show mvpn vrf CUSTOMER pe

However, I think it is easier to see all of these trees at once by simply using show segment-routing traffic-eng p2mp policy. If needed, this output can be filtered using the root keyword.