network virtualization & software-defined networking

SDN & NFV IntroductionOpen Source Data Center Networking

Thomas Graf <tgraf@redhat.com>Red Hat, Inc.

Spring, 2014

Agenda

● Problem Statement– Networking Challenges

● Path to resolution– Software Defined Networking, Network

Virtualization, NFV & Service Chaining

● What about Code?– OpenDaylight, Open vSwitch, OpenStack

● Look Ahead– Group Based Policy Abstraction

Problem Statement:Networking Challenges

She can't take much

more of this, captain!

Managing Forwarding Elements

● Vendor specific management tools● Little automation● Slow and error prone

DeveloperNetOps

Service Ticket

1d – 2 weeks

CLI

VendorUI

Change in Traffic Patterns

● Increased demand for bisectional traffic● Limited room for additional costs

5%

95%

80% by 2014*

20%

* Gartner Synergy Report

Dynamic Workloads

● Virtualization (Live Migration)& Cloud● Respond in real time

– Services are started/stopped dynamically, network needs to adapt.

● Bring Your Own Device

Hypervisor Hypervisor

VMVM

Live Migration

Debugging

Debugging complex networks is hard

Cost per Core

Network Definition

● Collection of endpoints and forwarding elements

● Responsible for moving packets between hosts● Source hosts identify destination● Forwarding elements direct traffic at each

intersection

Classic Forwarding Device

Data / Forwarding PlaneFabric, Flow Table, Forwarding Engine

Data / Forwarding PlaneFabric, Flow Table, Forwarding Engine

Control PlaneForwarding Decision (Learning, RIB Lookup),

Routing Protocols (OSPF, BGP, ...)

Control PlaneForwarding Decision (Learning, RIB Lookup),

Routing Protocols (OSPF, BGP, ...)

Management interfaceCLI, Console, SNMP, ...

Management interfaceCLI, Console, SNMP, ...

Path to Resolution:Software Defined

Networking

Software Defined Networking

In the Software Defined Networking architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications.

Software-Defined Networking:The New Norm for Networks

ONF White PaperApril 13, 2012

SDN – Abstraction

Controller

App App AppSNMPVendor Specific Protocol

Control Plane

Data Plane

A logically centralized controller programs the networkbased on a global view.

Control Plane

Data Plane

Control Plane

Data Plane

Console

Control Plane

Data PlaneData Plane

Data Plane

Data Plane

Data Plane

“We've taken over the network”

James HamiltonVP, Amazon Web Services

Nov, 2013

What Really Matters● Closed Source

● Network Engineer

● Vendor Lead

● CLIs

● Network Appliances

● Open Source

● Network Developer

● Community Driven

● APIs

● NFV (Software)

Open Source Defines SDN

SDN Promises

● Highly automated & dynamically provisioned● Enables innovation, experimentation &

optimizations● Virtualizes network & abstracts the hardware● Makes the network programmable● Enables overlays with control at edges

OpenFlow

Match on bits in packet header L2-L4 plus meta data

Execute actions● Forward to port● Drop● Send to

controller● Mangle packet

2.2.An Open Standard behind SDN

OpenFlow enables networks to evolve, by giving a remote controller the power to modify the behavior of network devices, through a well-defined "forwarding instruction set". The growing OpenFlow ecosystem now includes routers, switches, virtual switches, and access points from a range of vendors.

ONF Website

11..

Programmable Flow Table● Extensive flow matching capabilities:

– Layer 1 – Tunnel ID, In Port, QoS priority, skb mark

– Layer 2 – MAC address, VLAN ID, Ethernet type

– Layer 3 – IPv4/IPv6 fields, ARP

– Layer 4 – TCP/UDP, ICMP, ND● One or more actions:

– Output to port (port range, flood, mirror)

– Discard, Resubmit to table x

– Packet Mangling (Push/Pop VLAN header, TOS, ...)

– Send to controller, Learn

Is it production ready?

Google claims 95% network utilization!

Path to Resolution:Network Virtualization

Network VirtualizationWhat do we need?

1. Virtualize network topology on Layer 2-7- Run previous workload without changes

2. Decouple logical from physical topology- A virtual network should run anywhere

3. Allow for isolated tentant networks- Multiple customers/applications per network

4. Provide APIs to manage network abstraction- Orchestrate & automate

Naive VLAN Mapping

Switch

Compute Node

vSwitch

VM1

Compute Node

VM2 VM3

vSwitch

VLAN 2

Switch

Switch

Switch

VM1

Compute Node

VM2 VM3

vSwitch

VLAN 3

VM1 VM2 VM3

VLAN 1

Max 4096 VLANs

VLAN Trunking

Compute Node

VM1

vSwitch

Compute Node

vSwitch

Compute Node

vSwitch

VM1VM1 VM2VM2VM2 VM3VM3VM3

