SDN Architecture & Ecosystem

SDN Architecture and Ecosystem

S. Kingston [email protected]

Course Objective

SDN Architecture and Ecosystem

SDN switch Ecosystem

SDN Controller Ecosystem

Placement of Controller

SDN Migration Plan

SDN Security

Hands-On with RYU Controller

SDN Architecture Model

SDN Switch Ecosystem

Introduction to OpenFlow Switches

• Hardware-based OpenFlow Switches– Commercial hardware switches with OpenFlow capability

• Network abstraction is realized by firmware upgrading

– Show high processing speed

– Have space limitation on saving the flow table entries• Approximately store 1500 flow entries (due to expensive CAM)

– Not easy to upgrade• Most switches only support OpenFlow up to version 1.0

• Software-based OpenFlow Switches– OpenFlow enabled software switch (runs on x86 commodity computer)

– Performance is relatively low

– Store large amount of flow entries with bound (theoretically)

– Under active development, support most recent OpenFlow spec.

• Hybrid OpenFlow Switch– Supports both openflow as well as traditional routing / switching

– Much faster than software-based switches

Hardware-based OpenFlow Switches

Software-based OpenFlow Switches (1/3)

• OpenvSwitch (OVS)– Overview

• A virtual switch or Virtual Ethernet Bridge (VEB)

• User-space: configuration, control

• Kernel-space: datapath (included in main Linux kernel from v3.3)

– Features• Support OpenFlow protocol

• Support multiple tunneling protocols– VxLAN, Ethernet over GRE, IPsec, GRE over IPsec

• Fine-grained QoS

– Main components• ovs-vswitchd: a daemon that implements the switch

• ovsdb-server: lightweight database server that ovs-vswitch queries to

• ovs-vsctl: a utility for querying and updating the config. of ovs-vswitchd

• ovs-dpctl: a tool for configuring and monitoring the switch kernel module

• ovs-ofctl: a tool for monitoring and administering OpenFlow switches

• ovs-controller: a simple OpenFlow controller reference implementation

• openvswitch.ko: OpenvSwitch switching datapath

Hybrid Switch Approaches

SIN – With Default Gateway

Hybrid Switch – OFNormal

Hybrid Switch based on Port + Vlan

SDN Controller Ecosystem & Anatomy

Controller Architecture

Imperative Declarative

Legacy Architecture Next-Gen Architecture

Imperative Vs Declarative

• Declarative : A programming paradigm that expresses the logic of a computation without describing its control flow. Many languages applying this style to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it

• Imperative : A programming paradigm that describes computation in terms of statements that change a program state. Imperative programs define sequences of commands for the computer to perform

Imperative Controller Architecture

• Imperative is a top down approach to managing the network

• where network state is held and managed by the controller and pushed down to the network elements

• This may lead to scale limitations for the controller as the network grows

• Openflow is an example of an implementation of the imperative model

Declarative Controller Architecture

• Declarative model uses bottom up approach to manage the network

• where the physical switches handle the network state and the state is defined by the policies created by the controller

• The “Declarative” model scales much better

• APIC controller is an example of an implementation of the Declarative model

Centralized vs De-centralized vs Distributed Models

Centralized vs De-centralized vs Distributed Models

Anatomy of SDN Controllers



• SDN-enabled Applications– Communicate their requirements/polices to the network

– Can monitor network state and adapt accordingly

• SDN Network Controller– Controller translates from app requirement to low-level rules

– Controller summarizes the network state for applications

• SDN Datapath– Programmatic low-level control of all fwd’ing and configuration

– API for Capabilities advertisement and publishing statistics

– No resource contention with other entities

– Controller “owns” this device, subject to capabilities advertisement / negotiation

Controller Redundancy

• Single Switch can be controlled by more than one controller for load balancing or redundancy purpose

• The controller takes anyone of the following role– Master– Slave– Equal

Controller Redundancy

Master Equal Master - Slave

Controller Topology Discovery

Topology Discovery Protocols

OFDP LLDP

OpenFlow Discovery Protocol• Implemented by most SDN

controllers and de facto standard

• OFDP leverages the packet format of LLDP

• OFDP operates completely differently

Link Layer Discovery Protocol• IEEE 802.1AB• Used in traditional Ethernet

network devices

Topology Discovery Operations

OpenFlow Discovery Protocol

• Controller injects LLDP packets (Link Layer Discovery Protocol)

• Switches flood them to all ports


OpenFlow Discovery Protocol

• Other switches receive packets and report packet-in to controller.

• Controller learns topology from information about incoming ports


SDN – North Bound Interface

SDN – First Stage

SDN – Second Stage

SDN – Third Stage

Intent Based SDN

Controller Placement – Who Cares

SDN Controller Placement Considerations

Single Controller /

Multiple Controllers?

Redundant / Load Sharing?

Cluster / Independent?

Inband / Out of Band

Challenges in SDN

Scalability

Reliability

Inter-operability

Fault Tolerance

Controller Scalability – Handling Multiple Switches

Controller Scalability – Handling Multiple Switches

• Is it really a problem?– Nox can handle more than 30k requests / sec with multicore CPU

– This is fine for decent size enterprise, however for data center this is a problem.

• Solution– Multiple Controllers with auxiliary connections

– Proactive programming of Flow table entries

– Deploy hybrid switch with locally scoped application / protocol in the switch itself

