Inter-AS L3VPN Pt. 3, Option B
In Option B, we will exchange the vpnv4 unicast table with the remote ASBR over the L3 NNI. We no longer need to define the VRF and create a sub-interface for each L3 VPN service we want to transport over this L3 NNI. We only need a single interface to run BGP vpnv4 unicast with the remote SP’s ASBR.
This allows for much greater scalability, but requires the SPs to trust each other and exchange their individual vpnv4 unicast tables. Route filters can be used to only export the necessary routes to the vpnv4 peer. However, you’d need the remote SP to tell you their RT values in order to filter incoming routes from them.
Let’s convert our Option A Inter-AS setup to Option B.
Lab
First we’ll remove the Option A config on SP1_R3 and SP2_XR1.
Next, ensure the L3 addresses for the NNI are on the physical interfaces.
Now we’ll configure a vpnv4 session between the two SP routers.
First, notice that IOS-XE has automatically added a command under the Gi2 interface:
Gi2 is not enabled for MPLS explicity, but it will need to send labeled traffic using the VPN label learned from SP2_XR1. IOS-XE automatically adds the mpls bgp forwarding command under the interface when you configure an eBGP neighbor for vpnv4 unicast.
Also look at the route-policy used on SP2_XR1. eBGP neighbors need a route-policy, so I decided to demonstrate a route-policy used to limit vpnv4 routes to only customer RTs that span this L3 NNI. This is not necessary, but is good practice.
Why aren’t the two routers learning any routes via the vpnv4 unicast address-family yet?
The answer is due to the bgp route target filter, which you saw in “An In-Depth Look at RD and RT, Pt. 1.” A router will automatically filter received vpnv4 routes if they do not contain an RT value that is configured locally on the router. In other words, if they router doesn’t think it “needs” the vpnv4 routes, it ignores them. Let’s disable this filter on both routers.
Both routers are now accepting the vpnv4 routes from their local RR, and advertising the routes to each other.
Is traffic working now between CE1 and CE2?
The answer is no. The PEs do not have the routes from the other SP in the table. Why is this?
Think back to the series on RD and RT. The reason both PEs do not import the routes into the VRF is because of the RT value. SP1 is importing and exporting 100:1. SP2 is importing and exporting 200:1.
In order to solve this, we’ll need to import the other SP’s RT on the VRF. You could say that in Option A, the RT is locally significant. Each SP does not care what the other SP is using for RT values. However, in Option B, the RT is now globally significant, as the SPs either need to coordinate on the RT to use, or they need to import the remote SP’s RT value into the local VRF.
Hmm, still no luck. We still don’t see the routes on the PEs. Can you figure out the issue?
Look route received at the local RRs from the routers connecting to the L3 NNI.
The next-hop is the public IP of the other router on the L3 NNI. Let’s implement next-hop-self on the two routers on the L3 NNI. By default, routers will set next-hop-self on vpnv4 routes when they themselves inject the route from a VRF. However, when learning a vpnv4 route from another eBGP router, the regular BGP rules apply, and the nexthop is unchanged.
Great, both PEs have the routes. The CEs have the routes as well.
However, pings end to end still are not working.
There is one final configuration we are missing. On IOS-XR, the router does not send labeled traffic to a next-hop learned via BGP unless it is a /32 route. Right now, the next-hop 100.1.1.1 is known via a connected /30. The router will not deliver labeled traffic to this IP. To work around this, we’ll configure a static /32 pointing out the connected interface. This might seem a bit silly, but it is necessary.
Pings are working now!
A traceroute shows three different service labels (24, 24008, 18):
Conclusion
Option B allows for greater flexibility compared to Option A. You do not need to configure the VRFs on the ASBRs, nor do you need a sub-interface for every single L3VPN VRF you are spanning across this L3 NNI.
Option B requires a bit more configuration to setup. You need to take the following items into account:
You must disable the RT filter on the router connecting to the L3 NNI, unless it happens to be acting as PE and already has the VRF defined.
no bgp default route-target filter on IOS-XE
address-family vpnv4 unicast retain route-target all on IOS-XR
You must import the remote SP’s RT into your VRF on the PEs. You could alternatively coordinate with the remote SP on the RT values but this is likely too much effort.
You must set next-hop-self on the routes advertised from the router on the L3 NNI edge to the internal RR.
mpls bgp forwarding is automatically added to the interface on XE.
On IOS-XR you must have a /32 route to the next-hop.
With Option B, the traffic between the two routers on the L3 NNI is now label switched instead of IP routed (as it is in Option A). There are three total VPN labels end-to-end.
The VPN label from the originating PE to the local ASBR
The VPN label from the local ASBR to the remote ASBR
The VPN label from the remote ASBR to the remote PE
Last updated