Profile 1
Load basic.startup.config.with.cpim.cfg
The basic IP addresses, L3VPN, and C-PIM between the PEs and CEs is pre-configured.
Configure multicast VPN using MP2MP mLDP in the core. You cannot use PIM in the core.
C3 should be able to ping 239.1.2.3, with C2 responding.
CE1 is configured as the RP using BSR.
PEs should form C-PIM adjacencies directly between themselves.
See answer below (scroll down).
Answer
Enable mLDP on the IOS-XR devices. On IOS-XE, mLDP is already enabled.
Configure the VPN ID on the PEs
Configure the default MDT to use mLDP and configure the root of the MP2MP tree as some arbitrary router. P2 is chosen in this solution.
On IOS-XR we must also enable multicast on the lo0 interface (in the global table) and fix the RPF check to use the mLDP core tree instead of trying to use PIM. We also must explicitly set the MDT source to be the loopback.
Join a group on one of the C routers and ping it from another C router. Ensure that you wait long enough for the customer RP to propagate to CE2 and CE3.
Verification
The mldp database on the root (P2) shows the local and remote labels for each directly connected neighbor.
The default MDT using MLDP creates a MP2MP tree. This is analogous to PIM-BiDir, and for this to work, an arbitrary router must be set as the root of the tree, preforming a role similar to the PIM-BiDir RP. In this lab we used P2 as the root.
Each leaf advertises a downstream label out the RPF interface for the configured root. This is very similar to PIM, except the RPF neighbor is an LDP neighbor that supports MP2MP MLDP, not a PIM neighbor.
In order to create loop prevention, the root of the MP2MP tree creates a unique local label per incoming interface. This local label is installed in the LFIB with an operation to swap to all downstream labels except the interface for which this local label is associated. For example, local label 24006 is allocated for Gi0/0/0/1. This is installed in the LFIB with outgoing labels 24009, and 24007. This means that traffic received with label 24006 is replicated out Gi0/0/0/2 and Gi0/0/0/0. To control flooding, label 24006 is only advertised out Gi0/0/0/1, so it is sort of a per-interface label.
P2 will forward and replicate any traffic recieved on any single interface out all other interfaces with the remote label. Notice above that P2 has no upstream neighbors since it itself is the root.
On P1, we see an upstream neighbor and a single downstream client (PE1):
The IOS-XE PEs automatically create Lspvif0 (LSP virtual interface) as a sort of tunnel interface. The source is lo0 by default just as with the GRE interface in profile 0. On IOS-XR this interface is called Lmdt<VRF_NAME>. The routers will form C-PIM adjacencies over this interface. C-PIM packets are transported using the default MDT which is transported using MP2MP MLDP.
This virtual interface is used in the C-PIM mfib as well. On PE1, C1 is sending traffic to 239.1.2.3, and CE1 is the RP so it is receiving (*, G) Joins for this group.
On PE2, traffic for the (S, G) entry is incoming the Lspvif interface.
Same for PE3. Traffic is incoming via the virtual interface.
A = Accept
EG = Egress
LMI = mLDP MDT interface, as opposed to the MI flag which is just MDT interface. LMI indicates “labeled” MDT interface.
A note on the IOS-XR rpf topology command
By default, IOS-XR only uses the unicast routing table for the RPF check. This works fine when you are using profile 0 (P-PIM) in the underlay, because the RPF check naturally uses unicast RIB, finds the RPF neighbor is a PE reachable via a multicast-GRE tunnel, and this tunnel is used as the RPF interface.
However, when we use anything other than P-PIM for the underlay/transport, we have to tell IOS-XR to look at this transport for the RPF check. The following config tells IOS-XR to use the MLDP default MDT for the RPF check.
We can see on PE3 that the RPF check for the customer’s RP is currently via the LMDT interface:
If we remove the RPF topology command, we see that the RPF check for the customer’s RP now resolves to null. The RPF check cannot be completed, because it is looking for a MDT tunnel (multicast GRE) in the P-PIM underlay to use for the RPF, which cannot be found.
Note that we only see this output because we previously learned of the RP via BSR. Previously we correctly set the RPF check to use MLDP. If we forget to do this in the first place, the customer’s BSR message will fail the RPF check, and IOS-XR will never learn the RP. We would see the following output, because the show pim rpf command only shows active mappings from the MRIB. (In fact, this is what we see if we wait a few minutes and let the BSR information time out after breaking the RPF check mechanism).
The C-PIM adjacencies will still be able to form, because the PIM Hellos are still sent out the LMDT interface and received in the LMDT interface, regardless of the RPF check mechanism. But PIM Joins cannot be sent due to no RPF interface, and BSR messages will not pass the RPF check.
It is interesting that IOS-XE does not require this for any profile. Personally, I don’t see why this is necessary on IOS-XR, because it seems that the router should be able detect what we are using in the underlay the same way IOS-XE apparently can detect this. If we configure the default MDT for the VRF using mLDP, then the router should just use this for the RPF check. Unfortunately, this is not the case, and we must remember to use this rpf topology command.
Summary
This is sometimes referred to as LSM or label-switched multicast. PIM is no longer necessary in the core, which is a big advantage. LDP is simply extended to provide mLDP capability in which a MP2MP tree is built in a PIM-BiDir fashion. An arbitrary root is selected, and participating leafs (PEs) initiate a branch onto the tree towards the root.
In mLDP, a single label can have an instruction to replicate and swap label out multiple interfaces.
The MP2MP tree is built by the PEs advertising a downstream MP2MP FEC towards the root. This is the label the PE expects to see when receiving traffic. It’s “downstream” because the root uses this label when sending downstream towards the PE.
The root then initiates a upstream MP2MP FEC out each interface leading towards a PE. This the label the PE uses when sending traffic upstream towards the root. This label is unique from how normal LDP operates, in which a FEC on a device has a single label per-platform. (For example, IGP prefix 1.1.1.1/32 has label X and this one label is advertised to all neighbors on all interfaces). On the root, a single MP2MP FEC now has multiple labels, one per receiving interface, so that loop prevention can be preformed. This ensures that traffic arriving via one interface is replicated out all other interfaces (except the receiving interface).
Additionally, these mLDP FECs have an opaque value which multiplexes trees built that are rooted at the same source. In profile 1, this opaque value is the VPN ID plus 0 for the default MDT, and some non-zero value for data MDTs (which we will see next). This value is “opaque” because it is only relevant to the ingress and egress PEs, not any transit LSRs in the path.
Upstream MP2MP FEC advertised from the root of the tree
Last updated
