Skip to main content
Viptela is now part of Cisco.
Support
Product Documentation
Viptela Documentation

Configuring Local Internet Exit

To configure a vEdge router to be an Internet exit point, you enable NAT within a VPN on the vEdge router, and then you configure a centralized data policy on a vSmart controller. This policy splits the traffic within the VPN so that some of it is directed towards remote sites within the VPN, and hence remains within the overlay network, and other traffic is directed to the Internet or other destinations outside the overlay network. It is also possible to configure a vEdge router to forward data traffic directly to the Internet, by specifying the destination IP prefix.

NAT Configuration Considerations

When configuring a vEdge router to act as a NAT device, keep the following considerations in mind:

  • For a vEdge router that is acting as a vBond orchestrator, do not enable NAT operation on the interface that is tied to the vBond orchestrator's IP address. If you do so, the orchestrator is placed into a private address space behind the NAT. For the overlay network to function properly, the vBond orchestrator must be in a public address space. You can, however, enable NAT operation on other vEdge router interfaces.
  • When you enable NAT on a vEdge router, the router NATs all traffic that is sent out through VPN 0. That is, both data traffic and control traffic are NATed.
  • The NAT operation on outgoing traffic is performed in VPN 0, which is always only a transport VPN. The router's connection to the Internet is in VPN 0. Performing the NAT operation in VPN 0 avoids the IPsec tunnels that carry data traffic within the overlay network.
  • If you configure NAT on multiple interfaces in VPN 0, ECMP is performed among the interfaces.
  • When you use NAT—either by configuring it on an interface or by setting it as an action in a centralized data policy—no route lookup is performed. Instead, traffic is forwarded to one of the available NAT default gateways.
  • The vEdge router NAT implementation uses end-point–independent NAT. If your network contains other NAT devices that interact with the vEdge router NAT, these devices must either perform end-point–independent NAT, or they must be configured with policy rules so that they do not change the port numbers for Viptela overlay network destinations.
  • When a vEdge router has two or more NAT interfaces, and hence two or more DIA connections to the internet, by default, data traffic is forwarding on the NAT interfaces using ECMP. To direct data traffic to a specific DIA interface, configure a centralized data policy on the vSmart controller that sets two actions—nat and local-tloc color. In the local-tloc color action, specify the color of the TLOC that connects to the desired DIA connection.

Direct Traffic to Exit to the Internet Using Data Policy

To use a centralized data policy to direct traffic from a vEdge router directly to the Internet, you enable NAT functionality in the WAN VPN or VPNs, and then you create and apply a centralized data policy.

Enable NAT Functionality in the WAN VPN

The first step in setting up Internet exit on a vEdge router is to configure the router to act as a NAT device. You do this by enabling NAT functionality in VPNs that have interfaces that connect to a WAN transport network. By default, VPN 0 always connects to the WAN transport. Other VPNs in your network might also connect to WANs.

To configure a vEdge router to act as a NAT device:

  1. Enable NAT in the desired VPN:
    vEdge(config)# vpn vpn-id interface interface-name nat
  2. By default, NAT mappings from the Viptela overlay network side of the NAT to the external side of the NAT remain active, and NAT mapping timers are refreshed regularly to keep the mapping operational. To also refresh NAT mappings of packets coming from the external side of the NAT into the overlay network, change the refresh behavior:
    vEdge(config-nat)# refresh bi-directional
  3. NAT sessions time out after a period of non-use. By default, TCP sessions time out after 60 minutes, and UDP sessions time out after 20 minutes. To change these times:
    vEdge(config-nat)# tcp-timeout minutes
    vEdge(config-nat)# udp-timeout minutes

    The times can be from 1 to 65535 minutes.
    The following NAT session timers are fixed, and you cannot modify them:
    • TCP session timeout if no SYN-ACK response is received—5 seconds
    • TCP session timeout if three-way handshaking is not established—10 seconds
    • TCP session timeout after receiving a FIN/RST packet—30 seconds
    • ICMP timeout—6 seconds
    • Other IP timeout—60 seconds
  4. By default, the vEdge router does not receive inbound ICMP error messages. However, NAT uses ICMP to relay error messages across a NAT. To have the router receive the NAT ICMP messages:
    vEdge(config-nat)# no block-icmp-error
    In case of a DDoS attack, you might want to return to the default, to again prevent the vEdge router from receiving inbound ICMP error messages.

Create a Data Policy to Direct Traffic to the Internet Exit

To direct data traffic from a vEdge router to an Internet exit point, you split the destination of the traffic within a VPN, sending some to remote sites in the VPN and directing the traffic that is destined to the Internet (or other destinations outside the overlay network) to exit directly from the local vEdge router to the external destination.

