Software-Defined Networking (SDN)

The Traditional Networking Problem

In traditional networking, every router and switch is an autonomous system. Each device runs its own control plane (routing protocols like OSPF, BGP) and its own data plane (packet forwarding). Configuration is per-device, management is via CLI, and network-wide policy changes require touching every box individually.

This tight coupling created several critical pain points:

• Configuration drift — devices fall out of sync as manual changes accumulate
• Vendor lock-in — each vendor's proprietary CLI and OS
• Slow innovation — new features require firmware upgrades on every device
• Limited programmability — can't easily implement custom forwarding logic
• Operational complexity — troubleshooting requires correlating state across many devices

flowchart TB
    subgraph R1["Router 1"]
        CP1["Control Plane\nOSPF + BGP"]
        DP1["Data Plane\nForwarding"]
        CP1 --> DP1
    end
    subgraph R2["Router 2"]
        CP2["Control Plane\nOSPF + BGP"]
        DP2["Data Plane\nForwarding"]
        CP2 --> DP2
    end
    subgraph R3["Router 3"]
        CP3["Control Plane\nOSPF + BGP"]
        DP3["Data Plane\nForwarding"]
        CP3 --> DP3
    end
    CP1 <-.->|"Routing Updates"| CP2
    CP2 <-.->|"Routing Updates"| CP3
    DP1 <-->|"Traffic"| DP2
    DP2 <-->|"Traffic"| DP3
                            

The SDN Revolution

Software-Defined Networking fundamentally restructures this architecture by extracting the control plane from every device and centralizing it. The data plane devices become simple forwarding elements — "dumb pipes" programmed by a logically centralized controller.

flowchart TB
    subgraph CP["Centralized Control Plane"]
        APP1["Routing App"] --> CTRL["SDN Controller"]
        APP2["Firewall App"] --> CTRL
        APP3["LB App"] --> CTRL
    end
    subgraph DP["Distributed Data Plane"]
        SW1["Switch 1"]
        SW2["Switch 2"]
        SW3["Switch 3"]
        SW4["Switch 4"]
    end
    CTRL -->|"Southbound API"| SW1
    CTRL -->|"Southbound API"| SW2
    CTRL -->|"Southbound API"| SW3
    CTRL -->|"Southbound API"| SW4
    SW1 <--> SW2
    SW2 <--> SW3
    SW3 <--> SW4
                            

The key insight: a logically centralized control plane doesn't mean a physically centralized one. The controller can be distributed for fault tolerance while presenting a single, unified view of the network to applications.

OpenFlow Protocol

OpenFlow was the first widely-adopted southbound protocol for SDN — the communication interface between the controller (control plane) and switches (data plane). It defines how the controller installs, modifies, and removes flow rules in switch flow tables.

Flow Table Structure

Each OpenFlow switch maintains one or more flow tables. Each entry has:

• Match fields — packet header values to match (src/dst MAC, IP, port, VLAN)
• Priority — higher priority rules match first
• Counters — packet/byte counts for matched traffic
• Actions — what to do with matching packets (forward, drop, modify, send to controller)
• Timeouts — idle and hard timeout for flow expiration

sequenceDiagram
    participant Host as End Host
    participant SW as OpenFlow Switch
    participant Ctrl as SDN Controller
    participant App as SDN Application

    Host->>SW: Packet arrives (no matching flow)
    SW->>Ctrl: PACKET_IN (table miss)
    Ctrl->>App: New flow notification
    App->>Ctrl: Forwarding decision
    Ctrl->>SW: FLOW_MOD (install flow rule)
    Ctrl->>SW: PACKET_OUT (forward buffered pkt)
    Note over SW: Flow rule installed
    Host->>SW: Subsequent packets
    Note over SW: Match rule, forward at line rate
                            

