Software Defined Networking (SDN) Basics - Networking Basics

Software Defined Networking (SDN) is a paradigm shift in how we design and manage networks. Instead of configuring individual devices, we program network behavior centrally.

Traditional Networking vs SDN

Traditional Network

Each device is independent:

Router A:
- Learns routes from neighbors (BGP/OSPF)
- Makes forwarding decisions locally
- Firewall rules manually configured
- QoS manually configured on each device
- Takes 30 minutes to change a rule across network

Problem: Distributed, hard to manage, slow to change

Software-Defined Network

Central Controller programs all devices:

SDN Controller:
- Knows topology of entire network
- Programs datapath on each device
- Enforces policies globally
- Can change behavior in seconds
- Single management point

Result: Centralized, programmable, dynamic

SDN Architecture

Three-Layer Architecture

┌──────────────────────────────────────┐
│ Application Layer                    │
│ (Network Apps: Routing, FW, LB)      │
├──────────────────────────────────────┤
│ Control Layer                        │
│ (SDN Controller: OpenDaylight, ONOS) │
├──────────────────────────────────────┤
│ Data/Forwarding Layer                │
│ (OpenFlow/T-API Switches)            │
└──────────────────────────────────────┘

Data Plane (Switches)

Forwards packets based on flow rules
Low overhead, fast forwarding
Minimal intelligence

Control Plane (Controller)

Makes forwarding decisions
Maintains network state/topology
Programs data plane
Can run applications

Management Plane

Monitor and provision network
Interact with controller

OpenFlow Protocol

Purpose: Communication between controller and switches

How It Works:

Switch receives packet, doesn't recognize flow:
1. Switch sends Packet In message to controller
   "I received a packet from source X to destination Y"

2. Controller makes decision:
   "This traffic should go to port 3"

3. Controller sends Flow Mod message to switch
   "Add rule: packets like this go to port 3"

4. Future packets matching follow the rule locally
   (no more controller involved)

Example Flow Rule:

Flow Entry:
├─ Match: TCP port 80 from 10.0.0.0/8 to 10.1.0.0/8
├─ Action: Forward to port 3
├─ Priority: 100
└─ Timeout: 300 seconds

SDN Use Cases

1. Network Service Chaining

Internet → Firewall → IDS → Load Balancer → Servers

Traditional:
- Configure each device individually
- Hard to insert new service

SDN:
- Controller programs path through all services
- Add service by changing controller logic
- Can be per-flow (different flows different paths)

2. Dynamic Load Balancing

Controller monitors:
- Server load
- Network congestion
- Latency

Dynamically rebalances traffic:
"Route new connections to less-loaded server"
Changes in seconds (vs manual hours)

3. Network Virtualization

Physical Network:
4 switches, 30 servers

Virtual Network 1:
10 virtual switches, 20 virtual servers
(Overlays physical network)

Virtual Network 2:
8 virtual switches, 30 virtual servers

Controller maintains isolation:
Traffic from VN1 never touches VN2

4. Traffic Engineering

Path options for 10.0.0.0/8 to 10.1.0.0/8:
- Via router A (30ms, 80% loaded)
- Via router B (40ms, 20% loaded)
- Via router C (50ms, 10% loaded)

Traditional: Uses shortest path (router A)
SDN: Can choose least congested (router C)
Result: Better utilization, lower latency for most traffic

SDN Controller

Responsibilities:

Controller maintains:
├─ Network topology
│  (Knows which switch connects where)
├─ Network state
│  (VLAN config, IP addresses, firewall rules)
├─ Flow table
│  (What rules installed on each switch)
└─ Statistics
   (Traffic counters, dropped packets)

Controller applications:
├─ Routing
├─ Firewall (Network Policy)
├─ Load Balancer
└─ Traffic Engineering

Example Controllers:

