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
-----------------------
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.
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."
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 and ACL.
ip nat pool APP-OVERLOAD 40.40.40.41 40.40.40.41 netmask 255.255.255.252
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.
The need for "match-in-vrf" functionality in IOS-XE
---------------------------------------------------
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/