– Keep the controller close to the switch network.

Controller Scalability – Handling Flow Events from Switch

Controller Scalability – Handling Flow Events From Switch

• Is it really a problem?– Performance of first three step depends on the capability and positioning of

controller• When the controllers are placed on close proximity it is negligible

– Performance of last step depends on the Switch• OVS is capable of installing Tens of thousands of flows per second

• Most of the hardware supports few thousands of flows per second

• Solution– Proactive programming of Flow table entries


Controller Reliability

Fault Tolerance

Fault Tolerance – Link Failure

• Is it really a problem?– Takes 5 steps to detect and recover from the link failure

– Traditional network devices detects the link failure very fast. However the link failure event is flooded across the network via some protocols.

– In SDN network it is not required.

– The failure recovery process in SDN is no worse than in traditional network.

• Solution– Proactive programming of Flow table entries


In-Band Vs Out-of-Band

• Out-of-Band: Separate network / link for controller switch connections

• In-Band: Attaching controller to a switch in a data plane

SDN Migration Plan

Key Questions to be asked

• What are my goals for migrating to open SDN?

• What are the initial steps I should take to achieve my goals for SDN?

• What are my migration options?

• How have others performed the migration , and how different from their strategies is my current SDN migration plan?

Key Steps for Migration

• Identify and prioritize the core requirements of the target network

• Prepare the starting network for migration

• Implement a phased network migration

• Validate the results

Migration Approaches: Greenfield

Migration Approaches: Mixed

Migration Approaches: Hybrid

Migration Approaches: Hierarchical

Migration Approaches: Hierarchical

SDN Migration Case Study (Google)

Key Questions to be asked

• What are my goals for migrating to open SDN?

• What are the initial steps I should take to achieve my goals for SDN?

• What are my migration options?

• How have others performed the migration , and how different from their strategies is my current SDN migration plan?

Two Kind of Networks

To improve scalability, flexibility, and agility in managing the Internet-facing WAN fabric to enhance Google’s user-based services, including Google+, Gmail, YouTube, Google Maps, and others

Internet-facing

user traffic

Internal traffic between

Google’s global data centers

Starting Network

Fully distributed monolithic control and data plane hardware architecture to a physically decentralized (though logically centralized) control plane architecture

Phased deployment

A subset of the nodes in the network were OpenFlow-enabled and controlled by the logically centralized controller utilizing Paxos, an OpenFlow controller, and Quagga open source routing stack that Google adapted to its requirements

Complete OpenFlow

All nodes were OpenFlow-enabled. In the target network, the controller controls the entire network. There is no direct correspondence between the data center and the network. The controller also has a TE server that guides the traffic engineering in the network.

Final Deployment

SDN Security Challenges

Threat Challenges

Centralized Control

Programmability

Cross Domain

Connection

Challenge of Integrating

Legacy Protocols

Centralized Control

• Exposes a high-value asset to attackers

• Attackers may attempt to manipulate the common network services or even control the entire network by tricking or compromising a controller

• Unauthorized Access to centralized controller using Password Brute-Forcing or Password-Guessing Attacks

• Unauthorized Access Using Remote Application Exploitation Attacks

Programmability

• Traffic and resource isolation

• Trust between third party applications and the controller

• Interface Security protection across controllers

SDN Threat Models

Generic network

infrastructure threats

SDN specific Threats

Network Virtualization

Threats

Generic network infrastructure threats

Generic Threats

Physical threats

Damage/loss.

Failures/malfunctions

Outages / Disaster / Legal

Generic network infrastructure threats

Traffic diversion

DOS

Data forging

Flooding attack

Side channel attack

Software exploits

API exploita

tion

Identity spoofing

Traffic sniffing

Memory scraping

SDN Reference Architecture Threats

Hands-on

Course Objective

How to run RYU Controller

How to run RYU features

Creating a network with Mininet

Programming a flow entry with RYU

Ping and test the Network

How to start RYU Controller

Run the given VM in Virtual Box

Goto/home/ubuntu/ryu cd /home/ubuntu/ryu

Run ./bin/ryu-manager ryu/app/simple_switch.py ryu/app/ofctl_rest.py

Run ./bin/ryu-manager ryu/app/simple_switch.py ryu/app/ofctl_rest.py

Mininet

Mininet creates a realistic OpenFlow network, running real kernel, switch and application code, on a single machine (VM, cloud or native), in seconds, with a single command

sudo mn --topo single,3 --mac --switch ovsk --controller remote

sudo ovs-ofctl -O OpenFlow13 dump-flows s1

sudo ovs-vsctl show

Postman

Postman is a most popular HTTP Request composer that makes it easy to call web services.

Search postman firefox in google. There will be a link for Firefox addon.

Install that link and open the window.

You will get a window similar to this

Postman

To add a flow in the switch

http://127.0.0.1:8080/stats/flowentry/add{

"dpid": 1,

"cookie": 42,

"priority": 45000,

"match": {

"in_port": 3

},

"actions": []

}

Postman

To add a flow in the switch

http://127.0.0.1:8080/stats/flowentry/delete_strict{

"dpid": 1,

"actions": [],

"idle_timeout": 0,

"cookie": 42,

"hard_timeout": 0,

"priority": 45000,

"table_id": 0,

"match": {

"in_port": 3

}

}

Thank you