# OpenFlow flow rule (conceptual YAML representation)
flow_rule:
  table_id: 0
  priority: 100
  match:
    eth_type: 0x0800        # IPv4
    ipv4_src: 10.0.1.0/24   # Source subnet
    ipv4_dst: 10.0.2.0/24   # Destination subnet
    ip_proto: 6             # TCP
    tcp_dst: 80             # HTTP traffic
  actions:
    - set_field:
        eth_dst: "00:00:00:00:02:01"
    - output:
        port: 3             # Forward out port 3
  idle_timeout: 300         # Remove after 5 min idle
  hard_timeout: 3600        # Remove after 1 hour

SDN Controller Architectures

The SDN controller is the "network operating system" — it maintains a global view of the network topology, computes forwarding paths, and programs the switches. Several open-source and commercial controllers have emerged:

ONOS (Open Network Operating System)

Built for carrier-grade networks. Features distributed clustering (Atomix/Raft consensus), intent-based networking, and fault tolerance. Written in Java with a modular OSGi architecture.

OpenDaylight (ODL)

Industry-backed (Linux Foundation), supports multiple southbound protocols (OpenFlow, NETCONF, BGP-LS). Model-driven with YANG data models. Extensive plugin ecosystem.

Floodlight

Lightweight, single-instance controller for research and small deployments. Simple REST API, easy to extend. Good for learning SDN concepts.

Southbound vs Northbound APIs

SDN's layered architecture defines two critical API boundaries:

Southbound API (Controller → Data Plane): The protocol used to program forwarding devices. OpenFlow is the canonical example, but alternatives include P4Runtime, gRPC/gNMI, NETCONF/YANG, and OVSDB.

Northbound API (Applications → Controller): REST APIs, gRPC interfaces, or intent frameworks that applications use to express networking requirements. Examples: ONOS Intent Framework, ODL RESTCONF, custom REST APIs.

Cloud Networking as SDN

Every major cloud provider's networking is SDN at massive scale — they just don't always call it that. The cloud control plane manages virtual networks, and the data plane runs on hypervisor-level virtual switches.

flowchart TB
    subgraph CP2["Cloud Control Plane"]
        API["Cloud API\n(VPC, Subnet, Route Table)"]
        NC["Network Controller"]
        API --> NC
    end
    subgraph DP2["Cloud Data Plane (per host)"]
        VS1["Virtual Switch\n(Host 1)"]
        VS2["Virtual Switch\n(Host 2)"]
        VS3["Virtual Switch\n(Host 3)"]
    end
    NC -->|"Flow Programming"| VS1
    NC -->|"Flow Programming"| VS2
    NC -->|"Flow Programming"| VS3
    VS1 <-->|"Encapsulated Traffic\n(VXLAN/Geneve)"| VS2
    VS2 <-->|"Encapsulated Traffic"| VS3
                            

AWS VPC as SDN

• Control plane: VPC API, Route Tables, Security Groups, NACLs — all declarative intent
• Data plane: Nitro Cards (custom ASICs) on each host handle encapsulation, security group enforcement, and forwarding at line rate
• Overlay: Packets encapsulated in proprietary format across the physical underlay

Azure Virtual Network

• Control plane: Azure Network Resource Provider, NSGs, UDRs, Azure Firewall policies
• Data plane: Azure SmartNIC (FPGA-based) offloads virtual networking from host CPU
• Innovation: AccelNet — FPGA reprogrammable data plane for new features without hardware changes

GCP VPC

• Control plane: Andromeda network virtualization stack, global VPC spanning all regions
• Data plane: Hoverboards — custom network processors on each host
• Unique: Single global VPC (no regional boundaries) — the control plane abstracts geography entirely

Kubernetes CNI as SDN

Kubernetes Container Network Interface (CNI) plugins are SDN implementations for container networking. Each CNI plugin implements its own control/data plane split:

Calico

• Control plane: Felix agent (per-node) + BIRD BGP daemon + etcd/Kubernetes API as datastore
• Data plane: Linux kernel routing tables + iptables rules (or eBPF in newer versions)
• Architecture: Pure L3 routing — no overlay, no encapsulation (in default mode)

Cilium

• Control plane: Cilium agent (per-node) watches Kubernetes API for pod/service/policy changes
• Data plane: eBPF programs attached to network interfaces — bypasses iptables entirely
• Innovation: Identity-based security (not IP-based), transparent encryption, L7 policy

