Northbound & Southbound APIs – SDN Architecture, Protocols, and Automation

1. APIs in Networking – Why They Matter

An API (Application Programming Interface) is a defined set of rules and protocols that allows different software systems to communicate with each other. In networking, APIs replace the traditional model of an engineer manually typing CLI commands on each device with programmatic, automated, and repeatable interactions.

APIs are the foundation of Software-Defined Networking (SDN) and controller-based architectures. They enable external applications, orchestration platforms, and automation tools to control, configure, monitor, and extract analytics from network infrastructure — at scale and at speed that manual CLI work cannot match. 

  Traditional (CLI-only) model:
  Engineer → SSH/Telnet → Device A
             → SSH/Telnet → Device B   (slow, error-prone, not scalable)
             → SSH/Telnet → Device C

  Controller-based (API) model:
  ┌────────────────────────────┐
  │  Applications & Automation │  (Ansible, Python, Dashboards, OSS/BSS)
  └─────────────┬──────────────┘
                │  Northbound APIs  (REST, RESTCONF, GraphQL)
  ┌─────────────▼──────────────┐
  │      SDN Controller        │  (Cisco DNA Center, OpenDaylight, APIC)
  └─────────────┬──────────────┘
                │  Southbound APIs  (NETCONF, OpenFlow, gNMI, SNMP)
  ┌─────────────▼──────────────┐
  │  Network Devices            │  (Switches, Routers, APs, Firewalls)
  └────────────────────────────┘

Related pages: Controller-Based Networking | Network Automation Overview | NETCONF & RESTCONF Overview | JSON, XML & YANG | SD-WAN Overview | Ansible Overview | Python for Networking | RESTCONF Basics Lab | NETCONF with Python Lab

2. Northbound APIs

Northbound APIs are the interfaces that a network controller exposes upward to the applications, management systems, and orchestration platforms that sit above it. They allow those systems to ask the controller for network information, push policies, or trigger automated workflows — without needing to know which specific devices are underneath or how to configure them directly.

Property Detail
Direction Controller ↔ Applications / Orchestration / Management platforms
Exposed by The SDN controller (e.g., Cisco DNA Center, OpenDaylight, APIC)
Consumed by Custom apps, analytics dashboards, OSS/BSS systems, CI/CD pipelines, Ansible playbooks, Python scripts
Primary protocols REST (HTTP/HTTPS), RESTCONF, SOAP (legacy), GraphQL
Data formats JSON (most common), XML
Typical operations GET (query state), POST (create resource), PUT/PATCH (update), DELETE (remove)

Example: A cloud management platform sends an HTTP POST to Cisco DNA Center’s northbound REST API requesting the creation of a new VLAN for the “HR” department. The platform receives a JSON response confirming the request was accepted, without ever touching a single switch CLI.

3. Southbound APIs

Southbound APIs are the interfaces the controller uses to communicate downward to the physical and virtual network devices it manages. Through southbound APIs, the controller pushes configurations, installs forwarding rules, retrieves operational state, and collects real-time telemetry — all programmatically and at scale.

Property Detail
Direction Controller ↔ Network devices (switches, routers, APs, firewalls)
Used by The SDN controller to program and monitor managed devices
Targets Physical switches, routers, wireless APs, firewalls, virtual appliances
Primary protocols NETCONF, OpenFlow, gNMI, SNMP, RESTCONF, CAPWAP, CLI (SSH)
Data formats XML/YANG (NETCONF), binary/protobuf (gNMI), protocol-specific (OpenFlow)
Typical operations Push config, install flow rules, poll counters, stream telemetry, retrieve running state

Example: After receiving the VLAN creation request via its northbound REST API, Cisco DNA Center uses its southbound NETCONF interface to push the VLAN configuration to every relevant switch simultaneously.

4. Northbound vs. Southbound – Side-by-Side Comparison

