Introduction to OpenFlow

Copyright © 2014 World Wide Technology, Inc. All rights reserved.

Software-Defined Networking Introduction to OpenFlow

Joel W. King Technical Solutions Architect Enterprise Networking Solutions Engineering and Innovations

Agenda

• History and Evolution of SDN / OpenFlow

• Controller Overview

• OpenFlow Switches

• Basic Operations & Messages

• Controller Northbound Interfaces

• Performance

• Debugging Tools

• Advanced Technology Center (ATC) OpenFlow Implementations

Abstract

• Learning Objectives • Understand the history and important terms associated with SDN

• Identify various SDN controllers and their target deployments

• Articulate the components and communication paths in the topology

• Learn the basic OpenFlow specifications, functions and messages

• Become familiar with the northbound interface of a controller

• Examine basic troubleshooting methodologies

• Gain insight on how WWT is implementing OpenFlow in the ATC

• Goal • A the completion of this class the student will have a working knowledge of

OpenFlow and it’s implementation

History and Evolution of SDN / OpenFlow

Historical view of SDN

• Purist view of SDN has two characteristics (*) • Control plane is separated from

device implementing data plane, • Single control plane manages

multiple network devices • SDN / OpenFlow initial

deployments were network research at universities – (Stanford ) providing a cost effective and ‘clean slate’ network architectures.

• OpenFlow is only one instantiation of SDN principles.

• SDN is a tool to enable a higher degree of control over network devices.

Control Plane

(1) The Road to SDN: An Intellectual History of Programmable Networks

What is OpenFlow?

• A Standard managed by the Open Networking Foundation (ONF)

• Originated at Stanford University 2005 - 2009 - Martin Casado, et al.

• https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf

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









What is OpenFlow?

• OpenFlow is simply a forwarding table management protocol.

• An OpenFlow Switch consists of:

• a flow table,

• which performs packet lookup and forwarding,

• and a secure channel to an external controller.

• Flow Table

• flow entries (header values to match packets against),

• activity counters,

• A set of actions to apply to matching packets.

• If no forward actions are present, the packet is dropped.

OpenFlow Switch Specification – version 1.0

Basic Building Blocks: Controllers and Agents

Some network functionality is better implemented from centralized coordination of all the devices in the network domain.

• Controller – process on a server interacting with network devices using APIs / protocols.

• Agent – process on network devices implementing a specific function.

• API – allow applications external to the controller to query and change the network configuration

app

Controller Overview

OpenFlow has Two Components

• OpenFlow Controller

• Controllers one or more switches

• Formulates Flows

• Programs switches

• Applications may run in the same address space as the controller

• Directives may come from external applications via REST API

• OpenFlow Switch

• OpenFlow agent runs on switch to communicate with the controller

• Processes commands from controller to populate the flow table

OpenFlow Controllers

Variety of Controllers

• NOX / POX

• Ryu

• Floodlight

• OpenDaylight

• Pyretic

• Frenetic

• Procera

• RouteFlow

• Trema

Considerations

• Programming Language

• Performance

• Learning Curve

• User base and support

• Focus

• Southbound API support

• Northbound API

• Production, Education, Research?

SDN Controllers

• NOX - NOX was the first OpenFlow controller. It has been the basis for many and various research projects in the early exploration of the SDN space

• POX -POX is a Python-only version of NOX that provides controller functionality within a rapid prototyping environment.

• Floodlight - Floodlight Open SDN Controller is an enterprise-class, Apache-licensed, Java-based OpenFlow Controller. It is supported by a community of developers including a number of engineers from Big Switch Networks.

• OpenDaylight is a collaborative, open source project to advance Software-Defined Networking (SDN). OpenDaylight is a community-led, open, industry-supported framework…

Controller Summary

NOX POX Ryu Floodlight ODL OpenDaylight

Language C++ Python Python JAVA JAVA

Performance Fast Slow Slow Fast Fast

Distributed No No Yes Yes Yes

OpenFlow 1.0 / 1.3 1.0 1.0 to 1.4 1.0 1.0 / 1.3

Learning Curve

Moderate Easy Moderate Steep Steep

Research, experimentation, demonstrations

Open source Python controller

Maintained Big Switch Networks

Vendor App support

Source: Georgia Tech SDN Class

Key Take-a-ways

• OpenFlow has two main components: Controller and Switch.

• OpenDaylight considered the leading open source SDN controller.

• OpenFlow is an example of an imperative model, the controller provides specific instructions to the switch.

• OpFlex is a declarative model, an alternative to OpenFlow, that transfers abstract policy to a set of “smart” devices.

• By contrast, OpenFlow transfers flow elements to “dumb” devices.

• Applications can run in the same address space as the controller, or communicate via a northbound API

OpenFlow Switches

Switch Data Plane

• Data plane of an OpenFlow switch is composed of :

