SD-WAN: NAT Tracker Lab

Ok so let’s get on with a lab around the NAT Tracker with DIA. The configuration for this is fairly simple (this is becoming a trend in SD-WAN!), so not too much to do. Cisco documentation will point you towards using templates for your task, but I am going to do this from the CLI.

There are 2 building blocks:

1. Setup system tracker
2. Apply to VPN0 NAT interface

System Tracker

Configured system tracker to http://www.google.co.uk

You have 2 options here for the endpoint of the IP or DNS name. If using DNS then be sure you have a DNS server configured within VPN0 where this applies:

Using 8.8.8.8 for DNS

Apply to VPN0 NAT Interface

tracker applied to ge0/1 in VPN0 – this being the NAT interface

Verify

This actually wasn’t obvious to work how you verify if the tracker is up or down. This was the best I could do:

Tracker is UP

So let’s cause an outage and break the connectivity from vEdge10 to the tracker endpoint – http://www.google.co.uk:80 – HTTP. The easiest way is stop the Internet interface on the WAN router towards EVE-NG:

Shut Gi0/3 on the WAN router, therefore breaking Internet access for vEdge10

Gi0/3 now shut

How does the tracker look on vEdge10?

Sure enough it is down

The expectation now is that the Internet traffic will route via the IPsec overlay, but really this depends on how you want the traffic to flow. In my lab there is no true backup way to the Internet via the MPLS transport. With more I could setup another Internet Gateway within the MPLS transport, but maybe some other time! I am happy with the concept and lab so far. 🙂 More on this below…

One last thing… timers! At a 1st glance the timers involved with the tracker seem confusing, so let’s break them down and be clear.

The 3 items we have when it comes to timers

Here is an extract from Cisco documentation:

Threshold	How long to wait for the probe to return a response before declaring that the transport interface is down. Range: 100 through 1000 milliseconds Default: 300 milliseconds
Interval	How often probes are sent to determine the status of the transport interface. Range: 10 through 600 seconds Default: 60 seconds (1 minute)
Multiplier	Number of times to resend probes before declaring that the transport interface is down. Range: 1 through 10 Default: 3

Summary of these terms and default values from Cisco documentation

• In my lab I have setup:
  • Threshold / How long to wait for the probe?
    • Left at default of 300ms
  • Interval / How often to send a probe?
    • Custom value of 10 seconds
  • Multiplier / Number of times to resend a probe before deciding it is down
    • (A bit like a dead timer in OSPF?) Left at default of 3 attempts

So based on the above, in my lab if there is a Tracker based failover, this would probe every 10 seconds, in the event of a failed probe it will wait 300ms to declare it a failure, then it will attempt this 3 times, therefore a total of 30 seconds + 300ms x 3, (so just shy of 31 seconds) will pass before there is a failover. Timers are always a headache with everything networking! 😛

DIA Failover to MPLS

Let’s go back to the failover of our biz-internet transport and how we would route internet traffic via the mpls transport.

We know that creating an outage between vEdge10 and http://www.google.co.uk does ‘kick in’ as in we see the tracker go down, but we haven’t tested or looked at this anymore that that.

Fallback Option

This is a simple ‘on and off’ switch on the policy, there is however an order of operation to traffic flow / routing.

Order of operations

1. Ingress ACL
2. Application Aware Routing
3. Centralized Policy (With Fallback enabled, we actually ignore this step and therefore hit step 4 – the route table.. so can you guess… we will need a route!)
4. Routing and Forwarding

Configuration Steps

1. Restriction of color at HQ site to avoid any complications
2. We need a default route within the VPN on the HQ vEdge to be advertised via OMP to other vEdge devices in the relevant VPN
   1. This will send traffic via mpls to specific site like a DC that will have an Internet breakout / this could be a firewall for example and then off to the internet via the firewall
   2. Add a static route within OMP to the HQ vEdge itself
3. Adjust NAT policy (edit existing DIA policy)
   1. On top of the Fallback option in the Sequence Rule, add a Local TLOC that is preferred – ‘biz-internet’

'show policy service-path vpn x interface ge0/x source-ip x.x.x.x dest-ip x.x.x.x protocol 1 all' 

Which policy is being preferred? Break biz-internet and then re-run the command, it should show the mpls / site 60 next hop (courtesy of the default route) instead of ‘biz-internet’.