Simplifying OcNOS Configuration Backups With Ansible

Aug 14, 2025

Configuration Backups

Configuration backups are an important topic for any network operations team, whether it be a service provider or an enterprise IT system. There are various ways to do this, ranging from off-the-shelf products to built-in tools (in the case of VMs), depending on what systems you use.

It’s not surprising that this comes up as a question in new engagements: “How can we execute scheduled backups?” While many operators already have their own tools, there is still interest in seeing what options are available.

Backups in OcNOS

OcNOS does not currently have the functionality for “automatic” scheduled backups, so scripting or another tool such as IP Maestro or Ansible is required.

There are three ways to see a running configuration in OcNOS:

  1.  show running-config
  2.  show xml running-config
  3.  show json running-config

Each command provides the same information but in a different format. This is where Ansible, a popular lightweight, agentless automation tool, comes in. We can write a simple playbook to capture the backups and store them in a preferred location.

Backup in Action

First, we will create a simple playbook with the goal of logging into every device, taking the output, and copying it to a remote location.

Here are the playbook’s components and how they work:

  1. A playbook that utilizes a module called ocnos_config_backup.
  2. An Ansible inventory file that captures the details of the routers (OcNOS devices).

Ansible Configuration Backup Module

The configuration backup module is part of the ipinfusion.ocnos Galaxy collection. The module is namedocnos_config_backup and is an action plugin. It requires the netmiko package to be installed on the Ansible control system where the playbook is being executed. The module requires six mandatory arguments, which can be provided in any order:

  1. remote_host: The IP address of the remote machine where the backup is stored.
  2. remote_username: The username for the remote machine.
  3. remote_password: The password for the remote machine.
  4. remote_path: The path on the remote machine where the backup configurations are stored.
  5. node_type: This argument accepts one of two values, ‘physical’ or ‘vm’. (Generally, it is physical for all production environments).
  6. transport: This argument is required to select the transport protocol (scp or ftp).

Backup Module Working Details

The backup module dumps the configuration files in three formats: json, xml, and cfg. The filename is stored in the format <hostname>_<timestamp>.<format>, where the hostname is the name defined in the inventory file, the timestamp is from the Ansible controller in the UTC time zone (not the OcNOS device), and the format is one of the three (json, xml, or cfg). The module has primitive error handling to detect missing mandatory arguments, connection errors to OcNOS devices, and file copy status from OcNOS devices to the remote machine.

Sample Playbook:

Inventory File Sample:

Running the Playbook:

ansible–playbook config_backup.yaml -i inventory.yaml

Backup Files Collected in the Specified Folder:

Installation of IPInfusion OcNOS Galaxy Collection

  1. Download the ipinfusion-ocnos-1.2.5.tar.gz file.
  2. Install the collection using ansible-galaxy collection install ipinfusion-ocnos-1.2.5.tar.gz.
  3. Verify the collection using ansible-galaxy collection list.

Conclusion

Although configuration backups have been around for a while and solved in numerous ways, here is a lightweight method to get OcNOS config backups. You can file these into Git repositories or other file management systems so you can always see the differences from various points in time. IP Infusion also has an element management system, IP Maestro, that can collect backups on a scheduled interval if Ansible isn’t part of your operations.

Vince Schuele is the Chief Quality Officer for IP Infusion.