sdn mini-bootcamp - mirantis · how sdn protocols such as openflow work and how that relates to...

Copyright © 2017 Mirantis, Inc. All rights reserved

training.mirantis.com

SDN Mini-Bootcamp

Webinar February 23, 2017


Grzegorz Pawelski

Senior Technical Instructor, Mirantis

● Engineer's degree in software and computer architecture ● 15+ years of experience as a systems engineer at IBM, AT&T and

Nokia● Expertise in areas of IP networking, IT security, mobile networking,

virtualization and telco cloud● Mirantis’ instructor of OpenStack, Kubernetes & Docker, and SDN

Speaker Bio


A Little Housekeeping

● Please submit questions in the Questions pane.

● We’ll provide a link where you can download the slides at the end of the webcast.


Agenda

● Traditional networking

● Software Defined Networking (SDN)

● SDN protocols – OpenFlow – Open Virtual Switch (OVS) - Open Virtual Network (OVN)

● SDN in Cloud Data Centers


When we're finished here

You'll understand…

● The very basics of traditional networking as relevant to SDN

● What Software Defined Networking (SDN) is and why it's useful

● The basic concepts of SDN

● How SDN protocols such as OpenFlow work and how that relates to your own networks

● What SDN means for cloud data centers


Traditional networking


A few basics

● MAC addresses● L2● L3● etc


Host 3

KernelSpace

App C

NIC

1.2.3.4 : 80

Host 2

KernelSpace

App B

NIC

1.2.3.3 : 333

Switching as L2 control plane

ARP: who-has 1.2.3.4?

Host 1

KernelSpace

App A

NIC

1.2.3.0 :111

Host 2

KernelSpace

App B

NIC

1.2.3.3 :333

Host 4

KernelSpace

App D

NIC

6.7.8.9 : 555

1.2.3.4 is-at 52:54:00:12:35:02

Host 3

KernelSpace

App C

NIC

1.2.3.4 : 80

Flood learning


OSPFAREA 1

OSPFAREA 0 (Backbone Area)

OSPFAREA 2

AS4

AS3

AS1

Routing as L3 control plane

eBGP AS1-AS2

AS2

BGP

eBGP AS1-AS3

eBGP AS1-AS4

iBGP AS1

ABR

OSPF

R5

R3

R1

R6

R4

ABR

R2

Internet

ASBR



● Network traffic is split into packets

● Packet headers contain instructions for devices

● Every device is configured independently

● Extensions to packet header allow to encapsulate one traffic flow into another


Traditional router


Traditional router – control plane - routing


Traditional router – routing and datapath interaction


Traditional router - forwarding


Traditional router – management plane


Limitations of traditional networks

● Manual configuration of devices doesn’t satisfy Cloud’s agility requirement

● No single view/control of networking policies / configuration

● Too many protocols to know, and non-standardized management

● Many errors are due to conflicting configurations in the network

● Configurations are detached from business requirements

● Localized control plane leads to inefficient data plane


Software Defined Networking (SDN)


SDN Controller – control plane decoupled


SDN – SouthBound protocols


SDN – SouthBound protocol examples


SDN application - embedded


SDN application – external and NorthBound protocols


SDN application example: OpenStack


SDN networking


White Box

White Box

SDN – full picture

Controller

Host A

Host B

White Box

White Box


Benefits of separate control plane

● All control is from a single place

● Policies are centralized, no more conflicting policies○ can become close to business language

● Data Plane can be dumb, if all logic is on a controller

● Quick deployment of network-related changes○ as you don’t need to change hardware

● Event-based reconfiguration becomes possible○ Re-route based on throughput○ Rebalance traffic when link fails


SDN architecture

OpenStack Kubernetes SDN apps

Contrail ONOS ODL

Data Planes

vRouter Open vSwitch Cisco ACI

XMPPOpenFlow

OpFlexP4

NetConf

NO established standard


SouthBound SDN protocol OpenFlow


OpenFlow

● The first (2008) standard of interaction between Controller and Forwarding plane

● Can also be called a Southbound API

● Latest spec - 1.5.1, March 2015

● Remains as the most well known protocol

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf


Components of OpenFlow switch

OpenFlow Switch

TLS-secured sessions of OpenFlow

MeterTable

Ingress Port

Ingress Port

Flow Table

Flow Table

Output Port

Output Port

Group Tables

Flow Table

... ...

Processing pipeline

ControllerController


Packet flow in details12 : … : f1 11 : … : ff 0x0800 2.3.4.5 1.2.3.4 UDP 123 124

Field Ingress port

MACdst

MACsrc

