That came out all jacked up, obviously. Will attempt to fix. --- On Wed, 5/11/11, Derick Winkworth <[email protected]> wrote:
From: Derick Winkworth <[email protected]> Subject: [c-nsp] VASI NAT on ASR/IOS-XE solved... I hope. To: [email protected] 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
