Upload
joel-king
View
1.430
Download
11
Tags:
Embed Size (px)
Citation preview
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
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]
268173314 permit ip any any ethertype 0x806 ingress-intf 436207616 redirect 0x1a001000 priority 64 [match=46]
268173315 permit ip any any ethertype 0x806 ingress-intf 436211712 redirect 0x1a000000 priority 64 [match=46]
268173316 permit ip any any ethertype 0x800 ingress-intf 436207616 redirect 0x1a001000 priority 64 [match=175594]
268173317 permit ip any any ethertype 0x800 ingress-intf 436211712 redirect 0x1a000000 priority 64 [match=175626]
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.
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
Mininet Virtual Machine
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
Mininet Virtual Machine
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
Transaction ID: 900829717
Transaction ID: 900829717
Repeated until all FLOWs have been pushed to the switch
Verification
virtual hosts
controller
Mininet Virtual Machine
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
Transaction ID: 900830426
Repeated until all FLOWs have been removed from the switch
Transaction ID: 900830426
Transaction ID: 900830426
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-K09 640 318 DELETE
QUA-K20 640 327 DELETE
QUA-K08 640 321 DELETE
QUA-K17 640 319 DELETE
QUA-K11-B 640 320 DELETE
QUA-K16 640 322 DELETE
QUA-K14 640 318 DELETE
QUA-K11-A 640 325 DELETE
QUA-K18 640 317 DELETE
QUA-3048-A 640 315 DELETE
QUA-K13 640 316 DELETE
QUA-K21 640 317 DELETE
QUA-K12 640 320 DELETE
QUA-K22 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
NetScout ONPATH 1518 120 / 128 / 140 ns
OF Switch 1518 2,280 / 2,339 / 2,460 ns
Baseline 9200 0 / 3 / 10 ns
NetScout ONPATH 9200 120 / 131 / 140 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
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