Eth type VLAN ID IP src IP dst IP proto TCP/UDP src

TCP/UDP dst

Actions

Match * 55 : ... : 55 * * * * * * * * Output 3

Match * * * 0x0800 * * * TCP * 22 Drop

Match * * * * * * 1.2.3.* * * * Group1

Flow Table 0 (simplified)

22: … : 88 12 : … : f1 0x8100 2 2.3.4.5 1.2.3.4 UDP 123 124

Field Actions

1 1. Push tag VLAN=22. Normal output4

Group Table (simplified)

Egress Flow Table(s) for port 4

port 4

Outgoingpacket

IncomingPacket

Outgoing Packet


Processing

Packet flow overview

Ingress Port

Group Table

Flow Table

Actions ...IncomingPacket

Processing

Flow Table

ActionsFlow Table

Actions

Flow Table

ActionsFlow Table

Actions... Output Port

Outgoing Packet


Actions defined by OpenFlow

Some of the actions (total 11)

● Push-Tag / Pop-Tag <ethertype> (MPLS, VLAN, etc.)● Change-TTL (hop count, etc.)● Set-Field - modify fields of packet header● Set-Queue - apply quality of service related actions● Group - send to specified group● Output - send to specified output port or all ports● not specified == drop

There are also reserved ports that can have their own forwarding rules.


What if connection to controllers is lost?

Spec 1.0:

● “Emergency mode”. Reset all TCP connections. Use only specified emergency

flow tables, all normal flows are deleted.

Spec 1.1 and further - two choices:

● “Fail secure mode” - continue to work, but don’t send packets to controller

● “Fail standalone mode” - act as legacy Ethernet switch/router


OpenFlow limitations

● Can’t introduce new protocols easily

● Can’t specify flexible rules, e.g. masks on fields or ranges

● Doesn’t cover generation of packets, e.g.:

● ICMP when hop count reaches 0● ICMP for MTU negotiation


What is Open vSwitch (OVS)


What is Open Virtual Network (OVN)?

● L2/L3 virtual networking for Open vSwitch● Logical switches and routers● Security groups (faster than with iptables)

● Works on same platforms as OVS● Linux (KVM and XEN)● Containers● DPDK

● Vendor-neutral, Apache2 license● Developed by the same community as Open vSwitch● Replaces Neutron’s implementation of OVS agent, L3 agent, DHCP agent,

Iptables-based security groups


SDN in Cloud Data Centers


Network in the cloud – it should provide:

● L2 VM-VM connectivity● L2 VM-BMS connectivity● L3 VM-VM connectivity (intra and inter network/subnet)● L3 VM-External network (e.g. Internet) connectivity● that might require NATing● tenant/networks separation● independent IPAM● support for overlapping IP ranges● traffic (stateful) filtering to protect VM from unwanted traffic● service chaining - sending traffic through a chain of VMs - policy based

routing


at the same time they want:

● to reduce broadcast domains and traffic flooding● VM mobility - so VM can be moved or started on any compute node without changing

IP address and default gateway● both intra and inter network/subnet traffic should be optimally forwarded● without so called hair-pinning or tromboning● all data center network links should be efficiently utilized● possibly separating mice and elephant traffic● and avoiding congestion

● and I want a pony


With traditional networking solutions:

● for VM mobility build large L2 networks, spanning across the whole data center, but then

● you have large broadcast domains and traffic flooding

● and you cannot have more than 4096 VLANs (separate L3 networks)

so● to reduce broadcast domains and flooding use (interconnected) L3 networks,

but then

● you don’t have VM mobility - VM needs to change its IP and default gw, when it moves to different segment


Overlay SDN enforces packet processing and path selection at VMs endpoints (virtual switches on compute nodes), and traffic is tunneled through the rest of network to other endpoints.

“Regular” SDN enforces packet processing and path selection at every point of the network.

Use SDN, overlay SDN


SDN100 Bootcamp

● 2-day live, instructor led course

● Includes 70/30 lecture & labs

● Regular Price: $1,995

● First class: May 15 - 16

○ Sunnyvale, CA or Virtual (Americas)○ Special price: $1,000

Software Defined Networking (SDN100)


Register for any training before March 31, 2017 to receive a 15% discount

During registration use discount code: webinar15off

Complete schedule:

training.mirantis.com

Special Offer for Webinar Attendees

http://training.mirantis.com/

http://training.mirantis.com/


Thank you

Download the slides from: bit.ly/sdn-mini-bootcamp-slides

We will send you the slides and recording next week.

sdn mini-bootcamp - mirantis · how sdn protocols such as openflow work and how that relates to...

Documents