Option B mVPN
Load russo.pl.course.inter-as.opt.b.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 B is fully setup and working. Configure mVPN inter-AS using profile 11 (GRE over P-PIM with BGP C-multicast routing).
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 at the ASBR-ASBR links
The following links are shutdown:
The R8-R13 and R8-R14
The R1-XR12
Do not use XR12 as a PE for this lab
The XR11-R3
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 A mVPN, the ASBRs treat each other as PEs. They must enable mVPN on the VRF and run PIM with the ASBR. In inter-AS option B mVPN, the ASBRs simply exchange ipv4/mvpn routes. They do not run the customer VRFs.
The PEs run normal mVPN but with some slight modifications to enable inter-as support. First, the PEs must use the inter-as keyword so that the no-export community is not included on the routes.
Let’s examine the current state of the network. On R8 we see that it has learned about R6, but the IIF is null.
This is because we are running option B, so the PE loopbacks are not leaked between the ASs. R8 cannot perform an RPF check on R6’s loopback.
To fix this, there is a “hack” in PIM in which the ASBR can act as proxy for the PIM Join. R8 uses the BGP nexthop for the type 1 ipv4/mvpn route (10.2.3.2) as the PIM proxy vector. R2 finds the true root of the tree as 10.0.0.6 and builds the tree the rest of the way to R6. To enable this, we use the following command on the PE.
R8 now uses R2 as the “vector.” Note that R9 is the RPF neighbor. If XR is the RPF neighbor, this won’t work, even if I enable router pim add ipv4 rpf-vector. Perhaps it’s a bug. For this reason, the links to the XR routers are shut down.
On R3 we see state for all three (S, G) entries. The entry for R6 points to R2 via the NNI. Note that for this to work properly, we don’t seem to be able to use next-hop-self on R3 for ipv4/mvpn. (We can for vpnv4). R3 instead must redistribute the /32 into the IGP. (This was already set in the init file). The V flag means Vector.
If we were using C-PIM in the overlay, we would now see all PEs form a PIM adjacency. However, we are using BGP as the overlay instead.
R1 now joins the SSM group in the two VRFs.
R8 finds that the group has an RPF neighbor of R6. How does R8 know this? Isn’t the route to the source via 10.0.0.3?
This is because R6 adds a “connector” attribute to the VPNv4 route. As far as I know, this attribute is only used for inter-AS mVPN for this very purpose. It essentially retains the original nexthop and RD on the route.
R8 and R10 signal interest via BGP type 7 routes. They use the RD and ingress PE found from the VPNv4 connector attribute. The RT comes from the VPNv4 route as well (the MVPN VRF extcommunity attribute). The source AS field is used for the PE’s loopback when the route is inter-AS. 167772166 in decimal is 10.0.0.6. (Normally for intra-AS this field is the AS number).
This is advertised across the NNI and R6 learns of the best route. (XR14 only reflects the route from R10 due to highest RID, but this doesn’t matter, as only one route needs to be advertised to create the state at R6).
R6 adds this entry to the VRF MRIB. When R1 pings this group, R6 forwards the traffic down the default MDT, to which both R8 and R10 belong. The “client” in both VRFs responds.
Summary
Inter-AS option B mVPN seems to only support P-PIM in the underlay. This is because we need a way to proxy the tree building’s Join message at the ASBR. mLDP does not appear to have this feature. mLDP does have the recursive-fec feature, but this only allows the root’s nexthop to be used to proxy the tree building. This is available in option C. But in option B, we don’t even have a remote PE’s loopback in the RIB at all. Only PIM seems to let us use the BGP nexthop for the type 1 ipv4/mvpn route to proxy the PIM Join process.
For this reason, I don’t believe option B mVPN is often supported. It seems it would be easier to go with option C in order to build inter-AS mLDP trees.
Last updated
