A. It was published through the following link:
https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-cloud-onramp-iaas-azure-deploy...
A.It was published through the following link:
This document will explain the steps and best practices for upgrading Cisco SD-WAN.
Using the link below, use the compatibility matrix embedded in the release notes to verify the version of the controllers (vManage, vBond, vSmart, and WAN Edges) or you can go to the SDWAN compatibility matrix webpage.
SD-WAN Release Notes https://www.cisco.com/c/en/us/support/routers/sd-wan/products-release-notes-list.html
SD-WAN Compatibility Matrix https://www.cisco.com/c/en/us/solutions/enterprise-networks/sd-wan/compatibility-matrix.html
As an example, if the controllers are running on release 19.3.x, the Edge devices should be running on the following versions 18.4, 19.2, 19.3. See below
Important: Controller versions must follow the compatibility matrix to avoid operational issues.
To upgrade the software running on the devices in the overlay network, download the new software packages from the Cisco SD-WAN website.
Visit the following link and select your hardware to validate the available releases, https://www.cisco.com/c/en/us/support/routers/index.html
Additionally you can go directly to the Software Download Center and download the available releases https://software.cisco.com/download/home/282770988
To upgrade all devices in the overlay network, perform the upgrade in the following order:
A: With each new version of code comes multiple bug fixes that improve product quality. The release notes contain all bug fixes that came in with that release. Release code versions 18.3 and older are now End-of-Sale and End-of-Life per the following notice: https://www.cisco.com/c/en/us/products/collateral/routers/sd-wan/eos-eol-notice-c51-743306.html
A: Yes, running a deferred release is not recommended and can cause that device has an abnormal behavior caused by a software defect.
The latest versions are located in the Software Download Center: https://software.cisco.com/download/home/282770988
A: No, you will need to upgrade the suite of controllers in the following manner: 1) vManage 2) vBond 3) vSmart. This is documented in the following link in the section entitled Best Practices for Software Upgrades:
Upgrading Cisco IOS XE Devices video: https://www.youtube.com/watch?v=qugfIlEmSEM
A: Yes! It is important to consider the upgrade path based upon your current controller version along with which version you will be upgrading to. The reason for this is because of schema changes in the database when upgrading to a version that is a major code release. Refer to the following upgrade path below:
17.1.x > 18.3.8 > 18.4.4
17.2.x- > 18.4.4
Note: From version 18.4.x you can upgrade to any other Cisco Release without mid steps
Q: Will I run into issues when upgrading vEdges from certain versions?
A: No, vEdges can be upgraded straight from version to version. please consider the compatibility matrix for the right match
Q: Will I run into issues when upgrading cEdges from certain versions?
A: No, cEdges can be upgraded straight from version to version. please consider the compatibility matrix for the right match
A: Yes, you should always follow the Compatibility Matrix provided in the release notes for each version. You never want your Edge device version to be higher than the controller version in your environment. For example, in the Compatibility Matrix section of the release notes below, you’ll see the following:
18.3 controllers > 18.3 vEdge and 16.9 XE SDWAN
18.4 controllers > 18.4 vEdge and 16.10 XE SDWAN
Q: Should I consider my Edge device version compared to my controller version?
A: Yes, you should always follow the Compatibility Matrix provided in the release notes for each version. You never want your Edge device version to be higher than the controller version in your environment. For example, in the Compatibility Matrix section of the release notes below, you’ll see the following:
A: The upgrade process is explained in the YouTube video below:
https://www.youtube.com/watch?v=qugfIlEmSEM
Additional information is available at:
A: Yes, not all Cisco routers support SD-WAN software.
You can do the migration from traditional IOS-XE to IOS-XE SD WAN software on the following devices,
ISR1000
ISR4000
ASR1000
Cat 8000
For example, SD-WAN is not supported on CISCO 2900 or 3900 series.
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:
System Tracker
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:
Apply to VPN0 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:
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:
How does the tracker look on vEdge10?
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.
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 |
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! 
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.
'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’.
the blog from the link:
https://ccieme.wordpress.com/2021/02/12/sd-wan-nat-tracker-lab/
complement：
NAT tracker by HTTP/HTTPS（TCP/80 or 443), not by ICMP, so you cannot tracker your up link if the
router didnot open the https/http server. cEdge support the NAT tracker at 17.3.1 version or later. the older version did not support the feature.
