Profile 14 with Extranet option #1
Last updated
Last updated
Load profile.14.extranet.1.init.cfg
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)
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.
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.
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.
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.
IOS-XE supports the following command, which upon first glance, appears to work exactly like IOS-XR’s set rpf-topology vrf command.
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.
See this detailed article from Luc De Ghein on extranet mVPN on IOS-XR: https://www.cisco.com/c/en/us/support/docs/ip/multicast/217600-configure-and-troubleshoot-mvpn-extranet.html#anc18
