# Southbound API

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/southbound-api

## Quick definition

A southbound API is how a software-defined networking (SDN) controller sends instructions to the network hardware. It translates high-level policies from the controller into commands that devices like switches and routers understand. Without it, the controller would not be able to configure or monitor the network equipment. Think of it as the bridge between the brain of the network and the muscles that do the work.

## Simple meaning

Imagine you are the manager of a large delivery company. You sit in a central office and decide the best routes for all the trucks to take. But you cannot talk directly to each truck driver, you need an assistant who knows the drivers' language. That assistant takes your route plan and tells each driver exactly what to do. In this analogy, you are the SDN controller, the assistant is the southbound API, and the truck drivers are the network devices like switches and routers.

The southbound API is the crucial middle layer that makes software-defined networking possible. The controller has a big picture view of the entire network and wants to enforce policies like "priority traffic for video calls" or "block traffic from that suspicious IP." However, the network devices themselves are built by different vendors and speak different languages, some use OpenFlow, others use NETCONF, and older ones might only understand SNMP or CLI commands. The southbound API is the standardized way for the controller to talk to all these devices, regardless of their specific make or model.

A common protocol used for southbound APIs is OpenFlow, which allows the controller to directly program the flow table of a switch. Another is NETCONF, which uses YANG data models to configure devices in a structured way. There is also OVSDB for managing virtual switches. Each protocol serves a similar purpose but works differently under the hood. The southbound API is not just one technology, it is a category that includes all the methods a controller uses to manage the data plane.

In a real network, the southbound API handles tasks like pushing ACL rules, setting up VLANs, monitoring link status, and collecting traffic statistics. It is a two-way street: the controller sends commands down to the devices, and the devices send back information about their state, errors, and traffic counters. This bidirectional communication is what makes the controller truly aware of the network's health and able to react to changes in real time.

Without southbound APIs, network automation would be nearly impossible. Engineers would have to log into each device individually and type commands. Instead, the controller can change the entire network configuration with a single policy change, and the southbound API does the hard work of updating every relevant device. It is the silent workhorse behind modern, programmable networks.

## Technical definition

In software-defined networking (SDN), the architecture is divided into three planes: the application plane, the control plane, and the data plane. The southbound API is the interface that sits between the control plane (the SDN controller) and the data plane (the network devices). Its primary role is to enable the controller to program the forwarding behavior of switches, routers, and other network elements, as well as to collect telemetry and state information from those devices.

The southbound API operates using a variety of protocols, each designed for specific use cases and device capabilities. OpenFlow, defined by the Open Networking Foundation (ONF), is one of the most widely known southbound protocols. It allows the controller to add, modify, or remove flow entries in the switch's flow table. Each flow entry contains match fields (e.g., source IP, destination MAC, VLAN ID), instructions (e.g., forward to a port, drop, send to controller), and counters. OpenFlow version 1.3 is commonly deployed in production environments.

NETCONF (Network Configuration Protocol) is another important southbound protocol, standardized by the IETF in RFC 6241. It uses XML-based messages over SSH or TLS to install, manipulate, and delete configurations on network devices. NETCONF is often paired with YANG data models, which define the structure and semantics of the configuration and state data. This combination provides a robust, standards-based way to manage device configurations programmatically.

OVSDB (Open vSwitch Database) is a southbound protocol specifically designed for managing Open vSwitch instances, which are commonly used in virtualized environments like VMware and KVM. OVSDB uses a JSON-based protocol to manage the database that defines the virtual switch's configuration, including ports, bridges, and tunnels.

Other southbound protocols include P4Runtime, which allows the controller to dynamically program the packet processing pipeline of programmable switches; gNMI (gRPC Network Management Interface) for streaming telemetry and configuration; and gNOI for operational tasks like rebooting devices or performing software upgrades. In addition to these, many SDN controllers also support traditional management interfaces like CLI and SNMP as southbound interfaces to interoperate with legacy hardware.

From a deployment perspective, the southbound API must be secure and reliable. Traffic between the controller and devices often runs over encrypted channels (e.g., TLS for OpenFlow, SSH for NETCONF). Authentication and authorization mechanisms ensure that only legitimate controllers can manage the devices. Performance is also critical: the southbound API must handle high volumes of control messages without introducing latency that could affect data plane forwarding.

