Virtual template interface in a VRF: IPSec termination in a VRF doesn’t work.

L2TP interface in a VRF: This one was closest to working. In some software releases IPSec started, but the L2TP code was not (fully?) VRF-aware, so the LNS-to-LAC packets used global routing table. In other software releases IPSec would not start.

In short, a reasonable (although a bit kludgy) design that has been working for years on a 7200-series router is impossible to implement on an ASR 1000.

Before you start bashing Cisco, remember that ASR implements most of the packet forwarding process in hardware. While it’s very simple to stack together numerous randomly-selected features in a software implementation, it’s hard to do the same on a streamlined hardware platform.

Developing custom hardware is also way more expensive than writing a few more lines of C code. When designing a hardware implementation, one is thus temped to implement only the most commonly used combinations of features (or the features used by the biggest customers). If you happen to be relying on a rarely used set of features, you’re bound to have interesting problems.

With this in mind, it looks like you have only two options when deploying a device with hardware-assisted switching:

Minimize the number of features used by the device to an absolute minimum. This is not always a realistic option as you might be forced to increase the device count in your network (ASRs could be successfully deployed in our sample network if you’re willing to split L2TP termination and IPSec termination). You’re also left wondering why you’ve paid the premium for all the features you can’t use concurrently.

Work with someone who understands the device’s caveats and restrictions. If you’ve just started deploying new hardware in your network, you cannot be expected to know all its intricacies (although I’m positive your PHB thinks otherwise). Make heavy use of people who have done a similar job before. Engage Cisco’s Professional Services or a highly knowledgeable system integration partner (I wouldn’t even try to use resellers competing solely on low prices) that has extensive in-house lab facility (so they could stress-test the design before implementing it in your network).

Related posts by categories

12 comments:

weeks ago i came to the same conclusion about this so called NG platform - ASRi can add that ZBF with zone-pair in VRFs is also not working, same goes for NAT with VASI iface.concerning VRF-aware L2TP, which hardware/software version are you using? i've been successful with it!

I use it only for a single static point-to-point tunnel, so it's not very complex. However, it looks like it works for dynamic virtual template interfaces. Was there perhaps something specific that didn't work?

The overall goal was to provide a cheap backup route for inter-LAN connectivity between two sites. I use GRE-over-IPsec to provide the virtual WAN link.

The twist was that there are two sets of networks that must be routed across the virtual link to the remote side. I'll call them "SecureLAN" and "InsecureLAN." These networks exist at both sites, and each LAN is separated by a firewall at each site.

The routes distributed by the IGP within "InsecureLAN" and "SecureLAN" overlap with each other. Moreover, "InsecureLAN" must carry a default route through the virtual WAN link to the remote side.

What I did, instead of using two pairs of routers for each network, was to configure a pair of 3825 routers with two named VRF instances. One named VRF was used for the InsecureLAN, and another named VRF, "Inet", was used for the Internet-facing interface. SecureLAN was connected to the routers' global VRF.

IPsec operates within the "Inet" VRF only.

The reason I decided to create a named VRF for the Internet-facing LAN connection, and to use VRF-aware IPsec, is very similar to the reason you gave in your earlier post: It is much easier to manage and administer the router within the global VRF. Also, at deployment time, I believe there were some needed management options that were not VRF-aware in that IOS rev.

To finish talking about the design, two GRE tunnel interfaces are set up on each router, one for "InsecureLAN" and one for "SecureLAN." The IP address endpoints are the same for each tunnel interface; GRE keying is used to differentiate each tunnel.

Applying vrf to l2tp tunnels via radius seems to be a problem on the ASR's as well or is related. Once the vrf is set via the cisco avpairs the ipcp process stops and peers never get to learn/negotiate addresses. This has the effect that the tunnel addresses are not assigned and the framed routes are not placed in the vrf routing table.

I made L2TP/IPSEC work for VRFs on the 4451-X which has the same quantum flow architecture as the ASR. You must install an ACL to exclude your your VPN network from being NAT'd beforehand or you won't be able to ping anything other than an interface IP on directly connected interfaces and private networks derived by your VRF's IGP.

The author

Ivan Pepelnjak (CCIE#1354 Emeritus), Independent Network Architect at ipSpace.net, has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced internetworking technologies since 1990.