Switch

Switch

Switch

Switch

Max 4096 VLANs

Network Overlay

Compute Node

VM1

vSwitch

Compute Node

vSwitch

Compute Node

vSwitch

VM1VM1 VM2VM2VM2 VM3VM3VM3

Switch

Switch

Switch

Switch

Encapsulation

Stateless

VXLAN, NVGRE, Geneve, GUE, LISP, STT, ..

Stateful

VPN, L2TP, SSH, ...

VXLAN Encapsulation

Network Abstraction

VM

VM

VM

VM

VM

VM

VM

VM

VM

Switch

Switch

Switch

Switch

Switch Switch SwitchLogical

Physical

NFV & Service Chaining

NFVProblem Statement

● Non commodity hardware● Physical install per appliance per site● Large development barriers● Innovation constraints & limited competition

NFVWhat do we want?

1. Virtualization– Run functions on scaleable commodity hardware

2. Abstraction– Limited dependency on physical layer

3. Programmability– APIs to implement automation

4. Orchestration– Centralized orchestration

– Reduced maintenance

NFV

Who is behind NFV?

● Originally operator driven– ETSI – European Telecommunications Standards

Institute

● Evolved into a generic concept● Open to any company

Service Chaining

Moving network functions into software means that building a service chain no longer requires acquiring hardware.

Build your ownOpen Source Data Center

OpenDaylight’s mission is to facilitate a community-led, industry-supported open source platform, including

code and architecture, to accelerate adoption of Software-Defined Networking and Network Functions

Virtualization.

Framework

Controller(Open Daylight)

Controller(Open Daylight)

OpenFlow / OVSDBOpenFlow / OVSDB

VM VM

Open vSwitch is a virtual multi layer switch for hypervisors providing network connectivity to virtual machines.

VM VM

Switch Switch

Switch Switch

Open vSwitch● Apache License (User Space), GPL (Kernel)

● Extensive flow table programming capabilities

● OpenFlow 1.1+ (1.1, 1.2, 1.3, extensions)

● Designed to manage overlay networks

● VLAN, VXLAN, GRE, LISP, ...● Remote management protocol (OVSDB)

● Monitoring capabilities

L2 Segregation (VLAN)

VM1

Host system

VM2 VM3

Open vSwitch

VLAN 1 VLAN 2

VLAN isolation enforces VLAN membership ofa VM without the knowledge of the guest itself.

vSwitchvSwitch

Virtual Machine

RemoveVLAN header

AddVLAN header

# ovs-vsctl add-port ovsbr port2 tag=10

Overlay Networks

VM1

Compute Node 1

VM2 VM3

Open vSwitch

VM4

Compute Node 2

VM5 VM6

Open vSwitch

ControllerController

Open

Flow

OVSDB

Open Flow

OVSD

B

Tunnel

VNET 1 VNET 1VNET 2 VNET 2

Tunneling provides isolation and reducesdependencies on the physical network.

NetworkNetwork

Visibility

●

● NetFlow

● Port Mirroring

● SPAN

● RSPAN

● ERSPAN

Supports industry standard technology tomonitor the use of a network.

FeatureQuality of Service

● Uses existing Traffic Control Layer

● Policer (Ingress rate limiter)● HTB, HFSC (Egress traffic classes)

● Controller (Open Flow) can select Traffic Class

VM1

Compute Node

VM2

ovsbr

VLAN 10

port1 port2

1mbit

# ovs-vsctl set Interface port2 \ ingress_policing_rate=1000

To produce the ubiquitous open source cloud computing platform that will meet the needs of public and private cloud providers

regardless of size, by being simple to implement and massively scalable.

OpenStack Architecture

Overlay Networks with OpenStack Neutron and Open vSwitch

A1

Compute Node 1

br-in

t

B1

br-t

un

A2

Compute Node 2

br-in

t

B2

br-t

un

A3

Compute Node C3

br-t

unB3

br-in

t

Compute Node 3

br-t

unB3

br-in

t

Network Node

DHCP

br-t

un

L3

br-e

x

VXLAN

VXLAN

br-in

t

C3

VID 11 ↔ VNI 1VID 49 ↔ VNI 13

Group BasedPolicy Abstraction

Network APIs are there.Now what?

Applications do not care about subnets, ports, or virtual networks.

Application Centric APIs

Allow application administrators to express networking requirements using group and policy

abstraction.

Leave the technical implementation to the network.

Terminology

Connectivity Group: Collection of endpoints (MAC/IP on vNIC) with a common policy.

Policy: Set of Policy Rule objects describing policy. Policies may be applied between groups, or alternatively, applied to a single group using provide / consume relations.

Policy Rule: Specific <classifier, action> pair, part of a policy.

– Classifier: L4 ports + protocol

– Actions: Permit / Deny, QoS action, service chain redirection

Policy as a Service