In practice, an SDN controller uses the southbound API to perform operations such as: installing static or dynamic flows for traffic engineering, configuring QoS policies, enabling or disabling ports, setting up tunnels (VXLAN, GRE), and collecting counters for traffic analysis. The southbound API is also used for event notifications, when a link goes down or a new device connects, the device sends a message northbound through the API to the controller.

Finally, southbound APIs are not limited to physical hardware. They are equally critical for managing virtual switches (like Open vSwitch and VMware vDS) and container networking (e.g., using OVN or Calico). As networks become more virtualized and cloud-native, the southbound API continues to evolve to support new data planes and automation frameworks.

## Real-life example

Think about a large airport control tower. The air traffic controllers sit high up, watching radar screens and communicating with pilots to ensure planes take off and land safely. They make high-level decisions like "Flight 123, taxi to runway 4L" or "Hold position for five minutes." But the controllers cannot physically walk out to the runway and move the planes, they rely on radio instructions that the pilots follow. In this analogy, the air traffic controller is the SDN controller, the radio communication system is the southbound API, and the individual airplanes are the network devices (switches, routers).

Just as the radio must use a standardized frequency and protocol that both the tower and the pilot understand, the southbound API uses standardized protocols like OpenFlow or NETCONF so that the controller can talk to any device, regardless of the manufacturer. If the controller wants every switch to block traffic from a malicious IP (like telling all planes to avoid a storm cell), it sends one command over the southbound API, and the devices comply. The pilots (devices) also report back to the tower (controller) about their status, altitude, fuel level, any issues, just as switches send link status and traffic counters via the southbound API.

Without the radio (southbound API), the air traffic controller would have to write letters to each pilot and hand them to the planes before takeoff, clearly impractical. Similarly, without a southbound API, network engineers would need to manually configure each device, which is slow and error-prone. The radio channel must be secure to prevent interference or hijacking, which parallels the encrypted connections (TLS, SSH) used in southbound communications.

This analogy also highlights the importance of speed and reliability. If the radio breaks, the controller cannot manage the planes effectively. In networking, if the southbound API fails or becomes congested, the controller loses visibility and control over the data plane, potentially causing outages or misconfigurations. That is why redundancy and monitoring of southbound channels are critical in production SDN deployments.

## Why it matters

For IT professionals, understanding southbound APIs is essential because they are the foundation of network automation and software-defined networking. They transform networking from a manual, device-by-device chore into a programmable, centralized system. This shift directly impacts daily operations: administrators can roll out configuration changes across hundreds of devices in seconds instead of hours, enforce security policies consistently, and react to network anomalies faster.

Southbound APIs also enable network disaggregation, where the control plane (the decision-making intelligence) is separated from the data plane (the forwarding hardware). This separation allows organizations to use commodity hardware that is cheaper and easier to replace, while the intelligent controller can be upgraded independently. For businesses, this means lower capital expenditure and greater flexibility in choosing vendors.

southbound APIs are the key to implementing intent-based networking (IBN). In IBN, the administrator declares a high-level intent (like "prioritize traffic for the video conferencing application"), and the controller automatically translates that into device-level configurations via the southbound API. This reduces human error and ensures the network aligns with business needs.

From a career perspective, knowing how southbound APIs work is increasingly required for roles like network engineer, cloud engineer, and DevOps professional. Technologies like Cisco ACI, VMware NSX, and open-source controllers like OpenDaylight and ONOS all rely on southbound APIs. Even if you work in a traditional network environment, understanding these concepts prepares you for the inevitable migration to programmable infrastructure.

Finally, troubleshooting a network problem often requires understanding the southbound communication path. If a policy change does not take effect, the issue might be in the southbound API: the controller may have failed to send the command, the device may have rejected it, or the protocol version might be incompatible. Without knowing southbound APIs exist, a technician might waste time checking device configurations instead of the controller-device communication channel.

## Why it matters in exams

Southbound API is a topic that appears in multiple IT certification exams, especially those covering software-defined networking. For the CompTIA Network+ (N10-009) exam, the term does not appear as a standalone objective, but understanding SDN architecture is required. Candidates should know that southbound APIs connect the SDN controller to the data plane devices. The exam may include a scenario asking about the role of APIs in network programmability, and choosing "southbound" as the interface that communicates with network hardware is a possible correct answer.

