Profile 14 with Extranet option #2

Load profile.14.extranet.2.init.cfg

#IOS-XE
config replace flash:profile.14.extranet.2.init.cfg
Y

#IOS-XR
configure
load bootflash:profile.14.extranet.2.init.cfg
commit replace
y

The basic IP addresses, L3VPN, and C-PIM between the PEs and CEs is pre-configured.

There are two VRFs: VRF A on PE1 and VRF B on PE3.

C1 has joined (10.1.3.10, 232.1.1.1). PIM-SSM is in use on both VRF A and VRF B.

• Configure profile 14 using extranet so that C1 in VRF A receives the multicast stream that is sourced from VRF B.

• PE3 should do SSC (source side chaining)

Answer

#PE1
vrf definition A
 address-family ipv4
  mdt auto-discovery mldp
  mdt partitioned mldp p2mp
  mdt overlay use-bgp

#PE3
vrf A
 address-family ipv4 unicast
  import route-target
   100:1
  !
  export route-target
   100:1
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf A add ipv4
 mdt source Loopback0
 bgp auto-discovery mldp
 mdt partitioned mldp ipv4 p2mp
!
route-policy RPF_VRF_A
 set core-tree mldp-partitioned-p2mp
end-policy
!
router pim vrf A add ipv4
 mdt c-multicast-routing bgp
 rpf topology route-policy RPF_VRF_A
!
router bgp 100
 vrf A
  rd 100:1
  add ipv4 uni
  add ipv4 mvpn
!
!
router static vrf A add ipv4 uni
 10.1.3.10/32 vrf B GigabitEthernet0/0/0/1 100.64.0.10
!
router bgp 100
 vrf A add ipv4 uni
  redistribute static

Explanation

In this lab we will do source side chaining (SSC). The ingress PE will define the receiver mVPN VRF and stitch the traffic received on the source VRF into the receiver VRF.

Unfortuantely we cannot use a RPF topology fixup on IOS-XR to accomplish this. For this reason, this option is not quite supported, but we can use a routing trick to implement this setup.

First, we enable profile 14 for the receiver VRF, and define the receiver VRF on the ingress PE, PE3.

#PE1
vrf definition A
 address-family ipv4
  mdt auto-discovery mldp
  mdt partitioned mldp p2mp
  mdt overlay use-bgp

#PE3
vrf A
 address-family ipv4 unicast
  import route-target
   100:1
  !
  export route-target
   100:1
!
multicast-routing add ipv4 int lo0 en
multicast-routing vrf A add ipv4
 mdt source Loopback0
 bgp auto-discovery mldp
 mdt partitioned mldp ipv4 p2mp
!
route-policy RPF_VRF_A
 set core-tree mldp-partitioned-p2mp
end-policy
!
router pim vrf A add ipv4
 mdt c-multicast-routing bgp
 rpf topology route-policy RPF_VRF_A
!
router bgp 100
 vrf A
  rd 100:1
  add ipv4 uni
  add ipv4 mvpn

As before with option 1, there is nothing new here. This is just profile 14 configuration. On PE1 we see that PE3 has sourced a type 1 and type 3 route for the mVPN.

Next we need a static route in VRF A (the receiver VRF) for the source via VRF B (the source VRF). This is redistributed into BGP VPNv4 for the receiver VRF. Note that the static route must have both the outgoing interface and nexthop. This is required so that VRF A can find the RPF neighbor for the source.

#PE3
router static vrf A add ipv4 uni
 10.1.3.10/32 vrf B GigabitEthernet0/0/0/1 100.64.0.10
!
router bgp 100
 vrf A add ipv4 uni
  redistribute static

On the egress PE, this now just looks like a normal source in the receiver VRF. PE1 joins a (S, G) via BGP route-type 7 and uses Lspvif0 as the incoming interface like usual.

The ingress PE is where the stitching is happening. We see the (S, G) in the receiver VRF, and that the RPF is via Extranet.

The RPF check on PE3 shows VRF B is used. Note that the static route needs the nexthop interface and address in order to complete the RPF check.

Since a route to the sender is present in the receiver VRF, the sender sees ICMP replies from the receiver.