Upload
kingston-smiler
View
248
Download
2
Embed Size (px)
Citation preview
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
Anatomy of SDN Controllers
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
Topology Discovery Operations
OpenFlow Discovery Protocol
• Other switches receive packets and report packet-in to controller.
• Controller learns topology from information about incoming ports
Topology Discovery Operations
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
– Keep the controller close to the switch network.
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
– Keep the controller close to the switch network.
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