Since the Cisco developer program (DevNet) began five years ago, we have seen huge growth and maturity of tools and platforms that enable engineers, operations teams, and software developers to deliver critical outcomes for their businesses. From the surge in growth of services in the public cloud to all of the open-source automation and orchestration platforms – such as Chef, Puppet, Ansible, so there has never been a better time to increase the way we tackle the challenges.

Our networks are composed of multiple operational domains (for example campus, data center, and security), that are tightly interconnected. However, engineers need more than interconnected domains to support customer and business needs. They need security, and an access policy that spans domains. And they need the agility to support new needs as they arise, with complete end-to-end visibility.

The need for tight integration, despite the differences in the domains, is one of the biggest drivers for moving to a controller-based, fully abstracted architecture.

Cisco Action Orchestrator provides a unified solution

Using Cisco Action Orchestrator we built a complete workflow. Action Orchestrator is a powerful workflow automation and technology-agnostic cross-domain orchestration product. This orchestration platform easily binds Cisco products together and connects smoothly to third-party products and open-source solutions, providing a unified solution. The following designs are applicable to provide advanced automation.

Imagine that your company wants to open a new store or remote office. When the company employees or customers connect on the network they need access to all their resources. This could be to enable applications to check stock, take payment, process invoices, or even just to safely surf the web. Ensuring your business is connecting safely and securely can be a challenge, this is where automation will help solve many of these once teething issue.

Let’s look at how we can deliver this, quickly and securely. Here we will focus on connecting the store to our data center and other locations and how we do this with Cisco SD-WAN API’s and Cisco Action Orchestrator.

Multi-Domain with Cisco SD-WAN

Our infrastructure must be flexible enough to accommodate those restraints. An intelligent, software-layer, such as SD-WAN, can change the inflexible and often slow networking models of the past. In the largest awareness, it is DevOps meets networking, this can be (and often is) referred to as ‘NetDevOps’.

When using Cisco Action Orchestrator we can use REST API calls to authenticate, to get a list of devices that are part of the SD-WAN fabric, and get device status deploying templates instantly connects our stores/remote office and data center networks. Now our routing algorithms accommodate application requirements and can adapt to real-time link conditions. The ability to connect any data services into the SD-WAN gives organizations amazing elasticity.

I’m hosting a free webinar on April 16 to dive into greater detail on Implementing SD-WAN Deployments. Register here to join.

Let’s go over the steps that are required

You must first establish an HTTPS session to the server. To do this, you send a call to log in to the server with the following parameters: URL to send the request to use URL: `https://{vmanage-ip-address/j_security_check` which performs the login operation and security check on the vManage web server at the specified IP address.  The API call payload. The payload contains the username and password in the format j_username=username&j_password=password.
After we have established the HTTPS session, we can list the devices attached to the fabric, we use the call that retrieves a list of all devices in the network. To retrieve this list, use the following URL: https://vmanage-ip-address/dataservice/device.  In the templates table, the Device Templates column indicates how many device configuration templates are using a particular feature template the next URL being called is URL: `https://{vmanage-ip-address/dataservice/template/feature` which show the devices in to which the feature template is deployed.
Once the new site/devices are identified we push and attach the feature template to the devices with URL: `https://{vmanage-ip-address/dataservice/template/device/config/attachfeature`.  Validation of the feature template is completed by URL: `https://{vmanage-ip-address/dataservice/template/device/config/attached/[id]` validates which sites/device.


Building the workflow in Cisco Action Orchestrator

Now we know our API’s we are using from Cisco SD-WAN, we can add these into Cisco Action Orchestrator. A workflow is basically a constructed workflow that consists of activities, invocations of child workflows, and logic components that can be included to complete the workflow. Action Orchestrator allows you to automate IT processes based on our requirements using a workflow format. Once we have added in our Cisco SD-WAN workflow the whole thing looks like this.

To kick this off, we simply hit the “RUN”. When you create a workflow, you must specify where you want the workflow to run. You can also specify that the workflow runs on a specific target or target group. The target group can be defined once and reused in several processes. For example, you might have a database maintenance process that is scheduled to run every month on all database servers. Instead of scheduling the process multiple times to run on each database server, you can create a target group that includes all the database servers and schedule the process to run on all the servers at the same time. If you choose to execute the process on a target group, you can further specify to run the process on all objects that are included in the target group or run the process on a specific object within the target group.

The colors associated with the individual activities determine the status of the process and activity instances, upon completion we see green which means our process has completed successfully (if any of the steps failed we would see these as red which means the process has failed and did not complete the process execution). We also see a 200 OK,  as our request succeeded, STATUS 200 OK appears in the results area, here our request was successful and we see a STATUS 200 OK and the result is contained in the response body.

Now our new device and location have had its template pushed to the end device and the traffic will begin to flow as expected and our new device has all our router, policy and security feature that our requirements for our company.

Register for one of the live webinars!

Want to know more?  Starting on April 9th, 2020, and continuing for the next 5 Thursdays, we will be holding BrightTALK webinars.  These 45-minute sessions will cover in detail the implementation of the above solution using Cisco Action Orchestrator and all of the platforms mentioned above.  Join one or join all!

Register now to join Matt Denapoli on April 9 for —
Intro to Multi-Domain Deployments

Register now to join me on April 16 for
Implementing SD-WAN Deployments

Register now to join Matt Denapoli on April 23 for
Implementing Meraki Deployments

Register now to join John McDonough on April 30 for
Implementing UCS/ACI Deployments

Register now to join Kareem Iskander on May 7 for
Implementing Cisco DNA Center Deployments

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel


Stuart Clark

Senior Developer Advocate Of Community, AWS