In the Cisco CCNA (200-301) exam, SDN concepts are explicitly tested. Objective 5.1 (Describe the characteristics of SDN, including overlay, underlay, and fabric) and 5.2 (Compare traditional campus device management with SDN) require knowledge of southbound APIs. CCNA candidates should know that southbound APIs are used in Cisco's Application Centric Infrastructure (ACI) and SD-Access. The exam might present a multiple-choice question asking which component in SDN communicates with the data plane, with options like northbound API, southbound API, REST API, and CLI. The correct answer is southbound API.

For the Cisco CCNP Enterprise (350-401 ENCOR) exam, the topic is deeper. Objective 6.0 (Automation and Programmability) includes understanding SDN controller types, southbound protocols like OpenFlow, NETCONF, and RESTCONF. Candidates might face drag-and-drop questions matching protocols to their API direction (southbound vs northbound). They could also see a lab simulation where they must identify which protocol is being used for southbound device management based on the output of a show command.

The AWS Certified Solutions Architect (SAA-C03) exam touches on southbound APIs indirectly through AWS services like AWS Direct Connect and AWS Transit Gateway, but the term itself is not a core objective. However, knowledge of SDN concepts helps understand how virtual networks are managed in the cloud. For the AWS Certified Advanced Networking (ANS-C01) exam, southbound API understanding is more relevant. Candidates need to know how controllers like Amazon VPC Lattice use southbound APIs to program virtual network devices.

For the Juniper JNCIA-Junos exam, SDN concepts are part of the automation track. The exam includes questions about the role of southbound APIs in Juniper Contrail Networking and the use of NETCONF and YANG as southbound protocols. Similarly, in the VMware NSX-V or NSX-T exams, understanding how the NSX Manager uses southbound APIs (like OVSDB) to communicate with virtual switches is critical.

In all these exams, the most common question pattern is: "Which API does the SDN controller use to communicate with network devices?" The answer is always southbound API. Another common pattern is giving a list of protocols and asking which one is a southbound protocol (e.g., OpenFlow, NETCONF, SNMP). Finally, scenario questions about why a configuration change did not apply might point to a southbound API issue like a dropped connection or version mismatch. Memorize the direction: southbound goes down to the devices; northbound goes up to applications.

Study tip: draw a simple 3-layer diagram (apps, controller, devices) and label the northbound and southbound interfaces. This visual will help you answer questions about API direction quickly. Also remember the key southbound protocols: OpenFlow, NETCONF, RESTCONF, gNMI, OVSDB, and SNMP (though SNMP is older, it is sometimes used as a southbound protocol in hybrid networks).

## How it appears in exam questions

Exam questions about southbound APIs typically fall into three categories: definition and direction, protocol identification, and scenario-based troubleshooting.

Definition and direction questions are the most common. A typical multiple-choice question might read: "In SDN architecture, which interface does the controller use to communicate with the physical switches and routers?" The options might include "Northbound API," "Eastbound API," "Westbound API," and "Southbound API." The correct answer is Southbound API. Another variant: "Which of the following is a characteristic of a southbound API?" with answer options like "It communicates with applications above the controller" or "It communicates with network devices below the controller." The correct answer is the latter.

Protocol identification questions test your knowledge of which protocols are southbound. Example: "Which of the following protocols is commonly used as a southbound API in SDN?" Choices could be OpenFlow, NETCONF, REST, and BGP. The correct answers might be OpenFlow and NETCONF. In a multiple-select question on Cisco ENCOR, you might see: "Which two protocols are southbound protocols used by an SDN controller?" (Select two). The correct answers are OpenFlow and NETCONF. Sometimes they include SNMP as a legitimate southbound protocol for legacy devices, so be careful: SNMP can be used, but it is less common in modern SDN deployments.

Scenario-based questions present a problem and ask you to identify the cause. For example: "A network administrator configures a new QoS policy on the SDN controller, but the policy does not take effect on the switches. The controller shows the switches as online. What is the most likely cause?" Options might include: the northbound API is down, the southbound API is not functioning correctly, the application layer is misconfigured, or the switches are out of memory. The correct answer is that the southbound API is not functioning correctly, because even though the switches are online, the controller cannot push the policy down to them if the southbound channel has a problem (e.g., protocol mismatch, authentication failure, or a dropped connection).

Another scenario: "An engineer is troubleshooting an SDN network where the controller is unable to collect traffic statistics from the data plane devices. Which layer of the SDN architecture should the engineer investigate first?" The answer is the southbound interface, as it is the channel through which the controller receives telemetry from devices. A wise candidate would look at the NETCONF or OpenFlow session status.

