Profile 28
Load top1.vpnv4v6.srv6.configured.cfg
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
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.
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.
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.
Last updated
