Profile 19
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 unicast ingress replication in the core.
You cannot use PIM or mLDP in the core.
Use BGP for auto-discovery of participating PEs.
Configure PIM-SSM in the C-PIM.
PEs must form C-PIM adjacencies between each other.
NOTE: Profile 19 is not in the v5.1 blueprint.
See answer below (scroll down).
Answer
Instead of P-PIM or mLDP, we will use unicast ingress replication as the underlay. PEs must auto-discover each other using BGP.
Notice that we did not need to enable mLDP in the core. Ingress-replication uses the same unicast LSPs as unicast L3VPN. The difference is that the service label now represents multicast for the VRF instead of unicast.
Verification
Ensure that each PE sources a type 1 BGP route. The details should show that the tunnel type is IR and that a label has been allocated.
BSR did not work with this profile for me. Instead I enabled PIM-SSM in the C-PIM and joined a (S, G) on C2 for C1 as the source.
Traffic from C1 to 232.2.2.222 is encapsulated with two labels just as with unicast L3VPN. This pcap was taken on the Gi0/0/0/0 interface of P1.
24002 is P2’s label for 2.2.2.2/32
24 is PE2’s service label for multicast on the VRF. This was advertised by PE2 in the type 1 route.
Profile 19 does not appear to work on XRv. We can verify that XRv is receiving PIM Hellos from PE1 and PE2, but PE1 and PE2 do not receive Hellos from PE3.
Additionally, XRv will not send PIM Joins out the IRmdt interface.
Otherwise, the C-PIM works the same as we have seen before. The difference with profile 19 is that the default MDT is a collection of P2MP ingress replication trees.
S-PMSI
On PE1, configure support for data MDTs, or S-PMSI. C1 is the sender so we only need to enable this on PE1.
Start the stream on C1 and observe how PE1 advertises the S-PMSI.
Once the data crosses the defined threshold, PE1 advertises a type 3 route (S-PMSI autodiscovery). We have seen this in previous profiles. This advertises the customer S, G and the usually the tree to switchover to. However, we have no P-PIM or mLDP trees in the core. So this just contains an annoucement that “I have a customer S,G I would like to optimize by only doing IR to interested receivers.”
PE2 sends its own type 4 route which is a leaf auto-discovery route. PE2 is saying “I am interested in still receiving traffic for this S, G.”
The NLRI of the type 4 route contains the type 3 route that PE1 originated in brackets, plus PE2’s own loopback. PE2 includes its service label - the same label as seen in its type 1 route.
So the difference with IR S-PMSI is that the switchover occurs via auto-discovery of interested PEs using type 3 and type 4 routes. This happens with profile 19 even though we are still using C-PIM in the overlay instead of BGP as the overlay.
Last updated