To split the traffic, configure a centralized data policy on a vSmart controller:

  1. Configure the source prefix of the data traffic:
    vSmart(config)# policy data-policy policy-name
    vSmart(data-policy)# vpn-list list-name
    vSmart(vpn-list)# sequence number
    vSmart(sequence)# match source-ip ip-prefix
  2. Configure the destination of the data traffic, either by IP prefix or by port number:
    vSmart(sequence)# match destination-ip ip-prefix​​
    vSmart(sequence)# match destination-port port-number
  3. Direct matching data traffic to the NAT functionality. You can optionally configure a packet counter.
    vSmart(sequence)# action accept
    vSmart(accept)# count counter-name
    vSmart(accept)# nat use-vpn 0
  4. Configure additional sequences, as needed, for other source prefixes and destination prefixes or ports, and for other VPNs.
  5. Change the default data policy accept default action from reject to accept. With this configuration, all non-matching data traffic is forwarded to service-side VPNs at remote sites instead of being dropped.
    vSmart(vpn-list)# default-action accept
  6. Apply the data policy to particular sites in the overlay network:
    vSmart(config)# apply-policy site-list list-name data-policy policy-name from-service

Direct Traffic To Exit to the Internet Based Only on IP Prefix

You can direct lcal data traffic to exit to the internet based only on the destination IP prefix. To configure this, in the service VPN, forward traffic that is destined towards an internet location to VPN 0, which is the WAN transport VPN:

vEdge(config)# vpn vpn-id
vEdge(config-vpn)# ip route prefix vpn 0

In the vpn command, specify the VPN ID of the service-side VPN from which you are sending the traffic. In the ip route command, prefix is the IPv4 prefix of the remote destination.The vpn 0 option configures the software to perform the route lookup in VPN 0 rather than in the service-side VPN. This is done because the service-side VPN cannot resolve the route.

For the traffic redirection to work, in VPN 0, you must enable NAT on the interface associated with the configured prefix:

vEdge(config)# vpn 0 interface interface-name nat

Here, the interface is the one to use to reach the destination prefix.

The following snippet illustrates the two parts of the configuration:

vEdge# show running-config vpn 1
vpn 1
 ...
 ip route 10.1.17.15/32 vpn 0
!
vEdge# show running-config vpn 0
vpn 0
 ...
 interface ge0/1
  ...
  nat
  !
  no shutdown
 !
!

To verify that the redirection is working properly, look at the output of the show ip routes command:

vEdge# 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    10.1.17.15/32       nat        -         ge0/1    -                0        -                -                -      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    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  

In VPN 1, the prefix 10.1.17.15/32 is associated with the protocol "nat", which reflects the configuration of the ip route command in VPN 1. For this prefix, the next-hop interface is ge0/1, and the next-hop VPN is VPN 0. This prefix is installed into the route table only if the resolving next hop is over an interface on which NAT is enabled.

The prefix that you configure in the ip route represents a route in the specified VPN (the service VPN whose ID you enter in the first command above). To direct traffic to that prefix, you can redistribute it into BGP or OSPF:

vEdge(config-vpn)# bgp address-family address-family redistribute nat
​vEdge(config-vpn)# ospf redistribute nat

 

Track Transport Interface Status

When you enable NAT on a transport interface to allow the local router to forward traffic directly to the internet rather than first forwarding the traffic to a data center router connected to the internet, the router directs data traffic according to the centralized data policy that is applied to that interface, forwarding some traffic directly to the internet (or other external network) and other traffic to other VPNs in the overlay network, including the data center. If the internet or external network becomes unavailable, for example, due to a brownout, the router has no way to learn of this disruption, and it continues to forward traffic based on the policy rules. The result is that traffic that is being forwarded to the internet is silently dropped.

To prevent the internet-bound traffic from being dropped, you can configure the router to track the status of the transport interface and to redirect the traffic to the non-NATed tunnel on the transport interface when the local internet is unavailable. With tracking enabled, the router periodically probes the path to the internet to determine whether it is up. When it detects that the path is down, the router withdraws the NAT route to the internet destination, and reroutes the traffic to the non-NATed tunnel on the interface so that another router in the overlay network can forward the traffic to the internet. The local router continues to periodically check the status of the path to the interface. When it detects that the path is again functioning, the router reinstalls the NAT route to the internet.

To track the transport interface status, you create a global interface tracker, and then you apply it to the transport interface on which NAT is enabled.

To create a transport interface tracker:

vEdge(config)# system
vEdge(config-system)# tracker tracker-name
vEdge(config-tracker)# endpoint-dns-name dns-name
vEdge(config-tracker)# endpoint-ip ip-address
vEdge(config-tracker)# interval seconds
vEdge(config-tracker)# multiplier number
vEdge(config-tracker)# threshold milliseconds

At a minimum, you must specify the IP address or DNS name of a destination on the internet. This is the destination to which the router sends probes to determine the status of the transport interface. You can configure either one IP address or one DNS name.

By default, a status probe is sent every minute (60 seconds). To modify this value, change the time in the interval command to a value from 10 through 600 seconds.

By default, the router waits 300 milliseconds to receive a response from the internet destination. To modify the time to wait for a response, change the time in the threshold command to a value from 100 through 1000 milliseconds.

By default, after sending three probes and receiving no responses, the router declares that transport interface is down. To modify the number of retries, change the number in the multiplier command to a value from 1 through 10.

You can configure up to eight interface trackers.

To apply a tracker to a transport interface:

vEdge(config)# vpn 0
vEdge(vpn)# interface interface-name
vEdge(interface)# tracker tracker-name

You can apply only one tracker to an interface.

  • Was this article helpful?