We were inspired to build the project when we detected that a client had a problem, that he could not use two interfaces with NAT on SD-WAN because the DIA tracker could not do the Fallback and the end user lost access to the Internet. Seeing that there was no release for this problem, we decided to build a solution through programmability, and that this process of making Fallback work using two interfaces with NAT without the client having to intervene, because the client had to be turning off the Tacker interface every time the users reported that they did not have internet and be aware when the provider indicated that the failure was solved to re-upload the interface.
What it does
In SD-WAN when we use DIA we can configure a Tracker so that when the local internet link goes down, the traffic changes through the backup link that gives us access to the internet, either locally or through the Datacenter. This is achieved by removing the default route that DIA installs on the interface that has DIA NAT configured, but if two interfaces have NAT configured, it does not remove the route. If the Track is in the down state, it keeps trying to get traffic through the link that is down. Understood this, what the program does is the following:
The program creates and updates a database with the following information about the devices that are in vManage: Hostname, System IP, Track Status, Template ID, UUID.
The program will be constantly checking (adjustable time) the Tack status of the devices.
When it detects that the status of the track has changed to down, it will remove the template and through NETCONF it will eliminate the default NAT route (ip route nat), so that the internet traffic changes through the other link with which it learns the route default injected by the data center.
The program will send notification to WebexTeam or Microsof Teams of the status change and detachment of the Template and it will update the database with the new status of the Track.
When it detects that the status of the Track changed to UP, it will reattach the Template with the configuration of the device, including the NAT route.
The program will send notification to WebexTeam or Microsoft Teams of the status change and template attachment and update the database with the new tracking status.
How we built it
We first created the functions we were going to need and tested them one by one, to make sure it got the expected result. Then we build the database which would help us store the data we need to make use of them like last track status, system IP, template id, UUID.
After that we had the functions created and the database. We create the logical part of the program, where it is decided when and how to execute each function and what action to take based on the results, to achieve the objective of the program.
After the logic worked for us, we started to organize the code more and make the program more autonomous, the database update itself with the information obtained from vManage.
Finally, we decided to integrate with Webex Team, so that it would notify the user and monitor the actions carried out by the program.
Challenges we ran into
Make it totally autonomous, from the update and creation of the database, to the execution of the entire program and that does not require any action by the user.
Accomplishments that we're proud of
We are proud that despite not having the greatest development experience, we archieved to create a complete and functional program, with many things to learn and improve. But with the conviction that we archieved to create an application that we know can be useful to solve this problem and more so when the user has problems because when using a feature offered by the platform it does not work as expected.
What we learned
We learned that through programmability we have tools that help us solve problems and overcome limitations that may arise when we are implementing or managing a network, which can be reflected in operating costs.
We also learned to automate tasks that we perform repeatedly and manually, reducing execution times.
It opened our minds to understand how to integrate various platforms.
What's next for Fallback Track DIA solution when using NAT on two interfaces
This solution, in addition to being able to implement it in clients that are presented with these limitations with NAT DIA + Tracker. It's to show that through programmability, as a partner, we can look for these kinds of solutions for customers and not make them wait for a new release that can take months to come out.