This lab will examine another common use case referred to as Direct Cloud Access (DCA). As more and more organizations leverage cloud services such as IaaS/SaaS, backhauling Internet-bound employee traffic to a data center across the overlay fabric causes increased bandwidth and latency, resulting in a degradation of the application quality of experience (AppQoE). The solution to this problem is to enable local Internet exit to employees at remote branches. However, there is a big difference in the requirements when direct internet access is provided to guests and when it is provided to business users or employees. From a security standpoint, giving employees unrestricted access to the entire world-wide-web exposes the organization to some serious cyber security vulnerabilities. From an availability standpoint, if Internet access is used for business, it has to be available at any given moment irrespective of any local ISP failures.
In this lab example, we will show how a regional data center is used as a backup Internet breakout site for branches. We are going to enable DIA to VPN 1. However, this time the DIA would be used by employees, so we will make sure that the Internet access works in case of any direct or indirect failure within the local ISP. To achieve this objective, we will use two Cisco SD-WAN features called NAT Tracker and NAT Fallback.
What is NAT Fallback?
If we check the current data policy applied to the guest VPN, we will see that the nat use-vpn 0 action that does the DIA has an optional configuration argument called nat fallback.
vEdge-6# show policy from-vsmart ! from-vsmart data-policy DATA-POLICY-TO-SPOKES direction from-service vpn-list VPN6 sequence 10 match destination-data-prefix-list RFC1918 action drop sequence 11 match source-data-prefix-list PROXIES action accept count TRAFFIC-FROM-PROXIES nat use-vpn 0 no nat fallback default-action accept !
The NAT fallback configuration specifies what the forwarding behavior should be in case there are no local NAT-enabled interfaces that are operational. At the moment, if the biz-internet interface of vEdge-6 goes down, the local Internet exit will no longer be usable, and the guest VPN will no longer be able to access the Internet.
With the nat fallback enabled, if all NAT-enabled transport interfaces go to a non-operational state due to a failure, the local DIA traffic will follow the forwarding path determined by an IP lookup in the underlying VPN routing table. In other words, the nat fallback tells the vEdge router - “in case there is no local Internet-facing interface in an operational state, fallback to regular routing.”
In a typical SD-WAN deployment, this would mean that in case of a failure of the local ISP circuit, the local Internet-bound traffic would go across the overlay fabric and egress at a regional hub site or data center. However, a key point here is to understand what types of failure would trigger the fallback to regular routing. By default, only direct failures, such as all Internet-facing interfaces going down, would trigger the nat fallback process. That is why the nat fallback is typically combined with another feature called NAT DIA Tracker.
What is NAT DIA Tracker?
The NAT DIA tracker is a tool that detects indirect failures along the Internet path to a given external service. The tracker is configured on any NAT-enabled transport interface used for DIA. The tool works by sending probes to a configured external endpoint and monitoring whether probes fail or succeed. If the number of failed probes exceeds the configured threshold value, the tracker considers the external endpoint unreachable and makes the transport interface unavailable for DIA. The tracker continues to check the status of the external endpoint periodically. When it detects that the service is available again, the Internet-facing transport interface is available for NAT DIA again.
Lab Topology and Initial Config
The lab topology that we will use for this example is shown in figure 1 below. The overlay topology is hub and spoke with vEdges 1 and 2 acting as hub routers and the vEdges 3 - 6 being spokes. (VPN6).
Configuring NAT DIA Tracker
In this lab example, we will configure a tracker that monitors whether the public website linkedin.com is reachable through the biz-internet transport interface on vEdge-6, as illustrated in figure 2.
The tracker configuration goes under the system settings on a vEdge router. It is given a name (up to 128 lowercase characters), and then, at a minimum, an endpoint IP or DNS name is specified. The tracker is applied under the Internet-facing transport interfaces used for DIA on the local vEdge. In our example, this would be interface ge0/0.
vEdge-6# conf t Entering configuration mode terminal vEdge-6(config)# system vEdge-6(config-system)# tracker linkedin.com vEdge-6(config-tracker-linkedin.com)# endpoint-dns-name linkedin.com vEdge-6(config-tracker-linkedin.com)# interval 30 vEdge-6(config-tracker-linkedin.com)# multiplier 5 ! vEdge-6(config)# vpn 0 vEdge-6(config-vpn-0)# int ge0/0 vEdge-6(config-interface-ge0/0)# tracker linkedin.com vEdge-6(config-interface-ge0/0)# commit and-quit
Once the tracker is configured and applied under the transport interface, we can see that the interface ge0/0 reports that the “IF TRACKER STATUS” is Up.
vEdge-6# show int vpn 0 | t IF IF IF AF ADMIN OPER TRACKER ENCAP VPN INTERFACE TYPE IP ADDRESS STATUS STATUS STATUS TYPE PORT TYPE MTU ------------------------------------------------------------------------------------ 0 ge0/0 ipv4 184.108.40.206/16 Up Up Up null transport 1500 0 ge0/1 ipv4 10.10.0.1/16 Up Up NA null transport 1500 0 system ipv4 220.127.116.11/32 Up Up NA null loopback 1500
Before we show what will happen when the linkedin.com website becomes unreachable through ge0/0, let’s first enable DIA with NAT fallback on VPN 1.
First, we will need to configure a VPN list that matches VPN 1 and a data prefix-list that matches the enterprise IP addresses used within the VPN.
policy lists ! vpn-list VPN1 vpn 1 ! data-prefix-list ENTERPRISE-IPS ip-prefix 10.0.0.0/8 !
Then under the existing data policy DATA-POLICY-TO-SPOKES, we will configure a new section under VPN-list VPN1.
data-policy DATA-POLICY-TO-SPOKES vpn-list VPN1 sequence 11 match destination-data-prefix-list ENTERPRISE-IPS ! action accept ! sequence 21 action accept nat use-vpn 0 nat fallback ! default-action drop !
The policy’s logic is that sequence 11 matches all employee traffic destined to internal enterprise services. In our example, this would be all packets destined to 10.0.0.0/8. Then sequence 21 matches all packets that had not been matched at seq 11 and leaks them into VPN 0 and out to the Internet. Notice that this time, the nat fallback option is enabled.
At this point, clients in VPN 1 at branches should have Internet access while being able to reach any internal services over the sd-wan fabric.
vEdge-6# ping vpn 1 linkedin.com Ping in VPN 1 #pinging public Internet service PING linkedin.com (18.104.22.168) 56(84) bytes of data. 64 bytes from 22.214.171.124 (126.96.36.199): icmp_seq=1 ttl=127 time=20.1 ms 64 bytes from 188.8.131.52 (184.108.40.206): icmp_seq=2 ttl=127 time=22.9 ms 64 bytes from 220.127.116.11 (18.104.22.168): icmp_seq=3 ttl=127 time=12.8 ms ^C --- linkedin.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 12.891/18.655/22.924/4.233 ms ! vEdge-6# ping 10.1.1.1 Ping in VPN 0 #pinging enterprise service hosted at the hub PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=254 time=9.03 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=254 time=10.3 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=254 time=17.0 ms ^C --- 10.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 9.035/12.138/17.078/3.531 ms
In case of a failure of the Internet-facing interface or within the Internet path to linkedin.com, the NAT tracker will make the transport interface ge0/0 unavailable for DIA. Then, because the “nat fallback” option is enabled, the vEdge router will fall back to the VPN routing table. However, at the moment, there is no default route in VPN1’s route table, and the routers do not know where to forward any Internet-bound traffic.
vEdge-6# show ip route vpn 1 | t # there is no default route in VPN1 so Internet-bound traffic can’t be routed over the overlay fabric ADDRESS NEXTHOP VPN FAMILY PREFIX PROTOCOL IFNAME TLOC IP COLOR ENCAP STATUS ----------------------------------------------------------------------------------- 1 ipv4 10.1.1.0/24 omp - 22.214.171.124 mpls ipsec F,S 1 ipv4 10.1.50.0/24 omp - 126.96.36.199 mpls ipsec F,S 1 ipv4 10.1.50.0/24 omp - 188.8.131.52 biz-internet ipsec F,S 1 ipv4 10.6.1.0/24 connected ge0/2 - - - F,S
The first step to configuring the hub to act as a backup Internet breakout site is to inject a default route via OMP into VPN1. As of now, the only possibility to inject a default route into the overlay fabric via OMP is by using the static route “ip route 0.0.0.0/0 Null0”. Of course, this behavior may change in future software releases.
Let’s inject a default route into VPN1 from the hub’s WAN edge routers.
vEdge-1# conf t #for redundancy, we should configure this on vEdge-2 as well Entering configuration mode terminal vEdge-1(config)# vpn 1 vEdge-1(config-vpn-1)# ip route 0.0.0.0/0 null0 vEdge-1(config-vpn-1)# commit Commit complete.
Now you can see that vEdge-6 has a default route pointing to each hub’s TLOC.
vEdge-6# show ip route vpn 1 | t ADDRESS NEXTHOP VPN FAMILY PREFIX PROTOCOL IFNAME TLOC IP COLOR ENCAP STATUS ----------------------------------------------------------------------------------- 1 ipv4 0.0.0.0/0 omp - 184.108.40.206 mpls ipsec F,S 1 ipv4 0.0.0.0/0 omp - 220.127.116.11 biz-internet ipsec F,S 1 ipv4 0.0.0.0/0 omp - 18.104.22.168 mpls ipsec F,S 1 ipv4 0.0.0.0/0 omp - 22.214.171.124 biz-internet ipsec F,S 1 ipv4 10.1.1.0/24 omp - 126.96.36.199 mpls ipsec F,S 1 ipv4 10.1.50.0/24 omp - 188.8.131.52 mpls ipsec F,S 1 ipv4 10.1.50.0/24 omp - 184.108.40.206 biz-internet ipsec F,S
At this point, when a failure along the DIA path occurs, the spoke routers will fallback to the VPN routing table and successfully send the Internet-bound traffic to the hub. However, the hub is not configured to do DIA at the moment. (the current data policy is applied to site-list SPOKES, hence not sent to the hub’s vEdges)
Let’s create another centralized data policy named DATA-POLICY-TO-HUB and apply it to the hub’s vEdges.
data-policy DATA-POLICY-TO-HUB vpn-list VPN1 sequence 11 match destination-data-prefix-list ENTERPRISE-IPS ! action accept ! sequence 21 action accept nat use-vpn 0 ! ! default-action drop !
The logic is the same as in the data policy to spokes, with the only exception being that the nat fallback option is not enabled because there is no other Internet location that the hub can fall back to.
The key difference is the direction in which we will apply the policy. We applied the policy in the "from-service" direction on the spoke routers because they provide local Internet access to clients connected on the service-side in VPN 1. However, the hub should act as an Internet exit for traffic from spokes over the overlay fabric. Therefore, we will apply the hub's data policy in a “from-tunnel” direction.
apply-policy site-list HUB data-policy DATA-POLICY-TO-HUB from-tunnel
Now, if we introduce a failure and make the LinkedIn website unreachable over vEdge-6's interface ge0/0, we are going to trigger the following chain of events as illustrated in figure 3.
The NAT DIA tracker detects that the configured Internet endpoint linkedin.com is unreachable over the ge0/0 interface, even though the interface itself is up and running. This can be seen in the output of the show interface vpn 0 command.
Full Content Access is for Registered Users Only (it's FREE)...
- Learn any CCNA, DevNet or Network Automation topic with animated explanation.
- We focus on simplicity. Networking tutorials and examples written in simple, understandable language for beginners.