Intent checks can be used to verify that the network is working as intended following a network change.
Suppose we are performing a Change Control to route traffic from the Internet to a web application running behind a load balancer.
We are going to use an intent check to validate that the server is reachable from an Internet router.
Also check out my article on using Forward for Change Control:
We begin by performing a path search from the Internet router to the intended web app IP.
Note that traffic is currently dropped on the atl-edge-fw01 firewall.
We want to quickly validate that this traffic is delivered after the change, so we save the path search as an intent check.
Here we want to verify that at least one possible path exists between the source and destination.
Furthermore, we want to verify that the traffic is delivered, so we add status:delivered to the path search criteria, and click Next.
Give the intent check a name and intent description and click Create Intent.
Now that the intent check has been created, we see it listed under Verify > Intent.
The path search verification shows failed because we have not yet made a change, and the traffic is dropped on the firewall.
During the maintenance window, we make several routing and firewall changes.
We run a new collection, and see that the Intent Check is now passed.
Click on passed.
The History column on the left shows on which snapshots the intent check passes and on which snapshots it fails. As seen in the path card, the packet is delivered in the latest snapshot.
We can click on a previous snapshot in the history and look at files that changed during the maintenance. Note the change in the app3-web-vip object.
The firewall change was required for the NATed traffic on atl-edge-fw-1, which you can see by expanding the path details in the path card for that device.
By creating an intent check before the maintenance window, we reduce the time required to verify whether or not the change is successful, and automatically document the results!