Aspect Northbound API Southbound API
Direction Controller ↔ Applications & orchestration Controller ↔ Network devices
Abstraction level High — hides device-level complexity from apps Low — directly addresses device capabilities
Who uses it Developers, DevOps teams, OSS/BSS, analytics platforms The controller itself (internal to the SDN system)
Common protocols REST, RESTCONF, SOAP, GraphQL NETCONF, OpenFlow, gNMI, SNMP, CAPWAP, CLI/SSH
Data format JSON, XML XML/YANG, binary (gRPC/protobuf), protocol-specific
Primary focus Automation, analytics, policy orchestration Configuration delivery, monitoring, telemetry collection
Authentication typical API tokens, OAuth 2.0, API keys over HTTPS SSH keys, TLS certificates, SNMP community strings
Example action App creates VLAN 100 via DNA Center REST API Controller pushes VLAN 100 config to switches via NETCONF

5. Northbound API Protocols in Depth

Protocol Transport Data Format Description Status
REST HTTP / HTTPS JSON or XML Stateless, resource-oriented architecture using standard HTTP verbs (GET, POST, PUT, PATCH, DELETE). The dominant northbound API style. Language-agnostic and easy to consume from any programming language. Current standard
RESTCONF (RFC 8040) HTTPS JSON or XML REST-style HTTP API specifically for managing network configuration and state using YANG data models. Bridges the human-readable REST world with the structured YANG models used by NETCONF. Current standard
GraphQL HTTP / HTTPS JSON Query language allowing clients to request exactly the data fields they need in a single call, avoiding the over-fetching and under-fetching common with REST. Increasingly used in modern network management platforms. Emerging
SOAP HTTP / HTTPS XML Legacy XML-based web services protocol. Verbose but provides strict type definitions via WSDL. Still found in older OSS/BSS integrations. Legacy

6. Southbound API Protocols in Depth

Protocol Transport Data Model Description Best For
NETCONF (RFC 6241) SSH (port 830) XML / YANG Network Configuration Protocol. Provides structured, transactional configuration and state retrieval using XML-encoded YANG data models. Supports candidate configurations, rollback, and commit/confirm operations — far more reliable than CLI scripting. Device configuration & state management on modern IOS-XE, IOS-XR, NX-OS
RESTCONF (RFC 8040) HTTPS JSON or XML / YANG HTTP-based alternative to NETCONF using the same YANG models but a REST interface. Easier to use from scripts and browsers but lacks some of NETCONF’s transactional features. Lightweight device management from REST-friendly tools
OpenFlow TCP / TLS Protocol-specific (binary) The original SDN southbound protocol. Allows an external controller to directly install, modify, and delete flow entries in a switch’s flow table, separating the control plane from the data plane. Pure SDN environments; research networks; data-centre fabrics
gNMI (gRPC Network Management Interface) gRPC (HTTP/2 + TLS) Protobuf / YANG Modern, high-performance telemetry and configuration protocol developed by Google and adopted by major vendors. Uses gRPC (binary protobuf) over HTTP/2, enabling efficient streaming telemetry at sub-second intervals. Real-time streaming telemetry; model-driven automation
SNMP v2c / v3 UDP (161/162) MIB / OID Legacy polling and trap-based monitoring protocol. SNMPv3 adds authentication and encryption. Limited configuration capability; primarily used for monitoring and alerting. Still widely deployed. Monitoring, alerting, and basic config on legacy devices
CAPWAP UDP (5246/5247) Protocol-specific Control and Provisioning of Wireless Access Points. Used by WLCs and controllers (e.g., Cisco Catalyst Center) to centrally manage lightweight APs, delivering configuration and tunnelling client traffic. Wireless AP management from a WLC or cloud controller
CLI / SSH SSH (port 22) Unstructured text Traditional CLI access. Controllers can drive SSH sessions using scripted expect-style interactions or tools like Netmiko. Fragile for automation (screen-scraping) but necessary for devices without model-driven APIs. Legacy devices with no NETCONF/gNMI support

7. YANG Data Models

YANG (Yet Another Next Generation, RFC 6020/7950) is the data modelling language that underpins both NETCONF and RESTCONF. It defines the structure, syntax, and semantics of the configuration and operational data a device exposes — making API interactions with that device predictable and machine-readable.

