Whenever we are introduced to new tools, systems and quite commonly programming languages, one of the first things we do is output “Hello World”. This is a very basic sanity test that can be used to make sure the system is properly installed and ready to go.

In this blog, we will walk through the steps to get to ‘Hello World’ by using native Ansible modules with Versa Director and explore basic automation.

Why Ansible?

Firstly, one may ask why we need to use Ansible. In this Agile and DevOps era, tools like Ansible have become quite popular with Engineers to automate their operational and configuration management tasks. From the business perspective, it is debated that reliability is the main motivation behind automation, while speed of execution and scale are also factors to consider, but honestly the Engineer is really interested in “automating the boring stuff”.

Network Engineers used to manually create 10-100s of VLANs on switches and right away saw this as an immediate candidate for automation. Similarly, in the Versa Networks Secure SD-WAN solution, while it is inherently a rich automation solution, there are opportunities to leverage external tools like Ansible for more automation. Simple use-case is creating 10-100s of similar (branch) devices that are members of a common and existing device-group using a common device-template previously configured on Versa Director.

Resources required :

  • Versa Director REST API interface (20.2.1 or above)
  • Ansible – uri modules

In Networking jargon, ‘Hello World’ is synonymous to querying version information of the system software, as this is probably the safest command/operation to execute, for instance a ‘show version’.

The interface available for external systems to interact with Versa Director is REST API, where we can execute GET, POST, PUT, DELETE transactions. We will use the Ansible uri module to perform a GET operation against the system’s package-info API resource:

https://<vd-director>:<vd-port>/api/operational/system/package-info

A very handy method of discovering API url resources is using the web browser’s developer tools to analyse the backend REST API calls executed by Versa Director as documented here [Versa Networks Partners and Customers access required]

In Ansible, tasks are organised in a playbook against a list of targeted devices. Below is a playbook that will give us our ‘Hello World’, i.e package information (version) of our Versa Director. For simplicity, the hosts in this case is ‘localhost’ which is where we will be executing the tasks on:

---
- name: Get version of Versa Director
  hosts: localhost
  gather_facts: no
  tasks:
    - name: Get version info
      uri:                                        # Ansible Module
        url: "https://10.48.58.101:9182/api/operational/system/package-info"
        method: GET                               # REST API GET method
        user: "Administrator"                     # REST API Username for Basic Authentication
        password: "XXXXXXXX”                      # REST API Password for Basic Authentication
        headers:
          Accept: application/json
          Content-Type: application/json
        return_content: yes
        force_basic_auth: yes
        validate_certs: no                        # Disable HTTPS/SSL Certificate verification
        follow_redirects: all
        timeout: 60
      ignore_errors: yes
      register: package_info

Result of executing this playbook:

Device Creation Task

The goal of using Ansible was not to print ‘Hello World’ but to automate a certain task, in this case device creation. Next we will look at how we can provision a device in Versa Director workflows/Device context. This will require a POST operation to the following API resource:

https://<vd-director>:<vd-port>/vnms/sdwan/workflow/devices/device

A POST operation requires some data be sent to the system, which we can refer to as body or payload. Versa Director supports data in the format of JSON or XML. As one would notice, we specified ‘application/json’ in our HTTPS headers in the above get-version playbook.

Below is an example of JSON body to create ‘branch10’ device, which is kept on file ‘branch10.json’ :

$ cat branch10.json
{
  "versanms.sdwan-device-workflow": {
       "locationInfo": {
              "country": "usa"
       },
       "siteId": "125",
    "deviceName": "branch10",
    "orgName": "acme",
    "serialNumber": "SN-BR-10",
    "deviceGroup": "Branch-Group01",
    "bandwidth": 100,
    "deploymentType": "physical",
    "postStagingTemplateInfo": {
      "templateName": "branch-template",
      "templateData": {
        "device-template-variable": {
          "template": "branch-template",
          "variable-binding": {
            "attrs": [
              {
                "name": "{$v_MPLS_IPv4__staticaddress}",
                "value": "192.168.100.2/30"
              },
              {
                "name": "{$v_MPLS-Transport-VR_IPv4__vrHopAddress}",
                "value": "192.168.100.1"
              },
              {
                "name": "{$v_LAN_IPv4__staticaddress}",
                "value": "10.10.10.1/24"
              }
            ]
          }
        }
      }
    }
  }
}

There are a few assumptions here:

  • A device-template called ‘branch-template’ already exists on the Director with defined variables
  • A device-group called ‘Branch-Group01’ already exists on the Director

The Ansible playbook to create this device:

---
- name: Create Device on Versa Director
  hosts: localhost
  gather_facts: no
  tasks:
  - name: Create device on Versa Director Workflow
    uri:
      url: "https://10.48.58.101:9182/vnms/sdwan/workflow/devices/device"
      method: POST
      user: "Administrator"
      password: "xxxxxxxx"
      headers:
        Accept: application/json
        Content-Type: application/json
      return_content: yes
      force_basic_auth: yes
      validate_certs: no
      follow_redirects: all
      timeout: 60
      body_format: json
      body: "{{ lookup('file', 'branch10.json') }}"
    register: results
    changed_when: results.status == 200
    failed_when: "results.status != 200"

Result of playbook execution:

Running this playbook creates ‘branch10’ on Versa Director:

Note, however, that the state of the device is ‘Saved’ instead of ‘Deployed’. On Versa Director, another task is required to deploy the device by another POST transaction on API resource:

https://<vd-director>:<vd-port>/vnms/sdwan/workflow/devices/device/deploy/<device-name>

What Next?

The above is an example of very initial basic steps for using Ansible to start automating tasks on Versa Director. While there is no immediate added value seen from this, this is a building block to enable and develop further resources that can eventually automate complete workflows of creating devices, device-groups, device-templates, etc., towards an Infrastructure as Code concept.

From the JSON body in the example, there are opportunities to templatize the payload and build an inventory of devices and their corresponding variables. This will be explored in a future blog.