Profile 12
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 mLDP in the core using only P2MP trees.
You cannot use PIM in the core.
CE1 is predefined as the RP in the C-PIM via BSR.
PEs cannot form C-PIM adjacencies between each other. Instead use BGP for the overlay.
See answer below (scroll down).
Answer
This is similar to profile 11, except we use mLDP in the underlay instead of GRE (P-PIM). Because BGP is used to learn of PEs participating in the VPN, a MP2MP tree is not required. BSR still works because the BSR message is sent down the default MDT that is rooted at each PE. Instead of a single default MP2MP tree, there is a default MDT for each PE for which that PE is the root. This is analogous to P-PIM in the underlay using PIM-SSM.
Also notice that there is no VPN ID necessary for the VRF. The FEC opaque value becomes an auto-generated global ID value.
Verification
Each PE will advertise a type 1 route that includes the FEC for its own default P2MP MDT rooted at itself.
The C-PIM BSR messages will be sent down this P2MP. Specifically, because the BSR is CE1, PE1 will send the BSR message out the default P2MP MDT rooted at itself.
There is no C-PIM between PEs. Remember this is BGP in the overlay instead of C-PIM. However, because of the bug mentioned in a previous profile, XRv will continue to send Hellos.
Any (*, G) Join that a customer joins will be converted into a type 6 route, as we have seen before. For example, join 239.3.3.3 on C3 and verify that PE1 sees this as a type 6 route originated by PE3.
When traffic is sent from C2 to 239.3.3.3, this should prompt a type 5 route (source active) from CE2, and a type 7 route (S, G Join) from CE3.
Theory
Saying profile Z is “like profile X excepting doing Y” can become a bit confusing, so let’s breakdown each component:
Underlay: mLDP using only P2MP trees
Underlay discovery: BGP ipv4/mvpn (how PEs participating in the same VPN discover each other)
Overlay: BGP ipv4/mvpn (how PEs signal C-PIM state to each other)
C-PIM converted to BGP route converted back to C-PIM
Data plane encapsulation: MPLS
C-PIM BSR works inter-site?
Yes, BSR is sent out the data MDT as usual. The data MDT is just a P2MP tree instead of MP2MP. PEs join every other PE’s data MDT by learning about it via the type 1 route.
What happens when both the RP and LHR join the (S, G)?
I tested joining 239.3.3.3 on C3 and pinging this from C2. What happens is that PE1 generates a source active route (type 5), and both PE1 and PE3 generate their (S, G) Joins (type 7). However, these two type 7 routes are identical from the RR’s perspective, so it only chooses one.
Which one it chooses shouldn’t really matter though, because they say the same thing: “Translate this into a PIM Join for (10.1.2.1, 239.3.3.3)” The originator does not matter. Both PE1 and PE3 are already joined to the P2MP default tree rooted at PE2, so they both receive the traffic. If PE2 switches over to S-PMSI, it will originate the appropriate type 3 route. So again, this route type 7 is just a PIM Join equivalent - nothing to do with the mLDP tree.
Reducing state in the core by omitting “mdt auto-discovery mldp”
By default, a full mesh of P2MP trees is used for the default MDT. However, leaf PEs (which only connect to receivers and never connect to sources) don’t really need a P2MP rooted at themselves.
Let’s say that C2 and C3 are only receivers. We can omit the command mdt auto-discovery mldp under both PE2 and PE3, and everything still works. Receivers behind these PEs can join groups and receive multicast traffic.
In the core, you will now only see one P2MP default tree rooted at PE1. Likewise PE1 is the only router originating a type 1 route.
Above, C2 has joined (*, 239.22.22.22) and C3 has joined (*, 239.33.33.33). Source 10.1.1.10 is sending to both groups.
Note that a better way to handle this is to use the builtin receiver-only knob. This works just as we saw in profile 11. IOS-XE omits the type 1 route entirely, and IOS-XR removes the PMSI attribute from the type 1 route.
Last updated
