Profile 11
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.
Use PIM-SSM in the core with no RP.
Use BGP ipv4/mvpn for P-PIM signaling (allowing PEs to learn of each other).
PEs are not allowed to form C-PIM adjacencies. Instead use BGP to replace these functions.
See answer below (scroll down).
Answer
Just as before with profile 0 and 3, we are using P-PIM and GRE, so we must enable P-PIM in the core. (Remember to enable SSM on IOS-XE).
Next we need to activate the BGP ipv4/mvpn AFI/SAFI.
Now we define the data MDT group and set the overlay to use BGP instead of PIM. We also must set the autodiscovery to use BGP for PIM as before. P-PIM is used as the underlay, and BGP ipv4/mvpn is used to auto-discover participating PEs to build the (S, G) state in the core. BGP is also used for the overlay for C-multicast signaling. Note that on IOS-XR, the c-multicast-routing overlay is defined under PIM instead of under multicast-routing.
Verification
PEs no longer form C-PIM adjacencies. However XRv still sends hellos in the C-PIM, but this is just a bug. On PE1 verify that the only neighbor is PE3 (which is a bug). PE2 is not a neighbor.
Examine the bgp ipv4/mvpn route table. We should see a single route type 1 from each PE annoucing itself. This is used for auto-discovery to build the P-PIM underlay. We should also see a route type 6 for each (*, G) PIM Join sourced from the C-PIM.
Here, a customer router behind PE3 has sent a PIM Join for (*, 239.6.7.8) with the RP as 10.1.1.1
Interestingly, PIM BSR messages still work. The PEs suppress C-PIM Hellos but they still form the default MDT. The PEs will send the BSR messages on this default MDT so that all C-PIM routers can learn the BSR.
Theory
When we use BGP for the overlay, we use a few more ipv4/mvpn route types in order to replace functionality we had with C-PIM in the overlay.
In addition to the route type 1 routes we saw earlier, we will now see route types 5, 6 and 7. Route type 5 is a source active message, route type 6 is a (*, G) join, and route type 7 is a (S, G).
A PIM Join only needs to be sent to the upstream PE. For example, a (*, G) Join only needs to be sent to the PE that connects to the customer RP. But by default, the BGP route would be installed in the table of all PEs participating in the VPN. To better scale this, a RT is used that only the single PE for that source will import. The PE automatically generates this and includes it in all unicast vpnv4 routes. Then this is automatically attached to the mvpn route by an egress PE. An example will help explain this.
First, notice that the vpnv4 routes have an additional extcommunity attribute. This is the unicast route for 10.1.2.0/24 as seen on PE3:
Above, the manually-defined export RT of 100:1 is included, but also a VRF route import value of <PE’s loopback>:<auto-generated index> is included. Only PE2 will import this auto-generated RT into its VRF. This process is done automatically - you don’t need to configure PE2 to generate this extcommunity and import this RT. The Source AS information is used for inter-AS multicast which we are not concerned with right now.
If C3 joins a (S, G) rooted at CE2, then PE3 will originate a BGP route type 7 that is intended only for PE2. PE3 will attach the 2.2.2.2:1 RT to the route so that only PE2 imports it.
The NLRI contains the RD (100:1), ASN (100), Customer S (10.1.2.10) and Customer G (232.2.2.2).
The same RT process is used for a type 6 route, which is a (*, G) Join. For a type 6 route, the RP address is used in the source field instead of the true multicast source.
The route type 5 is seen when a source goes active. First I join 239.20.20.20 on C3 which prompts a (*, 239.20.20.20) PIM Join towards PE3. PE3 originates a type 6 route which PE1 imports (because the RP connects to the site behind PE1). Notice the RP address (10.1.1.1) is placed in the source field for this type 6 route.
This prompts PE1 to convert the BGP update to a PIM Join, and CE1 installs the state:
Next, C2 begins sending to the group. PE2 originates a source active message (route type 5), which all PEs import. This does not contain a MVPN RT value (so that all PEs in the VPN will import the route).
The route is fairly simple - the NLRI contains the Customer S (10.1.2.10) and the group it is sending to (239.20.20.20). This allows PE3 to build a (S, G) tree to the source, without needing to wait for the PIM Register and STP switchover in the customer network to do this. This allows the provider network to not allow any RP trees (*, G trees) at all if desired (I believe configured using mdt overlay use-bgp spt-only). Instead of needing PIM Registers, when a source starts sending, the Source Active message takes care of allowing the LHR to discover the source, which gives it the ability to join a (S, G) tree rooted at the newly discovered source. Note that for this to work, the RP needs to be placed on the PE. This allows the PE to generate type 5 routes based on received PIM Registers.
A note on SPT-switchover
When using C-PIM as the overlay, the SPT switchover process works the same as with regular PIM. The LHR sources a (S, G) Join to switchover to the SPT. The PE connected to the receiver site propagates this Join through the MVPN towards the RPF neighbor for the source. The PE connected to the site with the RP has two state entries:
(*, G) with IIF = towards RP, and OIL = tunnel
From the original (*, G) Join
(S, G) with IIF = tunnel and OIL = towards RP
From the RP joining the (S, G) to pull in the traffic from the source
The PE notices that it is the divergent point. It is receiving traffic on the (S, G) via the core and also the (*, G) via the RP. The PE prunes itself from the shared tree for (S, G) so that it stops receiving duplicate traffic. The PE sends a (S, G) RPT-bit Prune towards the RP. The RP removes the interface towards the PE from the OIL. The RP now is left with no interfaces in the OIL for (S, G), so it prunes itself off the (S, G). Now the PE has (S, G) state with a null OIL. The receiver in the other site only receives one copy of the traffic.
When using BGP for the overlay, we don’t have an equivalent BGP route that means “(S, G) RPT-bit prune.” (Although, remember that the PE directly connected to the RP’s site sources this Prune anyways). Instead, the source active message (type 5 route) triggers this process. The PE connected to the RP notices the SA and can conclude that all PEs have learned of the active source, so the RP’s functionality is not required. The PE then sources a (S, G) RPT-bit prune towards the RP, as traffic from that source is not needed to flow down the shared tree.
If you think through it more, the process is essentially the same as with C-PIM in the overlay, because the PE will create (S, G) state from the RP joining the (S, G). This will then forward the source traffic as native multicast (not unicast Register) through the MDT, and the source’s PE will send the route type 5. But the (S, G) RPT-bit prune process on the RP’s PE seem to happen in the same manner either way.
Last updated