Config scenario questions might ask you to interpret a command output. For instance, the controller CLI shows "show openflow controller status" and lists switches with "connected" but "version mismatch." You need to know that the southbound API is failing due to incompatible OpenFlow versions. The answer would be to upgrade the switch firmware or change the controller's protocol version.

Finally, some exams include comparison questions: "Which of the following best describes the difference between a northbound API and a southbound API in SDN?" The answer should indicate that northbound APIs communicate with applications and business logic, while southbound APIs communicate with network infrastructure. Remember the direction: north goes up (to apps), south goes down (to devices). This directional understanding is crucial because it is the most tested concept related to southbound APIs.

## Example scenario

You are a network engineer at a mid-sized company that has just deployed a software-defined network using an open-source SDN controller. The controller manages a dozen switches across two data center racks. Your company uses voice-over-IP (VoIP) phones for all internal calls, and you want to ensure that VoIP traffic always gets priority over web browsing and file transfers.

You log into the SDN controller's web interface and define a policy: "Mark all traffic to and from the VoIP server IP 10.0.1.100 as high priority, and give it reserved bandwidth of 10 Mbps." The controller accepts the policy and updates its internal database. But for this policy to actually work on the switches, the controller needs to communicate the policy to each switch. This is where the southbound API comes in.

The controller uses a southbound protocol-let us say OpenFlow-to send flow entries to each switch. One flow entry says: "If the source IP is 10.0.1.100 or the destination IP is 10.0.1.100, then set the DSCP value to 46 and forward with high priority queue." Another flow entry says: "For all other traffic, forward using the default queue." The southbound API securely connects to each switch, authenticates the controller, and installs these flow entries into the switch's hardware forwarding tables.

After the policy is applied, you make a test call from a VoIP phone. The call is clear because the southbound API successfully configured the switches to prioritize that traffic. However, a few hours later, you notice that the VoIP calls are getting choppy during peak hours. You check the controller's dashboard and see that some switches are not reporting their traffic counters. You suspect the southbound API connection to those switches is intermittent. You log into the controller CLI and run a command to check southbound session status. You see that one switch has a NETCONF session retry count of 15, indicating connectivity problems. You find that the switch's management IP changed due to a DHCP lease renewal, and the controller still has the old IP address in its inventory. After updating the IP in the controller, the southbound connection restabilizes, and the traffic counters start flowing again. You also see that the VoIP traffic is now properly prioritized because the switches have the correct flow entries installed.

This scenario shows how the southbound API is not a set-it-and-forget-it component. It requires monitoring and maintenance. Without it, even the best-defined policies on the controller are useless because they never reach the devices. The southbound API is the delivery mechanism that turns a network administrator's intent into actual forwarding decisions on the wire.

## Common mistakes

- **Mistake:** Thinking a southbound API is the same as a REST API used to talk to an SDN controller from a web dashboard.
  - Why it is wrong: A REST API used by a web dashboard or script to communicate with an SDN controller is actually a northbound API, not a southbound API. Northbound APIs face applications; southbound APIs face network devices. Confusing the direction is a common error in exams because the same term 'API' is used for both.
  - Fix: Remember the physical world: south is down (toward the ground/network hardware), north is up (toward the sky/applications). If it talks to a switch, it is southbound. If it talks to an app, it is northbound.
- **Mistake:** Believing that SNMP is the only southbound protocol used in modern SDN.
  - Why it is wrong: While SNMP is a legitimate southbound protocol for monitoring, it is not the primary protocol for configuration in modern SDN. Protocols like OpenFlow, NETCONF, and gNMI are more common. Many learners overlook these because they are older and more comfortable with SNMP.
  - Fix: For SDN, focus on learning OpenFlow (for flow-based control) and NETCONF/RESTCONF (for configuration management). SNMP is more for traditional management and monitoring, not for real-time forwarding control.
- **Mistake:** Assuming the southbound API is only used for sending commands from the controller to devices, and not for receiving data back.
  - Why it is wrong: The southbound API is bidirectional. Devices send back statistics, link state changes, error messages, and other telemetry to the controller. If you only think of it as one-way, you will fail to understand how the controller maintains a real-time view of the network.
  - Fix: Think of the southbound API as a two-way radio: the controller talks, and the devices talk back. Both directions are essential for effective network management.
- **Mistake:** Confusing southbound API with southbound interface in other contexts, like in transport networks or electrical engineering.
  - Why it is wrong: The term 'southbound' is used in other industries (e.g., southbound interface in rail transport), but in IT networking, it has a specific meaning related to SDN architecture. Using a generic definition leads to confusion in exam answers.
  - Fix: Always understand the context. In IT certification exams, 'southbound API' always refers to the SDN interface between the controller and data plane devices.
- **Mistake:** Thinking that all southbound APIs are hardware-dependent and require specialized hardware.
  - Why it is wrong: Southbound APIs also work with virtual switches (software-based) like Open vSwitch, VMware vDS, and Linux bridges. Many SDN deployments are in virtualized environments where the 'data plane' consists of software running on hypervisors, not physical boxes.
  - Fix: Remember that the data plane can be physical or virtual. Southbound APIs abstract away that distinction, allowing the controller to manage both with the same protocol.

## Exam trap

{"trap":"The exam asks: 'Which API does an SDN controller use to communicate with applications that manage the network?'","why_learners_choose_it":"Learners see 'communicate with applications' and quickly associate 'API' with the familiar northbound API. They might also think the southbound API is the only API in SDN, so they incorrectly pick southbound.","how_to_avoid_it":"Read the direction carefully. The question says 'communicate with applications,' which sit above the controller. That is the northbound API. Southbound API communicates with devices below the controller. Always draw the mental picture: north = apps, south = switches."}

## Commonly confused with

- **Southbound API vs Northbound API:** A northbound API is the interface between the SDN controller and the applications or services that consume network services. It allows applications to request network resources (e.g., a virtual network segment) or receive network statistics. The southbound API, on the other hand, is between the controller and the physical/virtual network devices. Northbound goes up to apps; southbound goes down to hardware. (Example: If a cloud management platform asks the SDN controller to create a new VLAN, it uses the northbound API. The controller then uses the southbound API to configure that VLAN on all relevant switches.)
- **Southbound API vs Eastbound/Westbound API:** Eastbound and westbound APIs are interfaces between multiple SDN controllers or between an SDN controller and other control plane entities, like legacy network management systems. They enable distributed control and synchronization. The southbound API is only for talking down to data plane devices, not for inter-controller communication. (Example: If two SDN controllers need to share network topology information to coordinate routing across a WAN, they use east-west APIs. Meanwhile, each controller still uses its own southbound API to manage its local switches.)
- **Southbound API vs REST API (general):** REST API is a general architectural style for designing web services, often used for northbound APIs in SDN. When people say 'REST API' in the context of SDN, they usually mean the northbound interface. However, REST can also be used as a southbound protocol in some implementations (e.g., RESTCONF). The key difference is the direction and the data models used. (Example: A Python script that queries the controller for device inventory uses the northbound REST API. A NETCONF session that pushes a configuration to a switch uses a southbound protocol which could also use RESTCONF (a RESTful southbound protocol), but it is not just 'REST API' generically.)

## Step-by-step breakdown

1. **High-Level Policy Definition** — The network administrator or an automated system defines a policy at the application layer, such as 'Give video conferencing traffic the highest priority.' This policy is expressed in business terms or high-level network intent, not in device-specific commands.
2. **Northbound API Translation** — The policy is sent to the SDN controller via the northbound API. The controller receives this intent and interprets it into a set of global network requirements. This step is crucial because the controller must understand what changes need to be made at the device level to achieve the desired outcome.
3. **Controller Decision Making** — The SDN controller's internal logic determines the specific forwarding rules, quality of service (QoS) policies, or ACL entries needed. It calculates the best path, considers network topology, and identifies which devices need which rules. The controller maintains a unified view of the entire network.
4. **Southbound API Call Preparation** — The controller prepares the configuration commands in a format that the southbound protocol understands. For example, if using OpenFlow, it constructs flow mod messages. If using NETCONF, it builds an XML configuration payload according to a YANG data model. This step ensures the message is syntactically correct.
5. **Secure Transmission to Device** — The controller opens a secure session (e.g., TLS for OpenFlow, SSH for NETCONF) with the target network device. It authenticates itself using certificates or credentials. The southbound message is then sent over this encrypted channel. This step is critical for security and trust.
6. **Device Processing and Application** — The network device receives the southbound message, validates it, and applies the configuration to its hardware forwarding tables. For OpenFlow, this means installing flow entries in the TCAM. For NETCONF, it means updating the running configuration. The device may also acknowledge receipt or report success/failure.
7. **Feedback and Monitoring** — The device sends back status information, counters, or event notifications via the southbound API. The controller collects this feedback to update the network state, verify that the policy took effect, and detect any anomalies. This continuous feedback loop enables dynamic, real-time network management.

## Practical mini-lesson

A southbound API is not a single technology but a category of protocols and interfaces that allow an SDN controller to manage the data plane. In practice, a professional needs to understand which southbound protocol is appropriate for the devices under management. For greenfield deployments with OpenFlow-capable switches, OpenFlow is a strong choice because it provides direct, flow-level control. For environments with existing routers and switches from multiple vendors, NETCONF/YANG or RESTCONF are often better because they align with the IETF standards and can manage a broader range of device features.

When configuring an SDN controller for southbound communication, you must specify the device's IP address, authentication method (certificate, password, or API key), and the protocol version. For OpenFlow controllers like OpenDaylight, you configure the controller's IP and port (default 6653) on each switch, or you can configure auto-discovery using LLDP. For NETCONF, the controller needs to know the SSH port (default 830) and the device's credentials. It is also important to verify that the YANG models used by the controller match what the device supports.

One common issue in the field is protocol version mismatch. For example, a controller may support OpenFlow 1.3, but a switch only supports OpenFlow 1.0. In that case, the southbound session fails or operates with reduced functionality. The same can happen with NETCONF capabilities. Always check the device's documentation for supported protocol versions and configure both sides accordingly.

Another practical concern is scalability. The southbound API must handle a large number of messages, especially when the controller needs to update many flows simultaneously. If the controller sends 10,000 flow mods per second, but the switch can only process 1000 per second, the switch's processing delay can cause packet loss or buffer overflow. This is why southbound protocol performance is a key factor in SDN design. Some controllers implement rate limiting or batched operations to avoid overwhelming devices.

Security is non-negotiable. Southbound communication must be authenticated and encrypted. In some environments, management traffic travels over a separate management network or a dedicated OOB management VLAN. The controller should also be configured to verify device certificates to prevent rogue devices from connecting and receiving configuration commands.

Finally, southbound APIs are used not only for initial configuration but also for ongoing operations like topology discovery, monitoring, and fault detection. For instance, the controller may periodically send echo requests over OpenFlow or NETCONF to verify device liveness. If a device stops responding, the controller can reconfigure paths around it. Telemetry data collected via southbound APIs feeds into analytics tools that help with capacity planning and security incident response.

A professional who masters southbound API concepts will be able to design and troubleshoot SDN networks effectively. They will know that when a policy is not working, the first place to check is the southbound connection list, the protocol version, and the authentication state. They will also be able to choose the right southbound protocol based on the devices and the control needs, whether it is fine-grained flow control (OpenFlow) or device-level configuration management (NETCONF/YANG).

## Memory tip

South goes down to the ground (switches). North goes up to the sky (applications).

## FAQ

**Is a southbound API the same as a southbound interface?**

In SDN terminology, they are often used interchangeably. Both refer to the interface between the SDN controller and the data plane devices. However, the term 'southbound API' emphasizes the programmatic, API-driven nature of the communication.

**Can a southbound API work with legacy routers that do not support OpenFlow?**

Yes, by using NETCONF/YANG protocol allows management of many legacy devices if they support it. Also, some controllers can use SNMP as a southbound protocol for legacy devices that lack newer capabilities.

**Do southbound APIs only exist in SDN networks?**

They are most commonly discussed in the context of SDN, but similar concepts exist in any network where a central controller manages distributed devices, such as in cloud networking platforms. The term is predominantly used in SDN literature.

**How is the southbound API secured?**

Security is implemented through encrypted tunnels (TLS for OpenFlow, SSH for NETCONF), mutual authentication using certificates or credentials, and sometimes through IP allowlisting or dedicated management VLANs.

**What happens if the southbound API connection is lost?**

The switches continue forwarding traffic based on the current flow entries, but they cannot receive new or updated policies from the controller. The controller loses visibility into the device's status. This is known as a 'fail-standalone' mode. Some networks use a backup controller to take over.

**Are there any downsides to using a southbound API?**

Potential downsides include protocol compatibility issues between different vendors, the overhead of maintaining the API connections, and the risk of a misconfigured controller pushing bad rules to all devices. Also, the controller becomes a potential single point of failure.

**Do I need to know southbound API for the CCNA exam?**

Yes, the CCNA 200-301 exam includes SDN architecture concepts, and you should understand that the southbound API connects the controller to the data plane. It is a general knowledge point rather than a deep dive.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/southbound-api