• Ports,

• Flow tables,

• Flows,

• Match (classifiers)

• Modifiers and actions.

• Packets are matched to flows in flow tables using the match / classifiers.

• Flows contain sets of modifiers and actions which are applied to each packet that it matches.

Switch

RX - Ports

TX - Ports

Action

Match

Action

Match

Action

Match

Packet

Packet

Flow Table Components

Match Action Statistics

Ingress Port

Ether Type

Eth Dest

Eth Source

VLAN ID

VLAN Pri

IP Src

addr

IP Dest addr

IP Proto

col

ToS byte

L4-Src

Port

L4-Dst Port

Forward packet to port(s) Encapsulate and forward to controller Drop packet Send to normal processing pipeline Modify Fields

Packet | Byte Counters

Each Flow Table Entry contains: Match, Action and Counters

Layers-1 to 4

Flows can be Specific or General

• Also described as • ‘microflow’ verses ‘aggregated’

• ‘fine’ verses ‘course’

• Flow matching can be very specific or very general • Fine is TCP port 80 for a /32 IP address

• Course is matching on ingress port

• Matches can be on Layer-1 thru Layer-4 fields • Input Port (L-1)

• Ethernet (L2-Data),

• IP (L3-Network), - can be subnet masked

• Transport Protocol and TCP/UDP ports (L4-Transport).

Flexibility in Matching

• The ability to match on Layer-1 through Layer-4 allows the switch to behave like a variety of network devices

Ingress Port

Ether Type

Eth Dest

Eth Source

VLAN ID

VLAN Pri

IP Src addr

IP Dest addr

IP Protoc

ol

ToS byte

L4-Src Port

L4-Dst Port

SWITCH FLOW SWITCHING ROUTER FIREWALL

Action

Port 6

Port 6

Port 6

Drop

Actions

• A switch is not required to support all action types.

• When the switch connects to the controller, it specifies what actions it supports.

• Example: the Nexus 3048 supports

• OUTPUT

• SET_VLAN_VID

• STRIP_VLAN

• SET_DL_SRC

• SET_DL_DST

NEX-3048-E# show openflow sw 1 Logical Switch Context Id: 1 Switch type: Forwarding Pipeline id: 201 Signal version: Openflow 1.0 ... OFA Description: Manufacturer: Cisco Systems, Inc. Hardware: N3K-C3048TP-1GE V01 Software: 6.0(2)U2(2) of_agent 1.1.0 Serial Num: FOC1749R090 DP Description: NEX-3048-E:sw1 OF Features: DPID:0001e4c722dc4c80 Number of tables:1 Number of buffers:256 Capabilities: FLOW_STATS TABLE_STATS PORT_STATS Actions: OUTPUT SET_VLAN_VID STRIP_VLAN SET_DL_SRC SET_DL_DST

OpenFlow Protocol Overview

• OpenFlow protocol supports three message types • Controller-to-switch – initiated by controller and may not require a response.

• Asynchronous – switch sends to controller without controller requesting

• Symmetric – sent by either controller or switch without being requested

• Controller-to-switch • Feature Request

• Configuration

• Modify state- used to add / delete / modify flows on the switch

• Asynchronous • Packet-in

• Flow removed

• Symmetric • Hello

• Echo

Flow Element Priorities

• Packets are matched against flow entries based on prioritization.

• Entries with an exact match (no wildcards) match first.

• All wildcard entries have a priority associated with them.

• Higher numbers have higher match priorities.

• Cisco Nexus switches implement flow elements as ACLs, priority establishes order NEX-3048-D# show openflow sw 1 flows summary

Logical Switch Id: 1

Switch flow count: 12

NEX-3048-D# show ip access-list onep-acl-5

IPV4 ACL onep-acl-5

statistics per-entry

268169216 permit ip any any ethertype 0x800 ingress-intf 436391936 redirect 0x1a000000 priority 65 [match=0]

268169217 permit tcp any eq www any ethertype 0x800 ingress-intf 436207616 redirect 0x1a001000,0x1a02f000 priority 65 [match=34755]

268169218 permit tcp any any eq www ethertype 0x800 ingress-intf 436211712 redirect 0x1a000000,0x1a02f000 priority 65 [match=46567]

268169219 permit tcp any any eq 443 ethertype 0x800 ingress-intf 436211712 redirect 0x1a000000,0x1a02f000 priority 65 [match=110]

268169220 permit tcp any eq 443 any ethertype 0x800 ingress-intf 436207616 redirect 0x1a001000,0x1a02f000 priority 65 [match=0]

268173312 permit ip any any ethertype 0x88cc ingress-intf 436207616 redirect 0x1a001000 priority 64 [match=23275]

268173313 permit ip any any ethertype 0x88cc ingress-intf 436211712 redirect 0x1a000000 priority 64 [match=23275]





2147483647 deny ip any any priority -1 [match=0]

