Network automation and APIs

Network management has changed dramatically in recent years. Many tasks that used to be done manually - device-by-device, command-by-command - are now handled through automation and programmable interfaces. This shift is one of the biggest changes in networking since TCP/IP. As a result, network automation and programmability have moved from “nice to have” topics to core skills for networking professionals. The CCNA certification reflects this trend by placing more emphasis on automation, APIs, and controller-based management.

Traditional network management depended on human intervention: administrators logged into devices, configured them manually, and troubleshot issues after they appeared. Monitoring often relied on protocols such as SNMP. These methods worked for many years, but they also introduced predictable problems: human error, inconsistent configurations, and difficulty scaling as networks grew.

The challenges of traditional network management

Traditional network management often means interacting with devices one at a time through the CLI, typically over SSH or Telnet. An administrator logs into each router or switch and enters commands to configure interfaces, routing protocols, VLANs, and security policies. This works for small environments, but it becomes increasingly difficult as the number of devices grows.

• Human Error: Manual configuration is inherently susceptible to typos, incorrect commands, or forgotten steps, leading to network outages or security vulnerabilities.
• Time-Consuming: Configuring hundreds or thousands of devices individually is a labor-intensive and slow process, delaying deployments and changes.

Imagine having to deploy new VLANs across 100 different switches. Using traditional methods, you’d connect to each device individually, navigate the CLI, and manually enter the required commands. This process is time-intensive and prone to mistakes. A single typo or missed step can cause outages or create security gaps.

• Lack of Consistency: Maintaining uniform configurations across numerous devices manually is challenging, often resulting in configuration drift and inconsistent network behavior.
• Scalability Issues: As networks grow in size and complexity, the manual approach becomes unsustainable, making it difficult to manage, troubleshoot, and scale operations effectively.
• Limited Visibility and Reactive Troubleshooting: While SNMP is mostly used for monitoring network devices and collecting data, it also has capabilities to configure network devices. However, its capabilities for real-time programmatic configuration are limited, often leading to reactive troubleshooting after an issue has already impacted services.

SNMP monitoring typically involves polling devices at regular intervals to collect performance metrics, interface statistics, and device status information. This polling-based approach can generate significant network overhead, particularly in large-scale environments with hundreds or thousands of managed devices. Additionally, SNMP’s read-mostly nature limits its effectiveness for dynamic network configuration changes.

The evolution to automated network management

Network automation uses software, scripts, and specialized tools to perform network tasks programmatically. Instead of repeating the same manual steps on every device, you define the task once and let automation apply it consistently. This changes how networks are designed, deployed, and operated.

Impact of automation on network management

• Increased Efficiency: Automation significantly reduces the time and effort required for routine tasks like device provisioning, configuration changes, and maintenance. This allows network administrators to focus on more strategic initiatives rather than repetitive work.
• Reduced Human Error: By executing predefined scripts and workflows, automation reduces the risk of typos and inconsistencies, leading to more reliable and predictable network operations.
• Improved Consistency: Automation helps ensure configurations are applied uniformly across devices, enforcing standardized policies and reducing configuration drift.
• Enhanced Scalability: Automated tools can manage many devices at once, making it possible to scale networks without needing a proportional increase in staff. This is especially important in large enterprise and service provider environments.
• Faster Deployment and Changes: New services and configurations can be deployed rapidly and consistently. Zero Touch Provisioning (ZTP), for instance, allows devices to configure themselves automatically when they’re first connected.
• Proactive Problem Solving: Automation supports more continuous monitoring and data collection, which can help detect and resolve issues sooner - sometimes before users notice an impact.

In essence, network automation shifts network operations from a reactive, labor-intensive process to a more proactive, software-driven approach.

Northbound and Southbound APIs

At the heart of network programmability are Application Programming Interfaces (APIs). An API is a defined way for software systems to communicate and exchange data. A helpful analogy is a restaurant menu: it tells you what you can request and how to request it, without exposing all the details of how the kitchen prepares the meal.

In Software-Defined Networking (SDN) and controller-based architectures, APIs are commonly described as Northbound or Southbound. These terms describe which layers of the architecture are communicating.

Northbound APIs

Northbound APIs connect higher-level applications (often running on a developer’s or network administrator’s computer, or in an orchestration platform) to the network controller. They provide an abstract view of the network, so applications can request services or apply policies without needing to manage device-by-device details.

• Purpose: To enable applications (e.g., orchestration systems, business applications, network management software) to interact with the network controller, requesting services, applying policies, and retrieving network-wide information. They abstract the underlying network complexity.
• Direction: From applications (higher layer) to the SDN controller (middle layer).
• Examples:
  • Cisco Catalyst Center APIs: Cisco Catalyst Center (formerly known as Cisco DNA Center), a central network controller, exposes a rich set of Northbound REST APIs. These APIs allow external applications to integrate with Cisco Catalyst Center to manage network devices, retrieve network health, provision services, and apply intent-based policies. For example, an application could use Catalyst Center’s Northbound API to provision a new wireless SSID across an entire campus network.
  • OpenDaylight APIs: OpenDaylight, an open-source SDN controller, also provides Northbound APIs that allow applications to program the network. These APIs enable developers to build custom applications that interact with the network infrastructure managed by OpenDaylight.

Southbound APIs

Southbound APIs connect the network controller to the network devices (such as switches, routers, and access points). They translate high-level intent or policy into device-specific configuration and operational commands.

• Purpose: To allow the SDN controller to programmatically configure, monitor, and collect data from individual network devices. They are responsible for implementing the policies and services defined by the Northbound APIs.
• Direction: From the SDN controller (middle layer) to network devices (lower layer).
• Examples:
  • OpenFlow: A well-known Southbound API that allows an SDN controller to directly program the forwarding tables of network switches. It provides granular control over how traffic is handled by network devices.
  • NETCONF (Network Configuration Protocol): A standardized protocol designed for installing, manipulating, and deleting network device configurations. It uses XML-based data encoding and provides a programmatic way to manage devices.
  • RESTCONF: A REST-like protocol that uses HTTP for transport and relies on YANG data models to define the structure of configuration and state data, similar to NETCONF but using RESTful principles.
  • CLI (via automation tools): While not an API in the traditional sense, automation tools can use SSH to send CLI commands to devices programmatically, effectively acting as a Southbound interface for legacy devices that don’t support NETCONF or RESTCONF.

Together, Northbound and Southbound APIs support centralized control and automation while still allowing the controller to interact with many different device types.