What is Network Orchestration?

Network Orchestration Definition

Network orchestration refers to automating interactions across multiple types of devices, domains, and even potentially other related systems in the network. Orchestration typically requires the ability to interact with many device types and vendors, and across multiple domains and management systems requiring programmatic interfaces, including Restful APIs.

What is Network Orchestration?

Network orchestration is the next stage of network automation – it can be described as policy-based or event-driven automation. While automation involves ‘making a single task run by itself without human intervention,’ orchestration goes many steps further by automating entire ‘processes,’ i.e., ‘a sequence of interrelated tasks.’ The mechanism of orchestration is defined by a set of rules or policies laid down by the organization.

Key Differences Between Network Automation and Network Orchestration

Network Automation Network Orchestration
Used to run single, low-level tasks without human intervention. Used to run multiple, sequential high-level tasks or processes, without human intervention.
Usually done through the devices’ CLI or through third-party script-driven frameworks. Done through programmatic REST APIs that enable automation across devices and management platforms.
Restricted to a particular device type or vendor. Spans multiple network services, vendors, and environments.
Linear, does not take into account the state, status, or configuration of devices. Network-aware, executes workflows based on state, status, and configuration of devices.
Does not provide governance/policy management. Has policy management and governance as a part of its principle.
Example: Pushing configuration changes into a device. Example: Provisioning network services.

Network Orchestration Tools

The tools used to orchestrate networks should encompass the tenets of orchestration – that is, they should be intelligent, work across vendors and environments, and enforce policy compliance, among other characteristics.

Key Requirements of Network Orchestration Tools

Device inventory: The tool must possess the ability to pull the device inventory information either directly (SSH/Telnet) and/ or through API. Inventory typically consists of vendor, model, operating system, serial number, and more information.

Context, config, and state aware: The tool should check these network parameters before it performs any orchestration activity on it. These checks ensure that the changes made to the network produce the desired outcome without causing any discrepancies. The ability to perform these checks and execute orchestration workflows based on the results is a measure of the tool’s intelligence.

Device-, vendor- and environment-agnostic: Since orchestration spans multiple services (ITSM, DDI, etc.), vendors, and environments, it’s instrumental that the tools be device and vendor-agnostic, and be able to operate across multiple environments – on-premise, hybrid, and multi-cloud.

GUI-based single pane of control: The orchestration tool should have a centralized management plane from where administrators can monitor and control operations across the aforementioned systems. For this, the tool should be capable of interacting with different tools and management platforms, for the purpose of executing commands and collecting information, through REST APIs.

Policy enforcement and governance: In automation, multiple tools can push changes into a device without proper governance, sometimes causing the device to break down. The orchestration tool should streamline and govern the execution of these automation tasks to ensure they conform to certain policies that can be enforced by the team or the organization. This way, the tool acts as the ‘master orchestrator’ for the different automation tools.

RBAC-enabled collaboration: The orchestration tool should enable application and security operations teams to self-service some of the tasks that are generally under the scope of the network team – like application traffic management and configuring firewall policies. Self-servicing of tasks, coupled with access control and governance, drastically reduces time and tickets and helps improve network agility.

Logging, backup, and restore: The tool must provide timestamped logs of every action on the network to determine what happened for purposes of audit or troubleshooting. It should also allow for on-demand/scheduled configuration backups along with rollback capabilities in case of orchestration failure.

Types of Network Orchestration

Policy-Based Automation (PBA) – is the most basic type of orchestration. It provides an abstraction away from individual device configuration and enables centralized control to device a “policy,” which is made up of specific configuration parameters for a device type or role. Many of the technologies that use “software-defined” labeling provide policy-based automation to support implementations such as SD-WAN and SD-Access, SD-DC, and more. This approach is an improvement over the more rudimentary automation approach like network change and configuration management, but often the policies are defined in a template format, and template management can introduce new challenges. When performing updates, the PBA systems generally push the full-updated templates to the networking devices, which could be disruptive.

Software-Defined Networking (SDN) – is a higher level of network orchestration. It was originally intended to separate the control-plane and data-plane to enable higher operational efficiency in networking layer devices through programmable forwarding tables (like via the OpenFlow protocol). While this approach did not have wide adoption, other SDN technologies have had a lot of success, including SD-WAN and SDN technologies in the data center. SDN introduces a Controller layer that provides management functions such as provisioning, monitoring, and configuration management. They also provide a REST-based programmable interface for automation and interworking with other management systems.

Intent-Based Networking Systems (IBNS) – these systems are considered the most advanced from a technology standpoint since the objective can be abstracted up to a business level intent and then the system can derive the required configuration, implement on the network, and verify the network remains in that intended state. While this is one of the most advanced approaches, it can involve more time to ensure the design and required features are built properly, and the ready-to-consume intended state to be translated into actual network configurations.

Network Orchestration Use Cases – Examples

1. Automated Network Troubleshooting

Network troubleshooting is sometimes complicated and requires data gathering and analysis from many different tools. Known troubleshooting scenarios could be quickly identified and rectified with orchestration. Below is an example of BGP Flap remediation-

  1. Receive critical alert due to excessive BGP flaps on a particular device
  2. Raise an incident ticket on ServiceNow
  3. Run predefined compliance checks on the device. Compliance checks can yield configuration and OS issues.
  4. Compare with configuration compliance policy for the device and automatically apply fixes to eliminate configuration diffs.
  5. Schedule OS upgrade issues for the maintenance window
  6. Rerun compliance checks to validate device
  7. Close incident ticket on ServiceNow

2. Automated Software Upgrades

OS upgrade is an activity that can quickly gather complications, confusion, and delays as it rolls forward. An upgrade is a complex process involving prechecks, post checks, and approvals, which are mostly manual in today’s processes. Orchestration can simplify the method-of-procedures and remove human errors-

  1. Raise upgrade ticket on ServiceNow that triggers OS upgrade automation workflow
  2. Run Pre-Checks
    • Check if enough disk space is available
    • Check if traffic is running on the interfaces
    • Check file system
  3. If pre-checks succeed go to step 4, else change incident status on ServiceNow
  4. Take configuration backup
  5. Upload new image
  6. Ask for approval before applying new image and rebooting the device
  7. Restart device on approval
  8. Wait for SNMP trap to know when the device is back online
  9. Run post-checks
    • Verify new image is applied
    • Check interface status
  10. If post checks succeed go to step 11, else rollback to an earlier image
  11. Change status of the incident in ServiceNow

More on Network Orchestration: