SDN controllers in practice: OpenDaylight, ONOS and Cisco SD-Access

From SDN theory to products

Software-defined networking separates the decision-making (control plane) from forwarding (data plane) and puts a controller in charge, with northbound APIs for applications and southbound protocols to devices. The theory is explained in Network planes and SDN. In practice you meet two kinds of controller: open-source platforms that you build solutions on, and vendor systems that automate one kind of network end to end.

OpenDaylight

OpenDaylight (ODL) is an open-source controller platform hosted by the Linux Foundation. It is written in Java and built from modules that you install as features. At its heart is a model-driven service layer: every module describes its data with YANG, and ODL automatically exposes that data through RESTCONF northbound.

• Southbound plug-ins include NETCONF, OpenFlow, BGP-LS (to learn topology) and PCEP (to program paths in provider networks).
• It is mostly used as a building block inside other products and in service-provider orchestration, rather than run on its own by a typical enterprise.

ONOS

ONOS (Open Network Operating System) is an open-source controller designed for carrier networks. Its key feature is that it runs as a cluster: several instances share the network state, so the controller keeps working if one fails and can handle very large networks. Applications ask for outcomes through intents (for example "connect these two hosts"), and ONOS works out and maintains the flows. It supports OpenFlow, NETCONF, P4Runtime and other southbound protocols. For a wider comparison of controllers see SDN controllers.

Cisco SD-Access: SDN for the campus

SD-Access is Cisco's campus fabric. The controller is Catalyst Center (called DNA Center before 2023), which handles design, provisioning, policy and assurance, working with Cisco ISE for identity.

• Underlay: a routed network, often built automatically by Catalyst Center's LAN automation using IS-IS. No spanning tree between switches.
• Data plane: a VXLAN overlay carries user traffic between fabric switches (see Overlay networks).
• Control plane: LISP. Edge switches register each connected host with the control plane node, which answers "where is this host now?" lookups, so users can roam between floors and keep their address.
• Policy plane: virtual networks (VRFs) give macro-segmentation, such as separating building systems from staff. Scalable group tags (SGTs), assigned by ISE when a user or device authenticates, give micro-segmentation inside a virtual network. The tag travels in the VXLAN header, so policy follows the user rather than the IP address or port.

Instead of configuring each switch, the administrator defines sites, IP pools, virtual networks and group policies in Catalyst Center, and it pushes the configuration to every node. Assurance then compares how the network behaves against what was intended.

Real-world example: one campus, three kinds of device

A fictional university campus had staff, students and thousands of building-management sensors on the same switches, separated by dozens of VLANs and long ACLs that nobody fully understood. During a refresh, the network team deployed SD-Access. Catalyst Center built the underlay and fabric across 60 switches. Three virtual networks separated campus users, building systems and guests. Inside the campus-users network, ISE assigned SGTs for staff, students and research devices, and a small policy matrix allowed students to reach teaching servers but not staff file shares. When a lecturer moved between buildings her laptop kept its address and policy, and the ACL count on the switches dropped to almost nothing, because the policy now lived in the controller.