Concept Description
YANG model A schema defining what data a device has (e.g., interface names, IP addresses, VLANs) and what operations are allowed on it
OpenConfig models Vendor-neutral YANG models developed by network operators (Google, Microsoft, etc.) to create a common, multi-vendor API surface
Native / vendor models Vendor-specific YANG models (e.g., Cisco IOS-XE native models) that expose platform-specific features not covered by OpenConfig
NETCONF + YANG NETCONF carries the XML-encoded YANG data; YANG defines what that data means. Together they replace fragile CLI scripting with structured, validated configuration transactions
RESTCONF + YANG RESTCONF maps YANG data to HTTP URLs; e.g., GET /restconf/data/ietf-interfaces:interfaces retrieves all interface data in JSON or XML using the YANG-defined schema

8. Common Use Cases

Use Case API Direction Protocols Involved Example
Network orchestration Northbound REST / RESTCONF Ansible playbook calls DNA Center REST API to provision a new branch VLAN across 50 switches simultaneously
Analytics & monitoring Northbound REST A Grafana dashboard polls DNA Center’s REST API every 60 seconds to display device health KPIs
OSS/BSS integration Northbound REST / SOAP Telco billing system triggers network service activation via northbound API when a customer upgrades their plan
Device configuration push Southbound NETCONF / RESTCONF Controller commits a new ACL across all edge routers using a NETCONF <edit-config> operation with rollback on failure
Real-time telemetry Southbound gNMI / gRPC Controller subscribes to gNMI streaming on all core routers, receiving interface counters every 10 seconds for anomaly detection
Flow programming (SDN) Southbound OpenFlow OpenDaylight controller installs flow entries that route traffic for a specific tenant VxLAN segment through a chosen path
Wireless AP management Southbound CAPWAP Cisco Catalyst Center pushes a new SSID configuration to 200 APs via CAPWAP tunnel without touching each AP individually
Topology discovery Southbound BGP-LS / SNMP Controller queries routers via BGP-LS to build a real-time topology map for path computation

9. Controller Platforms and Their APIs

Platform Northbound APIs Southbound APIs Notes
Cisco DNA Center (Catalyst Center) REST (HTTPS/JSON) NETCONF, SNMP, CLI/SSH, CAPWAP Cisco’s intent-based networking platform; 300+ REST API endpoints; integrates with Ansible, Python, Postman
Cisco APIC (ACI) REST, Python SDK OpFlex (proprietary southbound to ACI fabric) Data-centre fabric controller for Cisco ACI; policy-based automation of leaf/spine switching
OpenDaylight (ODL) REST, RESTCONF, NETCONF (northbound) OpenFlow, NETCONF, SNMP, BGP-LS Open-source SDN controller; widely used in research and service provider networks
VMware NSX REST APIs VMware-specific southbound to ESXi hypervisors and physical switches Network virtualisation for data centres; micro-segmentation and distributed firewall
Aruba Central / AirWave REST APIs CAPWAP, PAPI (proprietary) HPE/Aruba wireless and wired network management; cloud-hosted controller

See also: Controller-Based Networking | Step-by-Step: Cisco RESTCONF | Step-by-Step: NETCONF with Python

10. API Security

An unsecured API is an open door into the control plane of your entire network. Comprehensive API security requires controls at every layer:

Control Description Implementation
Encryption in transit All API traffic must be encrypted to prevent eavesdropping and tampering TLS 1.2+ for HTTPS (northbound REST); TLS over gRPC (gNMI); SSH for NETCONF
Authentication Verify the identity of every API consumer before granting access API keys, OAuth 2.0 tokens, client certificates, username/password with token exchange
Authorisation (RBAC) Grant each consumer only the permissions they need — least privilege Role-Based Access Control; separate read-only vs read-write vs admin roles
Rate limiting Prevent API abuse, denial-of-service, and runaway automation scripts Per-token or per-IP request throttling; return HTTP 429 on limit breach
Input validation Reject malformed or unexpected input before it reaches the controller Schema validation against YANG models (NETCONF/RESTCONF); JSON schema validation (REST)
Audit logging Record every API call — who called what, when, from where, and with what result Centralised syslog or SIEM; immutable audit trail for compliance (SOC 2, PCI-DSS)
Network segmentation Restrict which hosts can reach API endpoints at all Firewall rules; management VRF; ACLs allowing only authorised management hosts

11. Challenges in API Integration

