[c-nsp] VASI NAT on ASR/IOS-XE solved... I hope.
Derick Winkworth
dwinkworth at att.net
Wed May 11 10:56:22 EDT 2011
That came out all jacked up, obviously. Will attempt to fix.
--- On Wed, 5/11/11, Derick Winkworth <dwinkworth at att.net> wrote:
From: Derick Winkworth <dwinkworth at att.net>
Subject: [c-nsp] VASI NAT on ASR/IOS-XE solved... I hope.
To: cisco-nsp at puck.nether.net
Date: Wednesday, May 11, 2011, 9:49 AM
Best viewed with a fixed width font... Bottom line if you intend to use the ASR in this fashion then by all means start harassing your account team to have "match-in-vrf" type functionality implemented on the ASR. Still the solution below works (as far as we have tested it), its just not as elegant as it could be...
___________________ / ___ ASR PE \ | / \ | | | A |-----+ | | \___/ | | | ___ _|_ | | / \ / \ | | | B |---| D | | | \___/ \___/ | | ___
| | | / \ | | | | C |-----+ | | \___/ |
\___________________/ | |to P-cloud | NAT with VASI on IOS-XE----------------------- In the diagram above we have a "NAT on an MPLS stick" solution. VRFs "A", "B", and "C" are each connected to VRF "D" over a pair of VASI interfaces. The MPLS interface facing the P-cloud is "ip nat inside" and all six of the VASI interfaces are "ip nat outside." VASI promises to more easily enable services between VRFs in a router. One of those services is NAT. In this post to C-NSP I'll describe how to do NAT over VASI. Suppose somewhere out in network "D" there are two servers. They house the
same application and for whatever reason some customers are on one server and some customers are on the other server. Both servers have RFC1918 addressing: 10.1.1.1 and 10.1.1.2. Customers are told to go after some URL that resolves to a public address: 40.40.40.40. Customer "A" comes in sourced on a public address they own and so you do not need to NAT their source. Their address is 30.30.30.30. This
customer should go to server 10.1.1.2. Also, server 10.1.1.2 needs to be able initiate outbound to this customer. Customer "B" comes in sourced on their own private addressing so you need to NAT their source to an RFC1918 address native to network "D." You will overload them to 10.140.1.1. This customer should go to server 10.1.1.2. The server does not initiate out to this customer. The customer has changed their local DNS so the URL resolves to 192.168.50.9. They would like you to NAT the server to this IP instead of 40.40.40.40. You have already NAT'd Customer "C" somewhere else in the network to an RFC1918 subnet native to network "D." Their address is 10.150.1.1. This customer should go to server 10.1.1.1. The server does not initiate out to the customer. Customer A ---------- ip nat inside source static 30.30.30.30 30.30.30.30 vrf VRF-A extendable ip nat outside source static 10.1.1.2 40.40.40.40 vrf VRF-A extendable ip route
vrf
VRF-A 40.40.40.0
255.255.255.0 vasileft1 ip route vrf VRF-D 30.30.30.30 255.255.255.255 vasiright1 Customer B ---------- ip access-list extended CUSTOMERB-NAT-ACL permit ip any any ip nat pool CUSTOMERB 10.140.1.1 10.140.1.1 netmask 255.255.255.0 ip nat inside source list CUSTOMERB-NAT-ACL pool CUSTOMERB vrf VRF-B overload ip nat outside source static 10.1.1.2 192.168.50.9 vrf VRF-B extendable ip route vrf VRF-B 192.168.50.9 255.255.255.255 vasileft2
ip route vrf VRF-D 10.140.1.1 255.255.255.255 vasiright2 Customer C ---------- ip nat outside source static 10.1.1.1 40.40.40.40 vrf VRF-C extendable
ip route vrf VRF-C 40.40.40.0 255.255.255.0 vasileft3 ip
route vrf VRF-D 10.150.1.1 255.255.255.255 vasiright3 Discussion ---------- The ASR has a couple of limitations
you should be aware of. First is that there is no "match-in-vrf" capability in IOS-XE. According to the release notes "ip nat outside" is not supported on a VRF subinterface. This contradicts VASI documentation that shows VASI interfaces in VRFs with "ip nat outside" configured. This limitation means that outside NAT statements in a VRF could be ignored as followed: (a) "ip nat outside" is configured on a VRF interface and (b) you initiate a session from a host in the outside domain of the VRF and (c) there is no *inside* NAT translation in the VRF for the destination. If you initiate a session from the inside domain then the outside NATs will always be applied as appropriate. The second limitation is that because there is no match-in-vrf capability on the ASR, you can not reuse global addresses in inside NAT statements. This is true even if the statements are for different VRFs. This is a callback to traditional NAT PE setups where you
were
always NATing traffic as it passed from an inside interface in a VRF to an outside interface in the global routing table. With these limitations in mind, lets talk about the NAT statements above. First, in order to have the same public address 40.40.40.40 translated to different addresses in network "D" you need to use extendable outside NAT statements. You configure these in the customer VRFs as appropriate. This is because of
limitation #2 above. For customer "A" we had to configure an inside NAT statement translating the customers source address to itself. I call this the "NAT itself hack." We do this so we can support the requirement of having 10.1.1.2 initiate outbound to the customer. Without this inside translation, the ASR would ignore the outside static NAT configured in the VRF. This is because of limitation #1. Customer "B" is
configured as you might expect them to be, there is no hackery there. Customer "C" is configured with just the outside static NAT because the customer is always initiating to the server, and as described above the ASR will always apply the appropriate outside NATs when the session is initiated from the inside domain. Lastly, you may wish to customize NAT overload for traffic coming in from network "D." In this case the diagram above changes so that there are three VRFs: "D1", "D2", and "D3." For the purposes of this discussion, all of them import and export the same route-targets. VRF-A connects to D1, VRF-B connects to D2, and VRF-C connects to
D3. ___________________ / ___ ___ \ | / \
/ \ | | | A |---| D1| | | \___/ \___/ | |
___ _ _ | | / \ / \ | | | B |---| D2| | | \___/ \___/ | |
___ ___ | | / \ / \ | | | C |---| D3| | |
\___/ \___/ | \___________________/ | |to P-cloud | For each overloaded address you use, you would create a NAT pool. Suppose you have two more servers in network "D." 10.1.2.1 and 10.1.2.2. These servers both reach outbound to all three customers for
the same application. Normally you would overload all traffic from these servers to 40.40.40.41. First, you would create the NAT pool. ip nat pool APP-OVERLOAD 40.40.40.41 40.40.40.41 netmask 255.255.255.252 Then create an ACL. ip access-list extended APP-OVERLOAD-ACL permit ip host 10.1.2.1 any permit ip host 10.1.2.2 any Then for customer A: ip nat inside source list APP-OVERLOAD-ACL pool APP-OVERLOAD vrf VRF-D1 overload Then for customer C: ip nat inside source list APP-OVERLOAD-ACL pool APP-OVERLOAD vrf VRF-D3 overload Notice how both A and C are referencing the same pool. This "pool-sharing" is a feature of IOS. It is necessary in this case because of limitation #2 described above. You are sharing the available source-port range across multiple VRFs. If "match-in-vrf" functionality were available on the ASR, you could reuse the entire port range per VRF in this scenario. Now suppose that customer B wants you to
overload to something else
for whatever reason. They tell you to overload this traffic to 192.168.50.10. ip nat pool CUSTOMERB-APP-OVERLOAD 192.168.50.10 192.168.50.10 netmask 255.255.255.252 ip nat inside source list APP-OVERLOAD-ACL pool CUSTOMERB-APP-OVERLOAD vrf VRF-D3
overload ip route vrf VRF-B 192.168.50.10 255.255.255.255 vasileft2
There are some other benefits to having a separate "D" VRF for each customer, but thats a different discussion. Why "match-in-vrf" functionality should be implemented on the
ASR------------------------------------------------- 1. No need for "NAT itself" hack. 2. For NAT
overload from the shared services network (network "D") outbound to the customers, we could reuse the entire source port range per customer. 3. The overall design would be much more elegant. All NATing for shared services devices would be inside NATs in the network "D" VRFs (as per the second diagram above). All customer NATing would be inside NATs in the customer VRFs. 4. No ambiguity about whether
or not VASI and NAT is actually valid. VASI documentation shows "ip nat outside" applied to VRF interfaces, but NAT documentation clearly states that this is not supported. Business units at Cisco need to talk to each other.
_______________________________________________
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/
More information about the cisco-nsp
mailing list