NEX-3048-D#

Hybrid Network (Switch)

• A Hybrid Network has both traditional switches and SDN switches operating in the same topology.

• Switches could be physically separate or hybrid switches.

• Hybrid network can exist in the same switch chassis, e.g. Ships-in-the-Night

• Ships-in-the-Night: Ports are designated as OpenFlow ports, remainder of the port operate under control of the switch operating system.

openflow switch 1 pipeline 201 controller ipv4 10.255.138.76 port 6633 vrf management security none of-port interface ethernet1/1 of-port interface ethernet1/2 of-port interface ethernet1/43 of-port interface ethernet1/44 of-port interface ethernet1/45 of-port interface ethernet1/46 of-port interface ethernet1/47 of-port interface ethernet1/48

interface Ethernet1/2 description OF: nex-3048-c ip port access-group onep-acl-7 in no lldp transmit switchport mode trunk spanning-tree bpdufilter enable mode openflow interface Ethernet1/3 shutdown no switchport

OF

NX-OS

Hard and Idle Timeouts

• Each Flow Entry contains an optional Idle and Hard Timeout field

• If no packets have matched within the Idle Timeout or

• The flow was inserted more than the Hard Timeout,

• Switch removes entry and sends flow removed message.

• The controller can instruct the controller to remove flows regardless of the timeouts.

• The timeouts are optional

OpenFlow Switches

QuantaMesh 3000 Series T3048-LY2 Cisco Nexus 3048

Quanta

QAU-3048-A> show version UBoot Version: U-Boot 2010.12 (Oct 09 2013 - 09:12:45) Manufacturer: Quanta Model: LY2 Platform: powerpc-quanta-ly2-r0 Description: Quanta LY2 (powerpc-quanta-ly2-r0) System Information: Card Type: 1 Hardware Version: 196608 Label Version: 1 MAC Address: 08:9e:01:f8:59:84 Manufactured Date: Fri, 18 Oct 2013 00:00:00 +0000 Model: QUANTA LY2 Part Number: 1LY2BZZ000R Product Name: LY2 Serial Number: QTFCEA3440003 Software Version: 61953 … Software Image Version: SwitchLight 2.1.1 Internal Build Version: (powerpc.release,qct,2014.05.07.15.58,...) Uptime is 66 days, 4:02:52 Load average: 0.06 0.10 0.13 Memory: 1751832 kB of 2073048 kB free

QAU-3048-A> show datapath datapath: id 00:00:5c:16:c7:1a:ec:72 description QUA-3048-A QAU-3048-A> show controller 10.255.138.11:6653 CONNECTED EQUAL QAU-3048-A> show flowtable summary table id 0 table name L2 Table max entries 131008 active entries 0 lookup count - matched count - table id 1 table name Full Match Table max entries 1020 active entries 0 lookup count 7363784235 matched count 0

QAU-3048-A> show flowtable <cr> detail Show detailed flow table dst-ip Filter on destination IP dst-ip6 Filter on destination IPv6 dst-mac Filter on destination MAC in-port Filter on input port out-port Filter on output port src-ip Filter on source IP src-ip6 Filter on source IPv6 src-mac Filter on source MAC summary Show the flow table summary table-id Filter on table identifier vlan-id Filter on VLAN identifier

Node Information

Cisco Nexus 3048 | OpenFlow switch

nex-3048-a# show openflow sw 1 Logical Switch Context Id: 1 Switch type: Forwarding Pipeline id: 201 Signal version: Openflow 1.0 Data plane: secure Table-Miss default: NONE Config state: no-shutdown Working state: enabled Rate limit (packet per second): 0 Burst limit: 0 Max backoff (sec): 8 Probe interval (sec): 5 TLS local trustpoint name: not configured TLS remote trustpoint name: not configured Stats coll. period (sec): 5 Logging flow changes: Enabled

OFA Description: Manufacturer: Cisco Systems, Inc. Hardware: N3K-C3048TP-1GE V00 Software: 6.0(2)U2(2) of_agent 1.1.2 Serial Num: FOC1524ZZPR DP Description: nex-3048-a:sw1 OF Features: DPID:0001547fee0298f0 Number of tables:1 Number of buffers:256 Capabilities: FLOW_STATS TABLE_STATS PORT_STATS Actions: OUTPUT SET_VLAN_VID STRIP_VLAN SET_DL_SRC SET_DL_DST Controllers: 10.255.40.207:6633, Protocol: TCP, VRF: management Interfaces: Ethernet1/45 Ethernet1/46

Key Take-a-ways

• OpenFlow is a protocol to manage a switch forwarding table from a central controller.

• Ingress packers are matched against Layer-1 to Layer-4 headers

• Some action is specified, e.g. Output, Drop, Strip VLAN header

• Each Flow element maintains counters of bytes and packets.

