Profile 3
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.
C3 should be able to ping 239.1.2.3, with C2 responding.
CE1 is configured as the RP using BSR.
Use PIM-SSM in the core with no RP.
Use BGP ipv4/mvpn for P-PIM signaling (how PEs learn of each other).
PEs should form adjacencies in the C-PIM.
See answer below (scroll down).
Answer
First enable P-PIM in the service provider core. Ensure PIM-SSM is enabled.
multicast-routing add ipv4 interface all enable is a shortcut on IOS-XR. You can just enable the interface for multicast-routing and it will automatically be enabled for PIM.
Next activate the ipv4/mvpn AFI/SAFI for the BGP sessions.
On IOS-XR we also need to activate the AFI/SAFI under the customer VRF even though no MP-BGP routes are exchanged under this VRF. Without this, the router will reject received ipv4/mvpn routes based on the received RT, because there are no associated VRFs that are activated for ipv4/mvpn and import that RT.
On the PEs, define the default MDT group and the fact that we should use BGP ipv4/mvpn for auto-discovery instead of BGP ipv4/mdt.
Verification
Verify that PEs become adjacent with one another in the C-PIM:
Verify that each PE only sources a single auto-discovery BGP Update which advertises its participation in the mVPN. This is a type 1, I-PMSI A-D route:
In the details of the route we can see the group address and the fact that this is using a PIM-SSM tunnel. There is no label because we are not using MPLS for the data plane, we are using GRE. Note that the label value of 0 is not really an exp-null as it appears to be interpreted in the output below. Instead it is “no label.”
We can also see the list of PEs for the MDT (I-PMSI) discovered via BGP using the same command as with profile 0 (when using ipv4/mdt):
Theory
The data plane here is the same as profile 0, using GRE. Additionally, the control plane is the same in the overlay, because all PEs are forming a full mesh of C-PIM adjacencies. The only difference is that BGP ipv4/mvpn is used instead of BGP ipv4/mdt. So we can say that the auto-discovery of PEs in the control plane is the only difference.
The use of BGP ipv4/mvpn is sometimes called “next generation mVPN”. BGP ipv4/mvpn has seven route types. This allows BGP to emulate and replace functions of PIM such as PIM Hellos, PIM Regsiters, and PIM Joins. PIM is a soft state protocol requiring constant state refresh. In contrast, BGP is hard state and also allows multiple routes for multiple VPNs to use a single BGP session. (With C-PIM in the overlay we need a full mesh of adjacencies for every single VPN).
Here are the seven route types. AD means “auto discovery.”
Route Type
Name
Purpose
Replaces PIM Function?
1
Intra-AS I-PMSI AD
Discover participating PEs in the C-PIM VPN
PIM Hello in the C-PIM
2
Inter-AS I-PMSI AD
3
S-PMSI AD
Switchover to data MDT (S-PMSI)
Replaces Data MDT advertisement in the Default MDT
4
Leaf AD
Autodiscovery for interested receivers for S-PMSI (Used with IR). The type 3 route contains a “Leaf info required” flag. In response, interested PEs send a type 4 route.
5
Source Active AD
Announce that a source is active so that the RP can join a (S, G) tree to the source. Similar to MSDP SA messages.
PIM Register
6
Shared Tree Join
Join a tree rooted at the RP for an ASM group.
(*, G) Join towards RP
7
Source Tree Join
Join a tree rooted at the source.
(S, G) Join towards Source
A PIM Prune is replaced with simply withdrawing a type 6 or type 7 route.
With next gen mVPN, the MDTs are given new names. The name MDT itself is replaced with PMSI (Provider Multicast Service Interface). This is because each PE has a virtual interface for the tree, whether it is a GRE interface or a virtual LSP interface. The default MDT is now called Inclusive PMSI or I-PMSI. This is because it includes all PEs participating in the VPN. Data MDTs are called Selective PMSI or S-PMSI, because only “select” PEs that have interested receivers participate in the tree.
Information about the PMSI tunnel is encoded in a new BGP attribute called the PSMI tunnel attribute. This contains the tunnel type (mLDP, RSVP-TE, PIM SSM, ingress replication), the label (used with ingress replication or when multiplexing multiple VPNs onto a single tree), and the tunnel identifier (PIM (S, G), mLDP FEC, RSVP-TE LSP, endpoint IP address for ingress replication).
For example, in our lab we only have one single route type, which is route type one. This is all that is needed for PEs to discover each other and then form PIM adjacencies. We can see the PSMI Attribute on the route which includes the tunnel type as PIM SSM and the tunnel ID as the (S, G):
PEs participating in the VPN use this information to source a (S, G) join in the P-PIM underlay for each PE they learn about via BGP mvpn type 1 routes.
Last updated
