[c-nsp] VASI interface and NAT on ASR1k

[Derick Winkworth]

Matt:

As of IOS-XE 3.5, I am happy to report that "match-in-vrf" is supported.  This means you can merrily apply "ip nat outside" to a VASI interface.

We use VASI interfaces for this purpose.  VRFs are "paired" and linked together via VASI.  The global MPLS interfaces are "ip nat inside" and the VASI interfaces are "ip nat outside."  This gives us NAT overload in both directions.  Keep in mind that *all* NATs must be configured with the "match-in-vrf" keyword.

Additionally the VASI interface gives us an air-gap between disparate private networks.  Static routes are put into the VRFs pointing to the VASI interface (and thus to the opposite VRF in the pair).  These are redistributed into BGP against a route-map.  This route-map matches on a tag:

 "ip route vrf CUST-A-TO-B-VRF x.x.x.x ... tag 1000"  

If the tag is 1000, it gets redistributed with a local-preference of 1000.  If its 500 it gets redistributed with a tag of 500.  So we have a redundant ASR with the same config, different route-tags.  If the primary dies (or otherwise loses both links into the P core) then traffic will automatically re-route through the secondary ASR.

I believe you can get up to 500 pairs of VRFs in this scenario (only can configure 500 VASI pairs at this time).  The ASR itself is limited to an embarrassing 16k configured static NATS (boooo!).  

Lastly, if you intend to scale this configuration, then you will need to get an RP2 w/16GB of RAM and an ESP-40.  Not for throughput mind you, but because of how ridiculously memory hungry IOS-XE is.  The ESP-20 has 1GB of high-speed RAM shared between forwarding logic and NAT sessions.  With minimal routes you can support close to a million concurrent NAT sessions.  But if you put 500k routes across 500 VRFs on that box, you will only be able to support 400k of concurrent NAT sessions.  You'll want to go ahead and configure timeouts of one hour for NAT sessions in general on the box.

The ESP-40, on the other hand, has a different memory area for forwarding-logic vs NAT sessions.  Presumably the forward-logic will not step on the NAT, and you can get the million concurrent sessions.

Lastly there are only two real options to consider when buying a processor for the ASR 1K:  RP2 w/8GB of RAM or RP2 w/16GB of RAM.  Frankly Cisco shouldn't be selling anything less because of how much memory is required of newer versions of code.  Plus the performance of the RP1 from the CLI is *awful.*  


Or you could just go the way of linux and hack out a solution using iptables in containers and veth interface pairs... if it meets your requirements... 

*ahem* shameless plug:  http://packetpushers.net/network-interrupted 

 
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://packetpushers.net/author/dwinkworth/


________________________________
 From: Matthew Melbourne <matt at melbourne.org.uk>
To: cisco-nsp at puck.nether.net 
Sent: Monday, March 12, 2012 11:14 AM
Subject: [c-nsp] VASI interface and NAT on ASR1k
 
Hi,

Does anyone have any pointers to some real-world use cases for VASI
interfaces on an ASR1k? I have a corner case where I can't use MP-BGP to
import a route from one VRF into another, when the next-hop of the route is
in a separate VRF (the case is VRF-aware IPsec with FVRF/iVRF
configuration). It looks like the issue can be worked around using VASI
interfaces (i.e. a vasileft/vasiright pair). I have used a /30 to address
the VASI interfaces and this appears to work, but is this best practice? NAT
may be another useful requirement in this scenario, but I have seen other
cisco-nsp postings which suggests 'ip nat outside' shouldn't be configured
on an interface which isn't in the global table. A suggestions is that "ip
nat enable" and hence NVI be used in preference to classic NAT for VASI
interfaces? VASI does appear to be a rather poorly documented feature in
IOS-XE :)

Cheers,
 
Matt
 
-- 
Matthew Melbourne



_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/