Option C mVPN
Load russo.pl.course.inter-as.opt.c.mvpn.init.cfg
NOTE: This is not working on CSR1000v 16.9.8. You will need to redeploy the topology with CSR100v version 17.x for this to work. This works on 17.3.2 for me.
L3VPN inter-AS option C is fully setup and working. Configure mVPN inter-AS using profile 11.
Use P-PIM in the core with SSM
PIM is already enabled everywhere, including on the ASBR NNI links
Use BGP for C-multicast signaling
BGP ipv4/mvpn is already configured within each AS, but not for the RR-RR BGP session
On R1, join (192.0.2.1, 232.1.1.1) within VRF L3B and L3C. Ensure that when R1 VRF L3A pings this group, both 172.16.18.1 and 172.16.110.1 respond.
Answer
Explanation
In inter-AS option C, all PE and RR loopbacks are distributed into each AS. This allows mVPN to operate as normal, provided the core tree can be setup. In profile 11, we use P-PIM in the underlay, so all routers must have routes to the remote PE loopbacks in order to build the PIM distribution tree hop-by-hop.
In AS65002, we are using BGP-LU for remote loopback reachability. BGP-LU is needed here because we are using SR, so we cannot simply redistribute loopbacks into the IGP and rely on LDP to allocate a label. However, this presents a problem when R8 tries to join an SSM group such as (R6, 232.0.0.1). Its neighbors XR13 and R9 do not have a route to R6, so their RPF check fails. (Another option would be to use PIM RPF proxy, but this in my opinion is more complex than just extending iBGP-LU on all P routers).
To solve this, we can run BGP-LU in a full mesh, including the P routers.
Next, the RRs run ipv4/mvpn as an additional address-family on the eBGP session.
Finally, the PEs enable mVPN as usual. The only interesting note is the inter-as keyword, which prevents the NO_EXPORT community from being attached to the BGP routes.
Verification
On R8, verify that it has learned the auto-discovery routes for the remote PEs:
R8 should join the SSM group in the P-PIM underlay:
The ASBRs should have SSM state for all four entries - one per PE. On R3 we see all four. The two remote PEs have an RPF neighbor of R2 given the lower MED we set in the previous lab.
XR11 is the preferred egress for R8 and R10 within AS65001, so XR11 holds the state for these two entries:
R2 holds the state for the R6, XR12 rooted entries, with OIL including the NNI to R3:
The P-PIM underlay is simply built by enabling PIM everywhere and ensuring that every single router has a route to the remote PE loopbacks.
Next, the BGP service routes are reflected between the RRs just like VPN/v4/v6 and l2vpn/evpn. We’ll join an SSM group on R1 VRF L3B and L3C, which will prompt a type 7 route from R8 and R10.
XR12 receives the route from R10 (due to highest RID), and adds the (S, G) entry in the MRIB for the VRF, with the OIL including the tunnel for the default MDT. Remember that XR12 is the bestpath to 192.0.2.1 because it receives the route from R1 with lower MED.
When R1 pings this group from L3A, both “hosts” in L3B and L3C respond.
Notes on mLDP as the underlay
mLDP can also easily be used for the underlay. You must enable mLDP everywhere (including the NNI). If using BGP-LU for the distribution of remote loopbacks (instead of redistributing into the IGP), then you also must enable recursive-FEC. This is only available on IOS-XR. There is a separate lab on this in the mVPN lab series using all IOS-XR routers.
Last updated