• OpenFlow is an example of an imperative model, the controller provides specific instructions to the switch, match conditions and actions.

Basic Operations & Messages

Lab Environment

• OpenFlow protocol examples are illustrated with:

• Cisco Extensible Network Controller (XNC) SDN controller running in a VM at WWT’s Advanced Technology Center.

• Mininet: network emulation platform. Mininet creates a virtual OpenFlow network. (http://openflow.org/mininet)

• Oracle VM VirtualBox: virtualization product for enterprise as well as home use. ( https://www.virtualbox.org )

• Quanta: QuantaMesh 3000 Series: whitebox switches

• Nexus 3000 series: hybrid OpenFlow and Layer2 switches

• Wireshark: network protocol analyzer for Unix and Windows.

http://openflow.org/mininet



https://www.virtualbox.org/





Logical Topology

Cisco XNC controller

Mininet Ubuntu Linux Open vSwitch

Windows Laptop

Nexus 3000

Quanta

ip.addr == 10.255.40.207 and tcp.port == 6633

Mininet Invocation

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

• Created 3 virtual hosts, each with a separate IP address.

• Created a single OpenFlow software switch in the kernel with 3 ports.

• Connected each virtual host to the switch with a virtual ethernet cable.

• Set the MAC address of each host equal to its IP.

• Configure the OpenFlow switch to connect to a remote controller.

Mininet Logical Topology

virtual hosts

controller

Mininet Virtual Machine

OpenFlow switch

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

S1

H1 10.0.0.1 H2

10.0.0.2

H3 10.0.0.3

C0 10.255.40.207

*** Creating network

*** Adding controller

*** Adding hosts:

h1 h2 h3

*** Adding switches:

s1

*** Adding links:

(h1, s1) (h2, s1) (h3, s1)

*** Configuring hosts

h1 h2 h3

*** Starting controller

*** Starting 1 switches

s1

*** Starting CLI:

mininet>

Mininet Brief Intro

• nodes

• net

• xterm h1

mininet> net h1 h1-eth0:s1-eth1 h2 h2-eth0:s1-eth2 h3 h3-eth0:s1-eth3 s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:h3-eth0 C0

mininet> nodes available nodes are: c0 h1 h2 h3 s1

OpenFlow Switch Start-up

virtual hosts

controller


OpenFlow switch

S1

H1 10.0.0.1 H2

10.0.0.2

H3 10.0.0.3

C0 10.255.40.207

TCP 6633 (deprecated) TCP 6653

TCP 3-way handshake

HELLO (version number)

HELLO (version number)

FEATURES REQUEST

FEATURES REPLY DPID # buffers # tables capabilities actions port details

SET CONFIG send flow expirations

GET CONFIG REQUEST

GET CONFIG REPLY

FLOW MOD

PACKET_IN no matching flow entry and default action: send to controller

ECHO REPLY

ECHO REQ

PACKET_OUT (LLDP)

TCP 3-way handshake

HELLO

FEATURES REQUEST / REPLY

GET CONFIG REQUEST / REPLY

FLOW MOD

PACKET_IN OUT

Keep Alive(s)

• To verify connectivity between OpenFlow switches and the controller, the switch sends ECHO_REQUESTs to the controller.

• The controller responds with an ECHO_REPLY using the unmodified data field provided by the switch

OpenFlow Switch Start-up

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

• Controller has these flows:

• Input port 1 – EtherType 0x800 – Action= Output port 3

• Input port 3 - EtherType 0x800 – Action= Output port 1

• Input port 1 – EtherType 0x806 – Action= Output port 3

• Input port 3 - EtherType 0x806 – Action= Output port 1

• Wireshark with this filter: ip.addr == 10.255.40.207 and tcp.port == 6633

# Dictionary of valid Ethertypes, used to map between a name and the hex value

#

self.valid_EtherTypes = {"IPv4":"0x0800","ARP":"0x0806","IPv6":"0x86DD", \

"LLDP":"0x88CC","IE23":"0x05FF","EFC":"0x8808", \

"IE1Q":"0x8100","SNMP":"0x814C","MPLu":"0x8847", \

"MPLm":"0x8848",None:None}

Validate Connectivity

mininet> mininet> h1 ping h3 PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data. 64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=1.34 ms 64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.053 ms 64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.048 ms 64 bytes from 10.0.0.3: icmp_req=4 ttl=64 time=0.052 ms 64 bytes from 10.0.0.3: icmp_req=5 ttl=64 time=0.046 ms 64 bytes from 10.0.0.3: icmp_req=6 ttl=64 time=0.049 ms ^C --- 10.0.0.3 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5000ms rtt min/avg/max/mdev = 0.046/0.265/1.344/0.482 ms mininet> iperf h1 h3 *** Iperf: testing TCP bandwidth between h1 and h3 waiting for iperf to start up...*** Results: ['2.26 Gbits/sec', '2.26 Gbits/sec'] mininet> h1 ping h2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

Incorporating Host H2

• Hosts H1 and H3 can communicate because we have pushed flows for ARP and IPv4 between ports 1 and 3.

• We will delete the existing flow elements and add static flow elements to flood ARP and IPv4 across all ports.

• Rather than use the controller, we will do this programmatically.

• Run ‘staticflows.bat’

virtual hosts

controller


OpenFlow switch

S1

H1 10.0.0.1 H2

10.0.0.2

H3 10.0.0.3

C0 10.255.40.207

Flow Pusher

• Running staticflows.bat

• Executes Python program using REST API calls to controller

• Uses controller northbound interface to push flows

• Packets from each input port are flooded to output ports

• IPv4 and ARP

>python sst.py --help usage: sst.py [-h] --cact CACT --cip CIP --cuid CUID --cpw CPW --dpid DPID --fname FNAME --act ACT --pri PRI [--et ET] [--nwsrc NWSRC] [--nwdst NWDST] [--proto PROTO] [--tpsrc TPSRC] [--tpdst TPDST] [--iport IPORT] [--debug] Copyright (c) 2014 World Wide Technology, Inc. optional arguments: -h, --help show this help message and exit --cact CACT Controller action, (eg. PUT, DELETE, LIST) a flow element --cip CIP Controller IP / Hostname --cuid CUID Controller username --cpw CPW Controller password --dpid DPID Data Path Identifier of the OpenFlow switch --fname FNAME Flow name, unique identifier --act ACT Action(s) to implement, eg. DROP, OUTPUT= --pri PRI Flow priority, higher numbers have more precedence --et ET Ethertype, eg. IPv4, IPv6. --nwsrc NWSRC Source IP address --nwdst NWDST Destination IP address --proto PROTO Protocol, eg. tcp, udp --tpsrc TPSRC transport protocol source port --tpdst TPDST transport protocol destination port --iport IPORT Ingress OpenFlow port number on the switch --debug When specified enables debugging

Flow Details

• Each program execution includes the

• controller IP address

• userid and password

• Action ‘put’

• DPID of the switch

• And the specifics of each flow

python sst.py --cact put --cip 10.255.40.207 --cuid admin --cpw admin --dpid 00:00:00:00:00:00:00:01

--fname ARP_1 --pri 64 --et ARP --iport 1 --act OUTPUT=2,OUTPUT=3 --fname ARP_2 --pri 64 --et ARP --iport 2 --act OUTPUT=1,OUTPUT=3 --fname ARP_3 --pri 64 --et ARP --iport 3 --act OUTPUT=1,OUTPUT=2 --fname IPv4_1 --pri 64 --et IPv4 --iport 1 --act OUTPUT=2,OUTPUT=3 --fname IPv4_2 --pri 64 --et IPv4 --iport 2 --act OUTPUT=1,OUTPUT=3 --fname IPv4_3 --pri 64 --et IPv4 --iport 3 --act OUTPUT=1,OUTPUT=2

Note the matches and multiple actions!

Flow Modification Messages

• The controller sends FLOW_MOD messages to the switch to implement the Flows into the Flow Table.

• The controller also sends BARRIER_REQUESTS

Barrier Messages

• Barrier Messages are used by the controller to verify that the switch has processed the flow modifications successfully.

• The switch will process the flow modifications and send a barrier reply to acknowledge the action to the controller.

• A common transaction ID is used to identify the exchange.

controller

OpenFlow switch

S1

C0 10.255.40.207

FLOW MOD

BARRIER REQUEST

BARRIER REPLY

Transaction ID: 900829717



Repeated until all FLOWs have been pushed to the switch

Verification

virtual hosts

controller


OpenFlow switch

S1

H1 10.0.0.1 H2

10.0.0.2

H3 10.0.0.3

C0 10.255.40.207

mininet> pingall *** Ping: testing ping reachability h1 -> h2 h3 h2 -> h1 h3 h3 -> h1 h2 *** Results: 0% dropped (6/6 received) mininet>

Remove Flows using GUI of Controller

controller

OpenFlow switch

S1

FLOW MOD

BARRIER REQUEST

BARRIER REPLY


Repeated until all FLOWs have been removed from the switch



FLOW REMOVED

What have we created?

• We have used brute force methods to create a hub – flooding ARP and IPv4 packets to the three ports on our switch.

• Using a combination of the controller GUI and REST API calls, we have implemented static flows to provide initial connectivity between ports 1 and 3

• Additionally we have flooded ARP and IPv4 traffic between all ports- 1, 2, and 3

• Implementing logic in a controller itself, e.g. POX, we can code functions such as

• Layer-2 MAC learning switch

• Stateless Load Balancers

• Layer-2 / Layer-3 stateless firewalls

• Campus Slicing

Want to learn more?

https://www.coursera.org/course/sdn

Reference: OpenFlow Messages

• We have examined OpenFlow messages between switch and controller

• Additional Reference material is available at:

• http://flowgrammable.org/sdn/openflow/message-layer/

Proactive vs. Reactive Flow Insertion

Reactive

• First packet of flow is sent to controller for processing.

• Controller evaluates packet and sends Flow message to switch insert a flow table entry for the packet.

• Subsequent packets (in flow) match the entry until idle or hard timeout.

• Loss of connectivity between switch and controller limit utility of switch.

Proactive

• Controller pre-populates flow table in switch.

• Zero set-up time for new flows

• Loss of connection between switch and controller does not disrupt network traffic.

• Switch in Proactive forwarding ‘only’ would default to action=drop

• Northbound REST API used to populate proactive flows

Proactive vs Reactive flow insertion

Proactive flow instantiation

• Controller populates flow elements in the switch before packets arrive

• Proactive flows eliminates any latency induced by consulting a controller on every flow.

Proactive vs Reactive flow insertion

Reactive flow instantiation • If no match flow element is available and the default configuration is to send to

controller

• Switch creates an OpenFlow PACKET_IN, encapsulates the packet, and sends to controller

• Controller evaluates packet, can inject flow elements for this and subsequent packets

Proactive Forwarding Only

• Operation Mode ‘Proactive forwarding only’

• Configure Subnet Gateway

• Add ports to the Gateway

• Three flows are configured on the switch • __Catch-All Drop__

• __Punt LLDP__

• __Punt ARP__

• ARP and LLDP punted to controller

• Everything else dropped

Proactive Forwarding only

Key Take-a-ways

• Mininet creates a virtual network running OpenFlow switches and hosts

• Allows you to develop, share, and experiment with OpenFlow.

• Mininet can be run with an external controller or a POX controller in the same VM.

• Wireshark can be used to examine the OpenFlow channel between controller and switch.

• We have demonstrated how to create static flows with the GUI of the controller and programmatically with Python and the REST API.

• Examined the difference between proactive and reactive flows.

Controller Northbound Interfaces

Northbound Protocols

• Northbound application programming interface (API) on a SDN controller enables applications and orchestration systems to program the network and request services.

• Provides a network abstraction interface to applications

• The abstraction is important when managing dissimilar network elements, e.g. Cisco IOS, NX-OS, IOS-XR

API

controller

agent

agent

APP

Northbound Protocol Examples

• REST (web based) API – applications which run on different machine or address space on the controller

• HTTP PUT, GET, POST, DELETE • URL • Body • Authentication • Content Type (XML or JSON)

• Web Browser • http://<controller ip>:8080/……

• OSGi framework is used for applications that will run in the same address space as the controller.

Controller Web Interface

REST API Documentation developer.cisco.com

Tools: cURL

• A command line tool for getting or sending files using URL syntax.

• curl -u admin:foo http://10.255.40.207:8080/controller/nb/v2/topology/default

• cURL called with the proper URI, sends commands or queries to an OpenFlow controller – command line version of REST API

• Example: Returns a list of all Flow Statistics from all the Nodes.

curl -u admin:admin http://10.255.40.207:8080/controller/nb/v2/statistics/default/flow

{"flowStatistics":[{"node":{"id":"00:00:00:00:00:00:00:01","type":"OF"},"flowStatistic":[{"flow":{"match":{"matchField":[{"value":"OF|1@OF|00:00:00:00:00:00:00:01","

Tools: Postman

Python REST API

• DreamPie is an interactive Python shell used for program development.

• Python module XNC is a objected oriented class to abstract the REST API to the controller

• This example illustrates how the methods of the XNC module can be used to instruct the controller to save the running configuration.

• Enabling the debug option displays the URL sent to the controller

Key Take-a-ways

• The northbound application programming interface (API) enables applications to program the network and request services from it.

• The northbound API presents a network abstraction to applications.

• In the next 5 years, most all network devices will be managed through a controller and the northbound interface.

• While the controller’s GUI, web interface, is a northbound interface, the real value is implementing orchestration systems to manage the network.

Performance

Considerations

• Controller selection

• Reactive vs Proactive

• Granularity of Flows

• Number of Flows supported by the switch

• Performance of the Switch

Controller Scalability

• Determine scalability of the Cisco Extensible Network Controller – version 1.7 (OpenDaylight) for Matrix switching deployment.

• Test program • Query the controller to determine all switches registered

• For each switch, create ‘n’ number of flows

• When all switches populated, delete the flows from each switch

• Calculate the average time to create / delete flows per switch

• Validation:

• Issue a REST call to verify the number of flows created and deleted

• View the flows on the Controller GUI (WEB) interface

• Test program uses the same underlying program as is called from QualiSystems Testshell

Controller Scalability - Results

• Total Number of Flows in this test is 9,600

FlowMax.py Mon Nov 10 11:40:07 2014

switch flowcount ave.time(ms) action

QUA-K07 640 321 PUT

QUA-K09 640 325 PUT

QUA-K20 640 330 PUT

QUA-K08 640 325 PUT

QUA-K17 640 321 PUT

QUA-K11-B 640 339 PUT

QUA-K16 640 322 PUT

QUA-K14 640 331 PUT

QUA-K11-A 640 322 PUT

QUA-K18 640 324 PUT

QUA-3048-A 640 333 PUT

QUA-K13 640 326 PUT

QUA-K21 640 330 PUT

QUA-K12 640 329 PUT

QUA-K22 640 330 PUT

switch flowcount ave.time(ms) action

QUA-K07 640 323 DELETE





QUA-K11-B 640 320 DELETE



QUA-K11-A 640 325 DELETE


QUA-3048-A 640 315 DELETE





Totals

30 9600

Port Details: Counters

Performance Metrics Quanta OpenFlow: Layer-1 Matrix Switch

• IXIA appliance is configured with the ‘Cut Through Latency’ test, line rate, in a bi-directional mode.

• The ports in the test are using the same 10Gigabit Cisco SFP-10G-SR optics on all devices

• The worst case latency for the OpenFlow switch is 8.58 microseconds or 0.0085 milliseconds.

MTU Setting Latency in nanoseconds

MIN / AVE / MAX

Baseline 64 0 / 3 / 10 ns

NetScout ONPATH 64 120 / 131 / 140 ns

OF Switch 64 1,130 / 1,180 / 1,290 ns

Baseline 1518 0 / 1 / 10 ns


OF Switch 1518 2,280 / 2,339 / 2,460 ns

Baseline 9200 0 / 3 / 10 ns


OF Switch 9200 8,430 / 8,475 / 8,580 ns

SDN / OpenFlow test solutions from Ixia

• IxNetwork and IxANVL products providing functional, performance, scale and conformance testing for OpenFlow.

• IxNetwork supports OpenFlow emulation.

• Can be used to generate traffic and act as a controller to Device Under Test (DUT)

• Supports capture of protocol exchanges

• IxANVL is for OpenFlow conformance testing.

https://www.youtube.com/watch?v=fwmInHmDdHU

Debugging Tools

Debugging

• Debugging should focus on the basics

• Reachability between the management interface of the switches and the controller

• Controller software is running

• Firewalls not blocking connectivity to controller northbound REST Interface

• Consistency of flows on the switch and controller

• Enable flow modification logging on the switch

• Examine the flows which exist on the switch and compare to the controller.

• When all else fails, verify your Layer-1 connectivity

Flow Modification Logging

• Logging of Flow Modifications is a useful troubleshooting tool

2014 Mar 28 18:31:56 nex-3048-b %VMAN-5- : LOG: OVS: sw1<->tcp:10.255.138.76:6633%management: no response to inactivity probe after 5 seconds, disconnecting 2014 Mar 28 18:32:17 nex-3048-b %VMAN-5- : LOG: OVS: sw1<->tcp:10.255.138.76:6633%management: connected 2014 Mar 28 18:32:18 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,in_port=43,dl_type=0x05ff Actions: output:44 2014 Mar 28 18:32:18 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,in_port=43,dl_type=0x88cc Actions: output:44 2014 Mar 28 18:32:18 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,in_port=45,dl_type=0x8100 Actions: output:46 2014 Mar 28 18:32:18 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,in_port=44,dl_type=0x8100 Actions: output:43 2014 Mar 28 18:32:20 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,in_port=46,dl_type=0x8100 Actions: output:45 2014 Mar 28 18:32:20 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,in_port=43,dl_type=0x8808 Actions: output:44 2014 Mar 28 18:32:20 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,ipv6,in_port=45 Actions: output:46 2014 Mar 28 18:32:20 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,in_port=44,dl_type=0x05ff Actions: output:43 2014 Mar 28 18:32:22 nex-3048-b %VMAN-5- : LOG: OVS: Flow deleted: Rule: priority=64,arp,in_port=45 Actions: output:46

openflow switch 1 logging flow-mod

Verify Controller Operation

• In the case of XNC, there is a config.ini file which specifies operational parameters.

• Use netstat –an to verify the controller is listening on the appropriate ports

• Use cURL to verify connectivity to the GUI interfaces of the controller

• Verify connectivity to the console

# Open Flow related system parameters # TCP port on which the controller is listening (default 6633) of.listenPort=6633 # IP address of the controller (default: wild card) # of.address = 127.0.0.1 # The time (in milliseconds) the controller will wait for a response after sending a Barrier Request … of.messageResponseTimer=60000

curl http://10.255.138.76:8080 curl -k https://10.255.138.76:8443

ssh -p 2400 [email protected]

Controller Logging

• Determine what log files the controller uses

• Log files can be used to verify connectivity issues between switches and controller

cisco@X-SDN-Controller:~/XNC15/xnc/logs$ ls -salt

total 936

132 -rw-rw-r-- 1 cisco cisco 127450 Nov 6 10:38 xnc.log

108 -rw-r--r-- 1 root root 103757 Nov 5 14:23 web_access_log_2014-11.txt

4 drwxrwxrwx 12 cisco cisco 4096 Nov 3 15:55 ..

2014-11-06 10:38:20.010 EST [SwitchEvent Thread] INFO o.o.c.p.o.core.internal.Controller - Switch:10.7.18.94:56420 SWID:00:00:00:00:00:00:00:01 is removed 2014-11-06 10:38:21.939 EST [ControllerI/O Thread] INFO o.o.c.p.o.core.internal.Controller - Switch:10.7.18.94:56422 is connected to the Controller

SDN Analyzer Tab

• Allows you to download packet capture (PCAP) files from the controller to your PC.

• Select the Controller management interface

nex-3048-a is 10.255.40.87

Flow Check Tab

• View Inconsistent Controller Flows

• View Inconsistent Node Flows

Advanced Technology Center (ATC) OpenFlow Implementations

Layer-1 Matrix Switch

Security-Defined Routing

Advanced Technology Center

Tech Briefings Workshops Sandbox Environments Proof of Concepts

Demonstrations Training Product Testing Early Field Trials

Pilots and Integration Lab as a Service

Layer-1 Matrix Switch

• Layer 1 Switching Matrix

• Based on “true” Layer 1 Switch

• OpenFlow switches and SDN controller in concert expand port density at a lower cost

• Both L1 and OpenFlow can be used simultaneously

• Integration with Qualisystems Cloudshell Lab Automation system

• Develop driver for interaction with SDN controller with the same functionality as a driver for layer 1 switch.

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OpenFlow TOR

Switch

OnPathLayer 1

Agg Switch

IXIA Traffic Generation Anue

Impairment

Logical Topology

OpenFlow

SDN Driver L1 Driver

SDN Extensible Network Controller (XNC)

Logical Connectivity

Aggregation / spine

Top of Rack

ATC Resources

Layer 1

OpenFlow

OpenFlow

Activate Topology

Flow Overview – XNC Controller

• Match on Input Port, Output port

• Bi-directional, there is a second flow with the values reversed

• Priority 64

• Ethertype not specified

QUANTA-LB9 Show commands

QUANTA-LB9# show int

* = Link up, D = Disabled

# Name Speed Rx Packets Tx Packets

1* ethernet1 1G 67841 2890 +Errors

2* ethernet2 1G 80008 67480 +Errors

QUANTA-LB9# show datapath

datapath:

id 00:00:5c:16:c7:1a:ec:71

description QUANTA-LB9

QUANTA-LB9# show flowtable

Prio InP Dest Mac Src Mac DstIP

SrcIP Output Packets Duration

64 1 - - -

- 2 799 866

64 2 - - -

- 1 386 865

Security-Defined Routing

SDR Solution includes the following components:

• An SDN controller

• OpenFlow switches between WAN edge routers and a corporate firewalls

• Security-Defined Routing (SDR) software developed by World Wide Technology (WWT)

• Security analytics software • Cisco Sourcefire

• RSA Security Analytics

• Open Source Snort

NEXUS-7K

Internal network Internal network SDN Controller

w/ Security-Defined Routing software

syslog

Internet

DMZ

OpenFlow switch

Monitoring Network

Security-Defined Routing Demonstration Video

• Slides are posted at http://www.slideshare.net/joelwking/security-defined-routingcybergamutv11

• Watch the video to see how security-defined routing combines cyber analytics and SDN to protect the network:

• http://youtu.be/KvZuklmi9uU

http://www.slideshare.net/joelwking/security-defined-routingcybergamutv11





http://youtu.be/KvZuklmi9uU

http://youtu.be/KvZuklmi9uU

Summary

Summary

• OpenFlow is only one instantiation of SDN principles.

• It is only one tool to enable more flexibility in programming the network.

• OpenFlow is simply a protocol to communicate and manipulate a switch configuration state and receiving switch events.

• What you create with this tool is most important. Think of use cases.

• The WWT definition of Software-Defined Networking is

A flexible, programmatic framework to optimize the delivery and management of network services.

• Program the Network!

• Network provisioning and configuration will increasingly become less chassis-by-chassis more controller based

• Network resources will align with business requirements through application resource profiles and network containers.

• Brush up on your programming skills!

Looking Forward

http://marketing.wwt.com/SDNGuide_Registration.html

Introduction to OpenFlow

Technology

openflow joel

basic openflow specifications

working knowledge of

external controller

controller directives

various sdn controllers

network research

network functionality