Controller	Features	Platform
OpenDaylight	Extensive, modular	Open Source
ONOS	Scalable, HA	Open Source
Floodlight	Simple, prototyping	Open Source
Commercial	Cisco, Juniper, etc	Proprietary

Disadvantages of SDN

1. Latency

Traditional:
Packet arrives → Switch decides → Forward (microseconds)

SDN:
Packet arrives → Controller queried → Decision → Forward
(milliseconds, much slower)

Solution: Flow table caching (first packet slow, rest fast)

2. Complexity

Traditional: Configure routing protocol, it learns routes
SDN: Must write routing algorithm
Easier to make mistakes

3. Centralization Risk

Controller is single point of failure
(Usually mitigated with controller cluster)

4. Vendor Lock-in

Proprietary controllers make it hard to change
Open standards (OpenFlow) help, but implementation varies

SDN in Practice: Kubernetes CNI

Kubernetes networking powered by SDN concepts:

┌──────────────────────────────────┐
│ Kubernetes API Server            │
│ (Network policy definitions)      │
├──────────────────────────────────┤
│ CNI Controller                   │
│ (Calico/Cilium/Weave)            │
│ (Programs routing rules)          │
├──────────────────────────────────┤
│ Host Network Stack               │
│ (iptables/EBPF rules)            │
└──────────────────────────────────┘

Example:
1. User defines NetworkPolicy
2. CNI controller watches for changes
3. CNI programs firewall rules
4. Packets filtered/routed accordingly

SDN in Cloud: AWS and GCP

AWS VPC (Virtual Private Cloud)

Underlying SDN concepts:
├─ Subnets (virtual network segments)
├─ Security Groups (firewall rules)
├─ Network ACLs (stateless firewall)
├─ Route Tables (traffic rules)
└─ Elastic Network Interfaces (virtual NICs)

Managed by AWS controllers:
- You don't write OpenFlow
- You define desired state (VPC config)
- AWS programs underlying infrastructure

GCP Cloud Armor

Control Layer: GCP's management
Data Layer: Google's network
- Define policies in console
- GCP programs edge routers
- Policies applied globally

Network Functions Virtualization (NFV)

Related to SDN:

Traditional:
Firewall = dedicated hardware box
Load Balancer = dedicated hardware box
IDS = dedicated hardware box

NFV:
Firewall = software on virtual machine
Load Balancer = software on virtual machine
IDS = software on virtual machine

Benefits:
- Easier to scale
- Cheaper
- More flexible

SDN complement:
- NFV provides functions
- SDN orchestrates them

Programming SDN Network

Simple Python Example (Ryu Controller):

from ryu.base import app_manager
from ryu.controller import ofp_event
 
class SimpleSwitch(app_manager.RyuApp):
    def __init__(self, *args, **kwargs):
        super(SimpleSwitch, self).__init__(*args, **kwargs)
        self.mac_to_port = {}
 
    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        
        # Extract packet info
        src = src_mac
        dst = dst_mac
        
        # Learn source MAC → port mapping
        self.mac_to_port[src] = in_port
        
        # Forward based on learned table
        if dst in self.mac_to_port:
            out_port = self.mac_to_port[dst]
            
            # Program switch with flow rule
            self.add_flow(datapath, priority, match, actions)

Future of Networking

Intent-Based Networking (IBN)

Traditional way:
"Configure route to 10.0.0.0/8 via 203.0.113.1"

Intent-based way:
"Ensure 10.0.0.0/8 reaches 10.1.0.0/8 with <50ms latency"

System figures out how to achieve intent
Much more powerful and flexible

Key Concepts

SDN = Centralized network programming
Control plane = Decision making (controller)
Data plane = Packet forwarding (switches)
OpenFlow = Protocol for controller-switch communication
Flow rules = Downloaded to switches for fast forwarding
Network state maintained centrally
First packet to controller (slow), rest in switch table (fast)
Applications run on controller (routing, firewall, LB, etc.)
Infrastructure increasingly SDN-based
Enables automation, programmability, agility