In this service-side NAT configuration example, two vEdge routers—vEdge5 and vEdge6—are located at two different sites in
the overlay network and onnected to each other via the Internet. They are both configured as NATs. Router7 sits in the service
side behind vEdge5, and the local network at this site runs OSPF. Router8 sits behind vEdge6 on a network running IBGP.
vEdge5 NATs the source IP address 10.20.24.17, which originates on Router7, translating it to 10.15.1.4. From a NAT perspective
on vEdge5, the address 10.20.24.17 is an inside address.
When vEdge6 receives packets with the source IP address 10.15.1.4, it translates the address to 10.16.1.4. From a NAT perspective
on vEdge6, the address 10.15.1.4 is an outside address.
In addition, vEdge5 NATs the outside IP source address 10.20.25.18, which originates on Router8 (behind vEdge6), translating
it to 10.25.1.1.
The data policies to direct service-side traffic to the NAT are configured on two vSmart controllers, vSmart9 and vSmart10.
By default, OMP advertises all inside NAT pool IP addresses and all static NAT pool IP addresses, so all devices on the overlay
network learn these routes automatically. In this example configuration, we configure OSPF and BGP to redistribute outside
NAT pool IP addresses. The result is that OSPF on vEdge5 redistributes outside NAT pool IP addresses to its OSPF neighbor,
Router7, and BGP redistributes outside NAT pool IP addresses to its BGP neighbor, Router8.
Configure Service-Side NAT on the vEdge Routers
vEdge5 and vEdge6 are vEdge routers at two different sites. They are both connected to the Internet, and they are both are
running NAT.
On vEdge5, we configure a NAT pool that can translate four static addresses:
vEdge5(config)# vpn 1
vEdge5(config-vpn-1)# interface natpool1
vEdge5(config-natpool1)# ip address 10.15.1.4/30
vEdge5(config-natpool1)# no shutdown
With this configuration, the following IP addresses are available for static source IP address mapping: 10.15.1.4, 10.15.1.5,
10.15.1.6, and 10.15.1.7.
We then configure NAT on this interface:
vEdge5(config-natpool1)# nat
We want to enforce 1:1 static source IP address mapping:
vEdge5(config-nat)# no overload
If you omit this command, the default behavior is overload, which is effectively dynamic NAT. With the default behavior, all IP addresses are translated to an address in the pool of
NAT addresses configured in the ip address command. The addresses are mapped one to one until the address pool is depleted. Then, the last address is used multiple
times, and the port number is changed to a random value between 1024 and 65535. Overloading effectively implements dynamic
NAT.
For this NAT pool, we want network address translation to be performed only on inside IP source addresses. Inside address
translation is the default behavior. You can also explicitly configure it:
vEdge5(config-nat)# direction inside
For this example, we configure two NAT mappings. We want to NAT the source IP address 10.20.24.17, which is the IP address
of Router7, This address is an inside address; that is, it is an address at the local site. We also want to NAT the source
IP address 10.20.25.18, which comes from Router 8, a router behind vEdge6. This is an outside address.
vEdge5(config-nat)# static source-ip 10.20.24.17 translate-ip 10.15.1.4 inside
vEdge5(config-nat)# static source-ip 10.20.25.18 translate-ip 10.25.1.1 outside
We translate the inside source IP address 10.20.24.17 to 10.15.1.4. Because this NAT pool performs NAT only on inside IP source
addresses (direction inside), and because 10.20.24.17 is an inside address, the translated address must be one of the addresses in the IP address range
10.15.1.4/30, which is the IP address of the NAT pool interface (configured in the ip address command).
We translate the outside address 10.20.25.18 to 10.25.1.1. Because this NAT pool performs NAT only on inside IP source addresses,
we can translate outside addresses to any IP address that is routable on the service-side network behind vEdge5.
At vEdge6, we want to translate the source IP address 10.15.1.4, the translated address received from vEdge5, to an address
that is routable on the service network behind vEdge6. The NAT pool that we configure on vEdge6 performs NAT only on outside
addresses:
vEdge6(config)# vpn 1
vEdge6(config-vpn-1)# interface natpool2
vEdge6(config-natpool2)# ip address 10.16.1.4/30
vEdge6(config-natpool2)# no shutdown
vEdge6(config-natpool2)# nat
vEdge6(config-nat)# direction outside
vEdge6(config-nat)# static source-ip 10.15.1.4 translate-ip 10.16.1.4 outside
vEdge6(config-nat)# no overload
Here are the complete configurations for the static NAT pools on the vEdge5 and vEdge6 routers:
vEdge5# show running-config vpn 1 interface natpool1
vpn 1
interface natpool1
ip address 10.15.1.4/30
nat
static source-ip 10.20.24.17 translate-ip 10.15.1.4 inside
static source-ip 10.20.25.18 translate-ip 10.25.1.1 outside
no overload
!
no shutdown
!
!
vEdge6# show running-config vpn 1 interface natpool2
vpn 1
interface natpool2
ip address 10.16.1.4/30
nat
static source-ip 10.15.1.4 translate-ip 10.16.1.4 outside
direction outside
no overload
!
no shutdown
!
!
Configure Data Policies on vSmart Controllers
To direct service-side traffic to the NAT pool interface, you configure centralized data policies on the vSmart controllers.
Our example network has two vSmart controllers, vSmart9 and vSmart10. The data policies must be identical on both of them.
The basic structure of the data policy is to define the match criteria for the packets destined to the NAT interface and then,
in the action portion of the policy, to assign or direct the packets to a specific NAT pool. The data policy structure looks
like this:
For a data-policy
For a vpn-list
For a sequence number
Match specific criteria
Action accept
nat pool number
Apply the data-policy to all data traffic
In our example, we want a data policy that directs service-side traffic behind the vEdge5 router to the router's NAT pool
interface 1 (interface natpool 1). Here is one portion of the data policy (specifically, one of the sequences within the policy) that does this, defining
the service-side traffic by its source and destination IP addresses:
policy
data-policy accept_nat
vpn-list vpn_1
sequence 108
match
source-ip 10.1.17.0/24
destination-ip 10.25.1.0/24
!
action accept
count nat_108
nat pool 1
!
!
!
!
!
apply-policy
site-list vedge1
data-policy accept_nat all
!
!
This data policy snippet takes data traffic whose source IP address is in the range 10.1.17.0/24 and destination is 10.25.1.0/24,
accepts it, counts it to the file nat_108, and directs it to NAT pool 1. The source IP prefix 10.1.17.0/24 corresponds to
traffic originating from Router7. The destination IP prefix 10.25.1.0/24 is an IP address that the vEdge5 router has translated
from 10.20.25.18. This latter IP address corresponds to data traffic originating on Router8, so data traffic with a destination
IP prefix of 10.25.1.0/24 is delivered to vEdge6 and then to Router8.
The second configuration snippet applies the policy to all traffic passing through the router (all).
Configure Route Redistribution by OSPF and BGP
By default, OSPF redistributes routes learned from inside NAT pool prefixes into OSPF. In addition, no routes from any other
protocols are distributed into OSPF. The same is true for BGP.
In our configuration, we also want OSPF and BG to redistribute routes learned from outside NAT pool addresses. We also want
OSPF to redistribute connected, OMP, and static routes, and we want BGP to redistribute OMP and static routes.
vEdge5# show running-config vpn 1 router
vpn 1
router
ospf
redistribute static
redistribute connected
redistribute omp
redistribute natpool-outside
area 0
interface ge0/4
hello-interval 1
dead-interval 3
exit
exit
!
!
!
vEdge6# show running-config vpn 1 router
vpn 1
router
bgp 1
timers
keepalive 1
holdtime 3
!
address-family ipv4-unicast
redistribute static
redistribute omp
redistribute natpool-outside
!
neighbor 10.20.25.18
no shutdown
remote-as 2
timers
connect-retry 2
advertisement-interval 1
!
!
!
!
!
Verify the NAT Configuration
You use two commands to verify that the NAT configuration is operational: show interface and show ip nat interface.
The show interface command output indicates which NAT pool interfaces are configured and provides status about them. The command output for
the vEdge5 router shows that NAT pool interface 1 is administratively and operational up. This command output also shows information
about the other interfaces configured on vEdge 5.
vEdge5# show interface
IF IF TCP
AF ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE TYPE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 ipv4 10.1.15.15/24 Up Up null transport 1500 00:0c:29:7d:1e:fe 1000 full 1420 0:09:52:43 226385 228332
0 ge0/1 ipv4 10.1.17.15/24 Up Up null service 1500 00:0c:29:7d:1e:08 1000 full 1420 0:07:00:23 1262 10
0 ge0/2 ipv4 - Down Down null service 1500 00:0c:29:7d:1e:12 - - 1420 - 0 0
0 ge0/3 ipv4 10.0.20.15/24 Up Up null service 1500 00:0c:29:7d:1e:1c 1000 full 1420 0:07:00:23 1272 10
0 ge0/6 ipv4 57.0.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:3a 1000 full 1420 0:07:00:22 1262 9
0 ge0/7 ipv4 10.0.100.15/24 Up Up null service 1500 00:0c:29:7d:1e:44 1000 full 1420 0:09:52:04 2931 741
0 system ipv4 172.16.255.15/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:06:59:24 0 0
1 ge0/4 ipv4 10.20.24.15/24 Up Up null service 1500 00:0c:29:7d:1e:26 1000 full 1420 0:07:00:19 26310 25065
1 ge0/5 ipv4 56.0.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:30 1000 full 1420 0:07:00:19 1261 8
1 natpool1 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool7 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool8 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool9 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool10 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool11 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool12 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool13 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool14 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool15 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
1 natpool16 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:52:41 0 0
512 eth0 ipv4 10.0.1.15/24 Up Up null service 1500 00:50:56:00:01:0f 1000 full 0 0:09:52:42 19482 12745
Similarly, on the vEdge6 router, we can check that its NAT pool 2 interface is up:
vEdge6# show interface
IF IF TCP
AF ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE TYPE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 ipv4 10.1.16.16/24 Up Up null transport 1500 00:0c:29:d7:63:18 1000 full 1420 0:09:58:47 271786 294577
0 ge0/1 ipv4 10.1.18.16/24 Up Up null service 1500 00:0c:29:d7:63:22 1000 full 1420 0:07:06:18 1274 10
0 ge0/2 ipv4 - Down Down null service 1500 00:0c:29:d7:63:2c - - 1420 - 0 0
0 ge0/3 ipv4 10.0.21.16/24 Up Up null service 1500 00:0c:29:d7:63:36 1000 full 1420 0:07:06:18 1285 9
0 ge0/7 ipv4 10.0.100.16/24 Up Up null service 1500 00:0c:29:d7:63:5e 1000 full 1420 0:09:58:04 2971 746
0 system ipv4 172.16.255.16/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:07:05:28 0 0
1 ge0/4 ipv4 10.20.25.16/24 Up Up null service 1500 00:0c:29:d7:63:40 1000 full 1420 0:07:06:15 51457 50250
1 ge0/5 ipv4 60.0.1.16/24 Up Up null service 1500 00:0c:29:d7:63:4a 1000 full 1420 0:07:06:15 1273 8
1 ge0/6 ipv4 61.0.1.16/24 Up Up null service 1500 00:0c:29:d7:63:54 1000 full 1420 0:07:06:15 1255 8
1 natpool2 ipv4 - Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:05:56:37 0 0
1 natpool12 ipv4 - Down Down null service 1500 00:00:00:00:00:00 - - 1420 - 0 0
512 eth0 ipv4 10.0.1.16/24 Up Up null service 1500 00:50:56:00:01:10 1000 full 0 0:09:58:39 17650 11555
To display information about the NAT pools themselves, use the show ip nat interface command. Here is the command output for the vEdge5 router in tabular format and for vEdge6 in nontabular format:
vEdge5# show ip nat interface
FIB NUMBER
FILTER FILTER IP
VPN IFNAME MAP TYPE FILTER TYPE COUNT COUNT IP POOLS
-------------------------------------------------------------------------------------------------------
1 natpool1 endpoint-independent address-port-restricted 0 0 10.15.1.4/30 4
1 natpool7 endpoint-independent address-port-restricted 0 0 10.21.26.15/32 1
1 natpool8 endpoint-independent address-port-restricted 0 0 10.21.27.15/32 1
1 natpool9 endpoint-independent address-port-restricted 0 0 10.21.28.15/32 1
1 natpool10 endpoint-independent address-port-restricted 0 0 10.21.29.15/32 1
1 natpool11 endpoint-independent address-port-restricted 0 0 10.21.30.15/32 1
1 natpool12 endpoint-independent address-port-restricted 0 0 10.21.31.15/32 1
1 natpool13 endpoint-independent address-port-restricted 0 0 10.21.32.15/32 1
1 natpool14 endpoint-independent address-port-restricted 0 0 10.21.33.15/32 1
1 natpool15 endpoint-independent address-port-restricted 0 0 10.21.34.15/32 1
1 natpool16 endpoint-independent address-port-restricted 0 0 10.21.35.15/32 1
vEdge6# show ip nat interface
ip nat interface nat-vpn 1 nat-ifname natpool2
mapping-type endpoint-independent
filter-type address-port-restricted
filter-count 0
fib-filter-count 0
ip 10.16.1.4/30
Verify Routes and Route Redistribution
We configured OSPF and BGP to redistributes routes learned from outside NAT into OSPF and BGP, respectively. (We also configured
OSPF and BGP ro redistribute static and OMP routes, and we configured OMP to redistribute routes learned from directly connected
devices.)
To see where routes have been learned from, look at the Protocol field in the output of the show ip routes command.
Looking on the vEdge5 router, we see that OSPF has redistributed 10.15.1.4/30, a route learned from an inside NAT (these routes
are redistributed by default) and 10.25.1.1/32, a route learned from an outside NAT. The vEdge5 router translates the IP address
10.25.1.1 from 10.20.25.18. Both these routes have a next-hop interface of natpool1, which is the NAT pool we configured to
run static NAT.
vEdge5# show ip routes
Codes Proto-sub-type:
IA -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/0 10.1.15.13 - - - - F,S
0 10.0.20.0/24 connected - ge0/3 - - - - - F,S
0 10.0.100.0/24 connected - ge0/7 - - - - - F,S
0 10.1.15.0/24 connected - ge0/0 - - - - - F,S
0 10.1.17.0/24 connected - ge0/1 - - - - - F,S
0 57.0.1.0/24 connected - ge0/6 - - - - - F,S
0 172.16.255.15/32 connected - system - - - - - F,S
1 2.2.0.0/16 static - - - - - - - B,F,S
1 4.4.4.4/32 static - - - - - - - B,F,S
1 9.0.0.0/8 omp - - - - 172.16.255.16 lte ipsec F,S
1 10.1.17.0/24 static - ge0/4 10.20.24.17 - - - - F,S
1 10.1.18.0/24 omp - - - - 172.16.255.16 lte ipsec F,S
1 10.2.2.0/24 omp - - - - 172.16.255.11 lte ipsec F,S
1 10.2.3.0/24 omp - - - - 172.16.255.21 lte ipsec F,S
1 10.15.1.4/30 natpool-inside - natpool1 - - - - - F,S
1 10.20.24.0/24 ospf - ge0/4 - - - - - -
1 10.20.24.0/24 connected - ge0/4 - - - - - F,S
1 10.20.25.0/24 omp - - - - 172.16.255.16 lte ipsec F,S
1 10.25.1.0/24 static - - - - - - - B,F,S
1 10.25.1.1/32 natpool-outside - natpool1 - - - - - F,S
1 56.0.1.0/24 connected - ge0/5 - - - - - F,S
1 60.0.1.0/24 omp - - - - 172.16.255.16 lte ipsec F,S
1 61.0.1.0/24 omp - - - - 172.16.255.16 lte ipsec F,S
512 10.0.1.0/24 connected - eth0 - - - - - F,S
The vEdge6 router translates the outside source IP address 10.15.1.4 to 10.16.1.4. The route table on vEdge6 shows this route
and that it has been learned from an outside NAT. The next-hop interface for this prefix is natpool2.
vEdge6# show ip routes
Codes Proto-sub-type:
IA -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/0 10.1.16.13 - - - - F,S
0 10.0.21.0/24 connected - ge0/3 - - - - - F,S
0 10.0.100.0/24 connected - ge0/7 - - - - - F,S
0 10.1.16.0/24 connected - ge0/0 - - - - - F,S
0 10.1.18.0/24 connected - ge0/1 - - - - - F,S
0 172.16.255.16/32 connected - system - - - - - F,S
1 2.2.0.0/16 static - - - - - - - B,F,S
1 4.4.4.4/32 omp - - - - 172.16.255.15 lte ipsec F,S
1 9.0.0.0/8 static - - - - - - - B,F,S
1 10.1.17.0/24 omp - - - - 172.16.255.15 lte ipsec F,S
1 10.1.18.0/24 static - ge0/4 10.20.25.18 - - - - F,S
1 10.2.2.0/24 omp - - - - 172.16.255.11 lte ipsec F,S
1 10.2.3.0/24 omp - - - - 172.16.255.21 lte ipsec F,S
1 10.15.1.4/30 omp - - - - 172.16.255.15 lte ipsec F,S
1 10.16.1.4/30 natpool-outside - natpool2 - - - - - F,S
1 10.20.24.0/24 omp - - - - 172.16.255.15 lte ipsec F,S
1 10.20.25.0/24 connected - ge0/4 - - - - - F,S
1 10.25.1.0/24 omp - - - - 172.16.255.15 lte ipsec F,S
1 56.0.1.0/24 omp - - - - 172.16.255.15 lte ipsec F,S
1 60.0.1.0/24 connected - ge0/5 - - - - - F,S
1 61.0.1.0/24 connected - ge0/6 - - - - - F,S
512 10.0.1.0/24 connected - eth0 - - - - - F,S
View Interface Statistics
To display packet receipt and transmission statistics for the interfaces, use the show interface statistics command. The output shows the following statistics:
vEdge5# show interface statistics natpool1 | notab
interface vpn 1 interface natpool1 af-type ipv4
rx-packets 0
rx-octets 0
rx-errors 0
rx-drops 0
tx-packets 0
tx-octets 0
tx-errors 0
tx-drops 0
rx-pps 0
rx-kbps 0
tx-pps 0
tx-kbps 0
To display NAT-specific interface statistics, use the show ip nat interface-statistics command. The output shows the following statistics for each NAT pool:
vEdge5# show ip nat interface-statistics
ip nat interface-statistics nat-vpn 1 nat-ifname natpool1
nat-outbound-packets 0
nat-inbound-packets 0
nat-encode-fail 0
nat-decode-fail 0
nat-map-add-fail 0
nat-filter-add-fail 0
nat-filter-lookup-fail 0
nat-state-check-fail 0
nat-policer-drops 0
outbound-icmp-error 0
inbound-icmp-error 0
inbound-icmp-error-drops 0
nat-fragments 0
nat-fragments-fail 0
nat-unsupported-proto 0
nat-map-no-ports 0
nat-map-cannot-xlate 0
nat-filter-map-mismatch 0
nat-map-ip-pool-exhausted 0
View the Data Policy Pushed to the vEdge Routers
To view and verify the data policy pushed from the vSmart controllers to the two vEdge routers, use the show policy from-vsmart command. The following is the command output for the vEdge5 router. The output on vEdge6 is identical.
vEdge5# show policy from-vsmart
from-vsmart data-policy accept_nat
direction all
vpn-list vpn_1
sequence 100
match
source-ip 10.20.24.0/24
destination-ip 10.20.25.0/24
action accept
count nat
nat pool 1
sequence 101
match
source-ip 10.20.24.0/24
destination-ip 10.1.15.13/32
action accept
count nat_inet
nat use-vpn 0
sequence 102
match
dscp 15
action accept
count nat_dscp
nat use-vpn 0
sequence 104
match
source-ip 10.1.18.0/24
destination-ip 10.20.24.0/24
action accept
count nat2
nat pool 1
sequence 105
match
source-ip 10.1.18.0/24
destination-ip 10.1.17.0/24
action accept
count nat3
nat pool 1
sequence 106
match
source-ip 10.1.17.0/24
destination-ip 10.20.25.0/24
action accept
nat pool 1
sequence 107
match
source-ip 10.15.1.0/24
destination-ip 10.20.25.0/24
action accept
nat pool 2
sequence 108
match
source-ip 10.1.17.0/24
destination-ip 10.25.1.0/24
action accept
count nat_108
nat pool 1
sequence 109
match
source-ip 10.20.24.0/24
destination-ip 10.25.1.0/24
action accept
count nat_109
nat pool 1
default-action accept
from-vsmart lists vpn-list vpn_1
vpn 1
Configurations for Each Network Device
For each of the network devices in this configuration example, this section shows the portions of the configuration relevant
to the service-side NAT configuration.
vEdge5 Router
The vEdge5 router is located at site 500, has a system IP address of 172.16.255.15, and has one connection to the Internet:
system
host-name vm5
system-ip 172.16.255.15
site-id 500
!
vpn 0
interface ge0/0
ip address 10.1.15.15/24
tunnel-interface
encapsulation ipsec
color lte
hello-interval 60000
hello-tolerance 120
no allow-service bgp
allow-service dhcp
allow-service dhcpv6
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
!
no shutdown
!
!
In VPN 1, NAT pool 1 runs 1:1 static NAT:
vpn 1
interface natpool1
ip address 10.15.1.4/30
nat
static source-ip 10.20.24.17 translate-ip 10.15.1.4 inside
static source-ip 10.20.25.18 translate-ip 10.25.1.1 outside
no overload
!
no shutdown
!
VPN 1 also has a number of other NAT pool interfaces:
interface natpool10
ip address 10.21.29.15/32
no shutdown
!
interface natpool11
ip address 10.21.30.15/32
no shutdown
!
interface natpool12
ip address 10.21.31.15/32
no shutdown
!
interface natpool13
ip address 10.21.32.15/32
no shutdown
!
interface natpool14
ip address 10.21.33.15/32
no shutdown
!
interface natpool15
ip address 10.21.34.15/32
no shutdown
!
interface natpool16
ip address 10.21.35.15/32
no shutdown
!
interface natpool7
ip address 10.21.26.15/32
no shutdown
!
interface natpool8
ip address 10.21.27.15/32
no shutdown
!
interface natpool9
ip address 10.21.28.15/32
no shutdown
!
ip route 2.2.0.0/16 null0
ip route 4.4.4.4/32 null0
ip route 10.1.17.0/24 10.20.24.17
ip route 10.25.1.0/24 null0
!
OSPF runs in VPN 1 and is configured to redistribute routes learned from outside NAT prefixes into OSPF:
vpn 1
router
ospf
timers spf 200 1000 10000
redistribute static
redistribute connected
redistribute omp
redistribute natpool-outside
area 0
interface ge0/4
hello-interval 1
dead-interval 3
exit
exit
!
!
!
vEdge6 Router
The vEdge6 router is located at site 600, has a system IP address of 172.16.255.16, and has one connection to the Internet:
system
host-name vm6
system-ip 172.16.255.16
site-id 600
!
vpn 0
interface ge0/0
ip address 10.1.16.16/24
tunnel-interface
encapsulation ipsec
color lte
no allow-service bgp
allow-service dhcp
allow-service dhcpv6
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service netconf
no allow-service ntp
no allow-service ospf
no allow-service stun
!
no shutdown
!
!
VPN 1 has one NAT pool for static address translation:
vpn 1
interface natpool12
ip address 10.1.155.4/30
shutdown
!
interface natpool2
ip address 10.16.1.4/30
nat
static source-ip 10.15.1.4 translate-ip 10.16.1.4 outside
direction outside
no overload
!
no shutdown
!
ip route 2.2.0.0/16 null0
ip route 9.0.0.0/8 null0
ip route 10.1.18.0/24 10.20.25.18
!
BGP runs in VPN 1 and is configured to redistribute routes learned from outside NAT prefixes into BGP:
vm6# show running-config vpn 1 router
vpn 1
router
bgp 1
timers
keepalive 1
holdtime 3
!
address-family ipv4-unicast
redistribute static
redistribute omp
redistribute natpool-outside
!
neighbor 10.20.25.18
no shutdown
remote-as 2
timers
connect-retry 2
advertisement-interval 1
!
!
!
!
!
Router7 and Router8
Router7 sits in the local site behind the vEdge5 router, and it is an OSPF peer with vEdge5. Router8 sits behind the vEdge6
router and is an IBGP peer with vEdge6.
In our example network, both these routers are configured on vEdge software routers. However, there is nothing in their configuration
that specifically relates to static NAT, so we do not show the configurations for these two devices.
vSmart9 and vSmart10 vSmart Controllers
You configure the data policy that runs on the vEdge routers to direct data traffic to the NAT interfaces on the vSmart controllers.
The vSmart controllers then push the data policy to the appropriate vEdge routers. The configure data policy must be identical
on all vSmart controllers in the overlay network to ensure reproducible data traffic handling in the network.
Here is the complete policy configuration for the two vSmart controllers in our example:
policy
data-policy accept_nat
vpn-list vpn_1
sequence 100
match
source-ip 10.20.24.0/24
destination-ip 10.20.25.0/24
!
action accept
count nat
nat pool 1
!
!
sequence 101
match
source-ip 10.20.24.0/24
destination-ip 10.1.15.13/32
!
action accept
count nat_inet
nat use-vpn 0
!
!
sequence 102
match
dscp 15
!
action accept
count nat_dscp
nat use-vpn 0
!
!
sequence 104
match
source-ip 10.1.18.0/24
destination-ip 10.20.24.0/24
!
action accept
count nat2
nat pool 1
!
!
sequence 105
match
source-ip 10.1.18.0/24
destination-ip 10.1.17.0/24
!
action accept
count nat3
nat pool 1
!
!
sequence 106
match
source-ip 10.1.17.0/24
destination-ip 10.20.25.0/24
!
action accept
nat pool 1
!
!
sequence 107
match
source-ip 10.15.1.0/24
destination-ip 10.20.25.0/24
!
action accept
nat pool 2
!
!
sequence 108
match
source-ip 10.1.17.0/24
destination-ip 10.25.1.0/24
!
action accept
count nat_108
nat pool 1
!
!
sequence 109
match
source-ip 10.20.24.0/24
destination-ip 10.25.1.0/24
!
action accept
count nat_109
nat pool 1
!
!
default-action accept
!
!
lists
vpn-list vpn_1
vpn 1
!
site-list east
site-id 100
site-id 500
!
site-list vedge1
site-id 500
!
site-list vedge2
site-id 600
!
site-list vedges
site-id 500
site-id 600
!
site-list west
site-id 200
site-id 400
site-id 600
!
prefix-list prefix_list
ip-prefix 10.20.24.0/24
!
!
!
vm9# show running-config apply-policy
apply-policy
site-list vedge1
data-policy accept_nat all
!
site-list vedge2
data-policy accept_nat all
!
!
Feedback