Challenge Description Mitigation
Vendor interoperability Different vendors implement proprietary YANG models, API endpoints, or data structures that vary from open standards Use OpenConfig YANG models where supported; use abstraction layers (e.g., NAPALM, Nornir) that normalise vendor differences
API versioning & backward compatibility Controller or device software upgrades may change or deprecate API endpoints, breaking existing integrations Pin integration code to a specific API version; test against a staging environment before upgrading production; follow vendor release notes
Scalability A controller handling thousands of API calls per second can become a bottleneck, especially during large-scale provisioning events Horizontal scaling of the controller; asynchronous / event-driven API patterns; batch operations rather than per-device calls
Legacy device support Older devices may only support CLI or SNMPv2; no NETCONF or gNMI available Use CLI-based automation (Netmiko, Paramiko) as a fallback; plan device refresh cycles to migrate to model-driven platforms
Error handling & idempotency Network API calls can fail mid-way, leaving devices in a partial configuration state Use NETCONF candidate configuration + commit/rollback for transactional safety; design automation scripts to be idempotent (safe to re-run)

12. End-to-End Practical Example

Scenario: Provision a new VLAN for the “HR” department across all campus access switches using Cisco DNA Center. 

  Step 1 — Application layer (Northbound)
  ┌────────────────────────────────────────────────────────────────────┐
  │ Ansible Playbook sends HTTP POST to DNA Center northbound REST API  │
  │                                                                    │
  │ POST https://dnac.company.com/dna/intent/api/v1/business/vlan      │
  │ Authorization: Bearer <token>                                      │
  │ Content-Type: application/json                                     │
  │ { "vlanId": 100, "vlanName": "HR", "siteId": "campus-floor-2" }   │
  └────────────────────────────────────────────────────────────────────┘
                              │
                              ▼ DNA Center accepts and queues task
  Step 2 — Controller (Decision & Translation)
  ┌────────────────────────────────────────────────────────────────────┐
  │ DNA Center determines which devices are in "campus-floor-2"        │
  │ Generates NETCONF <edit-config> payload for each switch           │
  └────────────────────────────────────────────────────────────────────┘
                              │
                              ▼ Southbound delivery
  Step 3 — Device layer (Southbound)
  ┌────────────────────────────────────────────────────────────────────┐
  │ NETCONF <edit-config> sent over SSH to SW1, SW2, SW3 ...          │
  │ Each switch validates, commits, and confirms the VLAN config       │
  │ DNA Center collects confirmation; marks task as SUCCESS            │
  └────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
  Step 4 — Verification (Northbound query back)
  ┌────────────────────────────────────────────────────────────────────┐
  │ Ansible queries DNA Center REST API to verify VLAN 100 is active   │
  │ GET https://dnac.company.com/dna/intent/api/v1/topology/vlan       │
  │ Response: {"vlan": "100", "status": "active", "devices": [...]}    │
  └────────────────────────────────────────────────────────────────────┘

  Result: VLAN 100 appears on all switches — zero manual CLI input.

13. Future Trends

Trend Description API Role
Intent-Based Networking (IBN) Applications express a desired business outcome (“ensure latency < 5 ms for VoIP”) via northbound APIs. The controller continuously translates, validates, and enforces this intent using southbound APIs — and self-corrects if the network drifts. Northbound APIs carry the high-level intent; southbound APIs implement and verify it
AI/ML-Driven Automation AI engines consume real-time telemetry via northbound APIs, detect anomalies, and autonomously push remediation actions through the controller’s southbound APIs — self-healing networks. gNMI streaming southbound feeds the AI data plane; REST northbound delivers AI-generated configs
Model-Driven Everything YANG models cover not just configuration but service models, network topology, and compliance policies. Every interaction — from day-0 provisioning to day-2 operations — is driven by versioned, validated data models. NETCONF/RESTCONF/gNMI southbound with YANG; OpenConfig for vendor-neutral coverage
Network-as-Code Network configurations are stored in Git repositories and deployed via CI/CD pipelines (GitOps), treating the network like software — with peer review, automated testing, and rollback capability. Pipelines call northbound REST APIs; automated tests verify southbound state

See also: Ansible for Network Automation | Python for Networking | Step-by-Step: NETCONF with ncclient