Flannel

• Control plane: flanneld daemon reads subnet config from etcd, allocates per-node CIDR
• Data plane: VXLAN encapsulation (or host-gw for same-subnet nodes)
• Simplicity: Minimal features, focuses on basic connectivity (no network policy)

# Kubernetes NetworkPolicy — SDN control plane declaration
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

# Check Cilium CNI status — control and data plane health
cilium status
# Output shows:
#   KVStore:       Ok   Disabled
#   Kubernetes:    Ok   1.28 (v1.28.4) [linux/amd64]
#   Controller:    Ok
#   Proxy:         Ok   (Envoy)
#   Hubble:        Ok   (via Hubble Relay)
#   ClusterMesh:   Ok

# View Cilium eBPF data plane programs
cilium bpf endpoint list

# Show loaded eBPF programs on a node
bpftool prog list | grep cilium

eBPF as Data Plane Technology

Extended Berkeley Packet Filter (eBPF) represents the next evolution of programmable data planes. Instead of fixed-function forwarding hardware or iptables rules, eBPF allows custom programs to run inside the Linux kernel at near-native speed.

XDP (eXpress Data Path)

XDP is eBPF at the earliest possible point in the network stack — before the kernel allocates an sk_buff. This enables packet processing at millions of packets per second per core:

• XDP_DROP — drop packet (DDoS mitigation at line rate)
• XDP_TX — bounce packet back out same interface (load balancer)
• XDP_REDIRECT — forward to different interface or CPU
• XDP_PASS — continue normal kernel processing

flowchart LR
    subgraph KernelSpace["Linux Kernel"]
        NIC["NIC Driver"] --> XDP["XDP\n(earliest hook)"]
        XDP --> TC["TC Ingress\neBPF"]
        TC --> SK["Socket\neBPF"]
    end
    subgraph UserSpace["User Space"]
        Agent["Cilium Agent\n(Control Plane)"]
        Maps["eBPF Maps\n(Shared State)"]
    end
    Agent -->|"Load Programs"| XDP
    Agent -->|"Load Programs"| TC
    Agent -->|"Update"| Maps
    Maps -.->|"Read"| XDP
    Maps -.->|"Read"| TC
                            

# Verify eBPF programs loaded by Cilium
# Lists all BPF programs with their attach points
bpftool prog show

# Check XDP program on an interface
ip link show dev eth0
# Look for: xdp/prog/id

# View eBPF map contents (connection tracking)
bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_ct4_global

# Cilium monitor — real-time data plane events
cilium monitor --type drop --type trace

Network Function Virtualization

NFV complements SDN by virtualizing network functions that traditionally ran on dedicated hardware appliances — firewalls, load balancers, IDS/IPS, WAN optimizers. While SDN separates control from data plane, NFV virtualizes the functions themselves.

The relationship: SDN provides the programmable network fabric; NFV provides the virtualized services running on that fabric.

• VNFs (Virtual Network Functions) — software implementations of network appliances running on commodity servers
• Service chaining — SDN steers traffic through ordered sequences of VNFs
• MANO (Management and Orchestration) — lifecycle management of VNFs (ETSI NFV framework)

Benefits & Challenges

SDN Benefits

• Programmability — network behavior defined in software, iterable at software speed
• Centralized policy — express intent once, applied network-wide consistently
• Network automation — APIs enable CI/CD for network changes
• Vendor independence — control plane software independent of data plane hardware
• Global optimization — controller sees full topology, can compute globally optimal paths
• Rapid innovation — new features deployed as software updates to the controller

SDN Challenges

• Controller as SPOF — logically centralized means the controller is critical path (mitigated by clustering)
• Scalability — controller must handle all table-miss events and topology changes across large networks
• Consistency — distributed controllers must maintain consistent network view (CAP theorem applies)
• Security — controller compromise means entire network compromise
• Migration — brownfield deployments must coexist with traditional networking during transition
• Latency — first packet of new flows incurs controller round-trip (reactive mode)