Profile 0
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 GRE tunneling over the core with profile 0.
C3 should be able to ping 239.1.2.3, with C2 responding. (IGMP joins are already pre-configured).
CE1 is configured as the RP using BSR.
Use PIM-SSM in the core with no RP, using P-PIM group 232.1.1.1.
See answer below (scroll down).
Answer
Configure BGP ipv4/mdt
Note: If you use ASM in the P-PIM and define an RP, you don’t need to use ipv4/mdt. Instead, each PE will define the default MDT as a non-SSM group (anything besides 232/8) and send a (*, G) join towards the RP. PEs will receive traffic from other PEs via the shared tree and therefore don’t need to discover each other via BGP.
Configure PIM-SM in the core. An RP is not required because we are using PIM-SSM with profile 0. Make sure to enable PIM-SM on the loopbacks of the PEs. This is necessary for the default MDT GRE tunnel interface which will use loopback0 as the source, and will be enabled for multicast.
Set the default MDT group address under the customer VRF on the PEs. By default, the peering address for the BGP ipv4 mdt AFI/SAFI is used for the mdt source interface on IOS-XE.
At this point, all CEs and PEs should learn CE1 as the RP via BSR. All PEs have PIM adjacencies with other PEs over the tunnel interface. These adjacencies are in the C-PIM, which is how the BSR information is propagated across the core to the other remote sites.
The core will have (S,G) state for each PE with the group as the default MDT group. PIM hellos and multicast traffic is encapsulated in a GRE packet with an outer header dst IP=232.1.1.1
C2 has already joined group 239.1.2.3. C3 should now be able to ping it.
Explanation
With profile 0, PIM is used in the provider core, and GRE tunneling is used to tunnel multicast control and data traffic between PEs in the customer VRF. The PEs form neighborships in the customer VRF PIM (C-PIM) between each other. PEs discover each other using BGP ipv4/mdt when using PIM-SSM instead of PIM-SM. From these BGP updates, the PEs join a multicast tree for (S, G) where S is the PE’s source IP address (nexthop of the BGP update), and G is the group address defined for the default MDT.
The group address for the default MDT needs to match among all PEs. This makes sense, because the PEs must both send and listen for traffic to the same group address.
You can verify the PEs participating in the MDT as learned via BGP with the following command. This does not ensure the P-PIM data plane is working, just that the BGP control plane is working:
This C-PIM overlay essentially emulates a LAN that is overlayed on the provider P-PIM. This is because an packet sent out the GRE tunnel with destination of the MDT group (232.1.1.1) is delivered to all participating PEs, which emulates the behavior of a LAN switch. You can sort of think of this as the PEs all connecting to a giant switch and running C-PIM over this switch. PIM behavior works the same as if these PEs were physically connected to a switch. We’ll walk through this in detail in the next section.
Also note that the loopback interface does the IGMPv3 join for the SSM groups. You don’t need to actually enable IGMPv3 anywhere. Notice that Lo0 is using IGMPv2, however it still originated the IGMPv3 Membership Report for the SSM groups:
Walkthrough of Customer Traffic
Before C3 has sent any traffic, all we have is a (*, 239.1.2.3) entry which receiver C2 has joined. CE1 is the RP, so the RPT tree is formed from CE1 down to C2.
On CE2 (LHR), we see the RPF neighbor for the RP is PE2:
On PE2, the RPF interface is the tunnel interface. PE2 sends a PIM Join out this tunnel for neighbor 1.1.1.1. We can think of the default MDT almost as a switch, in which all remote PEs are seen as directed connected out the tunnel interface. 1.1.1.1 is PE2’s RPF neighbor for the RP address, as 1.1.1.1 is the unicast nexthop for the RP (10.1.1.1). (This is normal PIM behavior, but now it is in a VRF context).
Shown below is PE2’s PIM Join towards PE1 to build the shared tree. Notice it is encapsulated in a GRE header with destination 232.1.1.1. As with normal PIM operation on a LAN, the PIM Join is multicasted to 224.0.0.13 but the upstream neighbor (PE1) is specified within the Join itself.
PE1 sends a PIM Join towards CE1, which is the RP (not shown)
CE1 now has the (*, G) state, with Gi1 in the OIL. The shared tree is fully built. This is no different than normal PIM-SM operation - the PEs just participate in the tree building process.
Next, C3 begins sending traffic.
CE3, acting as FHR, Registers the traffic with CE1. CE1 uses its Gi1 interface to source the Register. Note that you need to redistribute connected on PE3 in the VRF so that CE1 can send a Register Stop back to CE3’s WAN IP (100.64.0.10).
CE1 (RP) forwards the encapsulated traffic down the shared tree, back out Gi1. At the same time, CE1 joins the (S, G), sending a PIM Join out Gi1. PE1 sends the PIM Join to PE3 (PE1’s RPF neighbor for the source 10.1.3.10).
CE2 (LHR), upon learning the source, joins the (S, G) tree as well. CE2 sends a PIM Join to PE2. PE2 sends a PIM Join to PE3 (which is PE2’s RPF neighbor for the source 10.1.3.10).
CE1 sends a PIM Reigster Stop to CE3, as it begins receiving the traffic over the (S, G) tree.
PE1 is now the divergent point. It has two entries:
(*, G) with IIF = Gi2 (towards the RP), and OIL = tunnel1
(S, G) with IIF = tunnel1 and OIL = Gi2 (towards the RP)
Because PE1 is the branching point, it prunes itself off the shared tree for (S, G). PE1 sends this (S, G) RPT-bit Prune to CE1.
CE1 is now left with no interfaces in the OIL for (S, G), and it also prunes itself off the (S, G). Now PE1 has (S, G) with a null OIL.
The way that the RP is “on a stick” is a little confusing in these situations. However, the fundamental PIM operation doesn’t appear to change. The RP will receive Registers via the PE-CE interface and also send PIM Joins for (S, G) out this same interface. The directly connected PE will sense that the (*, G) and (S, G) entries are diveregent, and prune itself off the RPT for the (S, G). The result is that the multicast traffic will flow directly from the source to the receiver, and not go through the RP. However, there is an inefficiency here. When PE3 sends the traffic, it is encapsulated in the default MDT group 232.1.1.1, which PE1 still receives. PE1 receives the traffic on tunnel1 but does not send it out an interface (the OIL is empty). It would be more efficient if PE3 could send this traffic only to interested PEs, not all PEs.
Last updated