● Group is providing service as defined by policy

● Service mostly unaware of consumer

Policy between Groups

● Policy defined between pair of groups● Policy may apply to multiple relationships● Producer is aware of consumer

Example:Policy between Groups

Questions

ReferencesOpendaylight

– http://www.opendaylight.org/

Open vSwitch

– http://www.openvswitch.org/

OpenFlow

– http://www.openflow.org/

Open Networking Foundation

– http://www.opennetworking.org/

Inter-Datacenter WAN with centralized TE using SDN and OpenFlow [Google]

– http://bit.ly/18zgPE3

Red Hat OpenStack

– http://www.redhat.com/openstack/

OpenStack

– http://www.openstack.org/

Backup

Open vSwitchDeep Dive

Flow Table

VM

User space

Slow Path

Physical Interface

Kernel Fast Path

Controller programs flow table in the slow path thatfeeds the flow table in the fast path upon request.

tap

VM VM VM

tap tap tap

Open vSwitch

OpenFlow

Architecture

ovsdbvswitchd

Datapath

OpenFlow

Kernel

Userspace

Management

ovs-vsctl

Flow Table

ovs-dpctl

upcall

Netlink

sFlow

To DeviceFrom Device

Promiscuous Mode

reinject

1

2

(3)

4

5

6

7

Packet Processing

Management Workflow

ovsdb-tool

ovs-ofctl

Flow Table Rules● Flow matching capabilities

● Meta – Tunnel ID, In Port, QoS priority, skb mark● Layer 2 – MAC address, VLAN ID, Ethernet type● Layer 3 – IPv4/IPv6 fields, ARP● Layer 4 – TCP/UDP, ICMP, ND

● Possible chain of actions

● Output to port (port range, flood, mirror)● Discard, Resubmit to table x● Packet Mangling (Push/Pop VLAN header, TTL,NAT, ...)● Send to controller, Learn

Modifying the Flow Table

# ovs-ofctl add-flow ovsbr \ dl_src=11:22:33:44:55:66,actions=strip_vlan,output:1

# ovs-ofctl dump-flows ovsbr[...] cookie=0x0, duration=36.24s, table=0, n_packets=0, n_bytes=0, idle_age=36, dl_src=11:22:33:44:55:66 actions=strip_vlan,output:1

Strip VLAN header of all packets from MAC address11:22:33:44:55:66 and forward packet to port 1.

Megaflows

● Fast path made capable of handling wildcard flows

● Transparent optimization

in_port=3src_mac=02:80:37:ec:02:00,dst_mac=0a:e0:5a:43:b6:a1,

vlan=10,eth_type=0x0800

ip_src=10.10.1.1,ip_dst=10.10.1.2,

tcp_src=80,tcp_dst=32990,

...

in_port=3,src_mac=02:80:37:ec:02:00,dst_mac=0a:e0:5a:43:b6:a1,

vlan=10

Multi Threading

CPUCore 1

NIC

CPUCore 2

CPU Core 3

ovs-vswitchd

CPUCore 1

NIC

CPUCore 2

CPUCore 3

OVS OVS OVS

● Multiqueue NICs spread load across all cores

● Maps kernel NIC Queue => CPU core mapping to user space

● Allows slow path to scale across cores

Examples

Defining a Switch & Ports

# service openvswitch start# ovs-vsctl add-br ovsbr# ovs-vsctl add-port ovsbr port1

Creating a new virtual switch “ovsbr” with port “vm1”

# ovs-vsctl show7c68e54f-1618-41f4-bd16-2fd781488266 Bridge ovsbr Port ovsbr Interface ovsbr type: internal Port "port1" Interface "port1" ovs_version: "1.7.3"

VM1

Compute Node

ovsbr

port1

Using Red Hat ifcfg-

TYPE=OVSBridgeDEVICE=ovsbrONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-ovsbr

TYPE=OVSIntPortOVS_BRIDGE=ovsbrDEVICE=port1ONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-port1

# ifup port1

VM1

Compute Node

ovsbr

port1

<interface type='bridge'> <source bridge='ovsbr'/> <virtualport type='openvswitch' /></interface>

... with libvirt

TYPE=OVSBridgeDEVICE=ovsbrONBOOT=yes

/etc/sysconfig/network-scripts/ifcfg-ovsbr

virsh# edit <domain>

Start VM and it just works!

VM1

Compute Node

ovsbr

UUID

VLAN Isolation

# ovs-vsctl add-port ovsbr port2 tag=10

VM1

Compute Node

VM2

ovsbr

VLAN 10

port1 port2

Traffic Shaping

# ovs-vsctl set Interface port2 ingress_policing_rate=1000

Limit all traffic received from VM onport port2 to 1Mbit/s VM1

Virtual Host

VM2

ovsbr

VLAN 10

port1 port2

1mbit