14. Key Points & CCNA Exam Tips

  • Northbound API = Controller ↔ Applications / orchestration (above the controller); primary protocols: REST, RESTCONF
  • Southbound API = Controller ↔ Network devices (below the controller); primary protocols: NETCONF, OpenFlow, gNMI, SNMP, CAPWAP
  • The controller sits in the middle — it exposes northbound APIs upward and uses southbound APIs downward
  • REST northbound APIs use JSON or XML over HTTPS with standard HTTP verbs (GET, POST, PUT, DELETE)
  • NETCONF southbound uses SSH (port 830) and XML/YANG — the modern replacement for CLI scripting
  • YANG is the data modelling language used by both NETCONF and RESTCONF to define device data structures
  • OpenFlow = southbound only; directly installs flow entries in the data plane — the classic SDN protocol
  • gNMI = southbound only; modern streaming telemetry using gRPC/protobuf; sub-second intervals possible
  • SNMP = primarily monitoring (southbound); SNMPv3 adds encryption and authentication
  • CAPWAP = southbound; used for wireless AP management from a WLC or cloud controller
  • Cisco DNA Center exposes northbound REST APIs and uses southbound NETCONF/SNMP/CLI
  • API security requires: TLS encryption, strong authentication (tokens/certificates), RBAC, rate limiting, and audit logging
  • Intent-Based Networking uses northbound APIs to receive high-level intent and southbound APIs to continuously enforce it
  • Metrics are not comparable across protocols; similarly, metrics only have meaning within a single routing protocol context

Northbound and Southbound APIs Quiz

1. What is the main role of an API in networking?

Correct answer is B. APIs define rules that allow software systems to communicate with each other. In networking they replace manual CLI work with programmatic, repeatable, and scalable automation — forming the foundation of SDN and controller-based architectures.

2. What are northbound APIs primarily used for?

Correct answer is A. Northbound APIs are exposed by the controller upward to applications, orchestration platforms (Ansible, Python), analytics dashboards, and OSS/BSS systems. They allow those systems to request network changes or query state without touching any device directly.

3. Which of the following is a common northbound API protocol?

Correct answer is D. RESTful APIs are the dominant northbound protocol — stateless, HTTP-based, and language-agnostic. OpenFlow, SNMP, and CAPWAP are all southbound protocols used between the controller and network devices.

4. What are southbound APIs used for in networking?

Correct answer is C. Southbound APIs allow the controller to push configurations, install flow rules, retrieve operational state, and collect telemetry from the switches, routers, APs, and firewalls below it.

5. Which protocol is an example of a southbound API?

Correct answer is B. OpenFlow is a southbound SDN protocol that allows an external controller to directly install, modify, and delete flow entries in switch flow tables, separating control-plane logic from the data plane. RESTCONF, SOAP, and GraphQL are northbound-oriented protocols.

6. What data formats are commonly used in northbound REST APIs?

Correct answer is A. Northbound REST APIs use human-readable JSON (most common) or XML for request and response bodies. JSON is preferred for its simplicity; XML is used when YANG model compliance is required (RESTCONF).

7. What is a key security best practice for APIs in networking?

Correct answer is D. APIs are an entry point into the network control plane. All API traffic must use TLS (HTTPS, gRPC-TLS, NETCONF over SSH); every caller must be authenticated (tokens, certificates); and access must be limited to the minimum required permissions via RBAC. All calls should be logged.

8. Which of the following is a challenge when integrating APIs in networking?

Correct answer is C. When a controller or device receives a software upgrade, API endpoints may change, parameters may be renamed, or deprecated endpoints may be removed — breaking automation scripts that were built against an older version. Always pin to a specific API version and test upgrades in staging first.

9. Which platform exposes northbound REST APIs and integrates southbound via NETCONF, SNMP, and CLI?

Correct answer is B. Cisco DNA Center (now Catalyst Center) is Cisco’s intent-based networking platform. It exposes over 300 northbound REST API endpoints for orchestration tools and uses NETCONF, SNMP, and CLI/SSH as southbound interfaces to manage Cisco switches, routers, and APs.

10. What networking paradigm involves applications expressing desired outcomes through northbound APIs, with the controller continuously translating and enforcing those intents via southbound APIs?

Correct answer is A. Intent-Based Networking (IBN) takes the northbound/southbound API model to its logical conclusion: applications declare what they need (the intent) rather than how to configure it. The controller translates the intent into device configurations via southbound APIs and continuously verifies the network is delivering it.

← Back to Home