Profile 13

Load basic.startup.config.with.cpim.cfg

#IOS-XE
config replace flash:basic.startup.config.with.cpim.cfg
Y

#IOS-XR
configure
load bootflash:basic.startup.config.with.cpim.cfg
commit replace
y

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 a MP2MP default tree, with P2 as the root.

• 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 12, except we use a MP2MP tree for the default MDT instead of P2MP trees. This means the type 1 route is not very useful just like we saw in profile 9, because we have to define the MP2MP root on every PE anyways. However, BGP is now used for overlay routing instead of C-PIM.

#PE1, PE2
vrf def CUSTOMER
 vpn id 100:1
 add ipv4
  mdt default mpls mldp 20.20.20.20
  mdt auto-discovery mldp
  mdt overlay use-bgp
!
router bgp 100
 add ipv4 mvpn
  neighbor 10.10.10.10 activate

#P1
mpls ldp mldp add ipv4
!
router bgp 100
 add ipv4 mvpn
 neighbor-group IBGP
  add ipv4 mvpn
   route-reflector-client

#P2
mpls ldp mldp add ipv4

#PE3
mpls ldp mldp add ipv4
!
router bgp 100
 add ipv4 mvpn
 neighbor 10.10.10.10
  add ipv4 mvpn
 vrf CUSTOMER
  add ipv4 mvpn
!
route-policy USE_MLDP_DEFAULT
 set core-tree mldp-default
end-policy
!
router pim vrf CUSTOMER add ipv4
 rpf top route-policy USE_MLDP_DEFAULT
 mdt c-multicast-routing bgp
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf CUSTOMER add ipv4
 mdt so lo0
 mdt default mldp ipv4 20.20.20.20
 bgp auto-discovery mldp
!
vrf CUSTOMER
 vpn id 100:1

Verification

The main difference between this and profile 12 is just that the default MDT uses MP2MP instead of P2MP. Before any C-multicast traffic is seen in the data plane, we will see just one MP2MP mLDP tree on P2. In profile 12 we would see three - one default P2MP rooted at each PE.

The overlay routing works as we saw before with BGP. But we can also notice the difference in auto-discovery in the type 1 route. The FEC type is a MP2MP tree this time. As we saw in profile 9, this route type is not very useful because the PEs all define the MP2MP manually anyways.

Remember that you must define the VPN ID under the VRF on all PEs for the MP2MP tree. This is not the case when using P2MP tree, as bgp auto-discovery is required and the PEs will auto-generate the opaque value (tree ID). Note that if you don’t define the VPN ID on IOS-XR it still appears to work in the lab under certain circumstances. It seems that the VPN ID is coming from the previously configured VPN ID on the VRF, even after resetting the config. However, you should still just manually configure it under the VRF each time.

mLDP OAM

We can use OAM for mLDP to verify the tree. First we’ll enable mpls oam on all XR routers.

#P1, P2, PE3
mpls oam

From any IOS-XE router, we can use ping mpls mldp to verify all receivers for the tree:

This also works from an IOS-XR PE:

IOS-XR also has the traceroute mpls mldp command available as well. This traces the path, exposing the transit routers in the tree:

Unfortunately, from an IOS-XR root of the MP2MP tree, we cannot ping or traceroute. However, from a IOS-XE root, it does work to ping. You will see replies from every receiver on the tree.

If we enable S-PMSI (data MDTs), we can verify P2MP trees as well.

#PE1
vrf def CUSTOMER
 add ipv4
  mdt data mpls mldp 100

#C2, C3
int gi0/1
 ip igmp join-group 232.1.1.1 so 10.1.1.10

#C1
ping 232.1.1.1 size 1400 time 1 repeat 10000

PE1 advertises a type 3 route (S-PMSI) for this (S, G) flow. Both PE2 and PE3 join the tree. If we ping the tree from PE1, we see both PEs as receivers.