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/
