Profile 14 with Extranet option #1

Load profile.14.extranet.1.init.cfg

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

#IOS-XR
configure
load bootflash:profile.14.extranet.1.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.

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

Configure profile 14 using extranet so that C3 in VRF B receives the multicast stream that is sourced from VRF A (10.1.1.10).
Do not change the RTs to solve this task.
PE3 should do RSC (receiver 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
multicast-routing vrf B 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
!
route-policy RPF_VRF_B
 if destination in (232.1.1.1/32) then
    set rpf-topology vrf A
 endif
end-policy
!
router pim vrf A add ipv4
 mdt c-multicast-routing bgp
 rpf topology route-policy RPF_VRF_A
router pim vrf B add ipv4
 mdt c-multicast-routing bgp
 rpf topology route-policy RPF_VRF_B
!
router bgp 100
 vrf A
  rd 100:1
  add ipv4 uni
  add ipv4 mvpn

#CE3
ip mroute 10.1.1.10 255.255.255.255 100.64.0.9

Explanation

An extranet provides reachability to external networks outside an intranet, typically in another VPN. This is commonly implemented with VRF RT manipulation. For unicast routing, this is somewhat simple - one VRF imports the other VRF’s VPNv4 routes using a route-target import policy. For multicast mVPN, this is a little more complex, as the multicast traffic must be stitched between each VRF.

In this lab we will do receiver side chaining (RSC). The egress PE will define the source mVPN VRF and stitch the traffic received on the source VRF into the receiver VRF. On IOS-XR, the solution is configuration intensive but not too complex.

First, we enable profile 14 for the source VRF, and define the source VRF on the egress 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

So far 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 enable mVPN profile 14 on VRF B. The “secret sauce” is that VRF B must use VRF A for the RPF check. If we have only certain group addresses or sources that need to use VRF A instead of VRF B, we can selectively control this using standard RPL logic. For example, we will only match source address 10.1.1.10/32 and set that to use VRF A for the RPF check. All other multicast traffic will use VRF B for the RPF check.

#PE3
multicast-routing vrf B add ipv4
 mdt source Loopback0
 bgp auto-discovery mldp
 mdt partitioned mldp ipv4 p2mp
!
route-policy RPF_VRF_B
 if source in (10.1.1.10/32) then
    set rpf-topology vrf A
 endif
 set core-tree mldp-partitioned-p2mp
end-policy
!
router pim vrf B add ipv4
 mdt c-multicast-routing bgp
 rpf topology route-policy RPF_VRF_B

Note that we did not have to mess with RT import policies to achieve this. We simply use the RPF to point the RPF check to VRF A.

Since we do not have a route to the source (10.1.1.10) in VRF B, we must use some sort of RPF fix on CE3. In this solution I use a static mroute.

#CE3
ip mroute 10.1.1.10 255.255.255.255 100.64.0.9

PE3 now has a (10.1.1.10, 232.1.1.1) entry in VRF B. However, we see no incoming interface. This appears to just be a bug, the RPF mechanism is actually working correctly. We see a EX flag on the entry, indicating Extranet.

PE1 receives a type 7 route that PE3 has generated. PE1 adds its Lspvif0 interface to the OIL for this entry.

If we send multicast traffic from C1, C3 will not reply since VRF B has no route back to the source. However, using the MFIB counter, we can verify that traffic is working. On CE3, we see that the outgoing packet count has increased proptionally to the traffic that was sent by C1.

A note on IOS-XE Extranet mVPN

IOS-XE supports the following command, which upon first glance, appears to work exactly like IOS-XR’s set rpf-topology vrf command.

ip mroute vrf B 10.1.1.10 255.255.255.255 fallback-lookup vrf A

However, I found that this only works when using C-PIM in the overlay. When using BGP as the overlay, this mroute does not appear to take affect at all. It appears that the router needs an actual PIM neighbor to use for the RPF check when looking up in another VRF. So this works for profiles such as 0, 1, 3, and 9. (Any profiles that use C-PIM as the overlay. The underlay doesn’t matter.) But I could not get this to work for more modern profiles such as 11/12/13/14 which are actually listed in the SPv5.1 blueprint.

Answer

Explanation

A note on IOS-XE Extranet mVPN

Further Reading