A Typical Hybrid OpenFlow Deployment and Configuration
Dell Networking – OpenFlow Technical Brief
A peek at a hybrid enabled OpenFlow deployment
Dell Networking – Data Center Technical Marketing
May 2015
A Dell Technical White Paper
Revisions (required)
Date
May 2015
Nov 2015
Dec 2015
Description
Initial release – Mario Chow
Added comments from Jaiwant Virk
Added comments from EMEA team
THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS
AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED
WARRANTIES OF ANY KIND.
© 2013 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.
Dell, the DELL logo, and the DELL badge are trademarks of Dell Inc. Symantec, NetBackup, and Backup Exec are trademarks of
Symantec Corporation in the U.S. and other countries. Microsoft, Windows, and Windows Server are registered trademarks of
Microsoft Corporation in the United States and/or other countries. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims any proprietary interest in the marks and names of others.
2 Dell Networking – OpenFlow Technical Brief
Table of contents
3 Dell Networking – OpenFlow Technical Brief
Introduction
Network automation has become a vital feature for scaling up network operations. The need is driven by a two major factors which are requirement for rapid changes in the network and optimization of time of network architects and administrators. Among many different technologies used for network automation, OpenFlow is one that is most powerful and flexible technologies right now for a lot of reasons.
This paper could be used as both a reference and a guide for planners and architects to understand the functioning of the OpenFlow and how it could be used. In this paper we intend to discuss the use cases of OpenFlow in the
Enterprise IT network.
Let’s discuss three merits of OpenFlow in the light of Enterprise users.
First, its powerful for it can program hardware more granularly and directly than other methods that automate the manual process of CLI or other scripting
Its flexible because the use cases can be quite diverse with technology being at the bottom of hardware programmability ..
Third, OpenFlow is a widely adopted standard. Almost any major networking vendor of hardware and software is likely to support this.
The
Today’s networking building blocks are being challenged by the new concept defined as Software Defined
Networking or SDN. The idea behind SDN revolves around the notion of dis-aggregating the control plane, and data plane of a networking device – typically a switch (Layer 2) or router (Layer 3).
This dis-aggregation has lead the industry into somewhat of an unknown territory but has kept just enough degree of familiarity allowing for similarities to be drawn between the x86 server market space prior to virtualization and this new networking approach.
Prior to virtualization, a single server based on the x86 architecture …
SDN consists of three tiers (see figure 1):
1.
Application Tier – this tier consists of all the different applications the run on top of this new SDN network. They could be ip load balancing, firewall, security (IDS, IPS), WAAS, etc.
2.
Controller Tier – this tier consist of the SDN controller providing all the centralized smart decisions as it relates to data forwarding using a new set of forwarding decisions.
3.
Data plane Tier – and finally, the data plane using a completely new standard based communication protocol between the hardware (switches, routers) and controller tier. This new communication protocol is called “ OpenFlow ” and it is this protocol that holds, binds this new networking concept of SDN.
Figure 1 SDN Framework
4 Dell Networking – OpenFlow Technical Brief
5
Objective
The following technical brief is intended for both internal and external consumption. It is written to provide a brief introduction into Dell’s Data Center Networking OpenFlow configuration while highlighting some common use cases. The following document should be used as a reference tool and initial Openflow discussions.
OpenFlow and its components
OpenFlow is the communication protocol stack used between the components (switch, router, and controller) that make up an SDN (Software Defined Networking) architecture.
This communication protocol runs between the physical devices and OpenFlow controller using either TLS
(Transport Layer Security) or an unprotected TCP port. This communication allows for direct access to and manipulation of the forwarding plane (networking device) and in turn results for a more granular control and programmability of the networking environment.
OpenFlow consists of the following components:
1.
Protocol messaging
2.
Flows
3.
Forwarding tables
Protocol Messaging
There are three types of protocol messages:
Controller-to-Switch – This type of message is sent by the controller to:
Specify, modify or delete flow definitions
Request information on switch capabilities
Retrieve information like counters from the switch
Send a packet back to a switch for processing after a new flow is created
Dell Networking – OpenFlow Technical Brief
6
Asynchronous – This type of message is sent by the switch to:
Send the controller a packet that does not match an existing flow
Inform the controller that a flow has been removed because its time to live parameter or inactivity time has expired
Inform the controller of a change in port status or that an error has occurred on the switch
Symmetric – This type of message is sent by both the switch or the controller to:
Exchange hello messages between controller and switch on startup
Echo messages between controller and switch to confirm bi-directional connection
Flows
The communication between the OF controller and switch/router define a specific flow. This flow contains a set of instructions that tells the switch what to do with a specific or set of packets that match such set of instructions. A flow has two categories: 1) Match and 2) Action, whereby if a packet matches the set of instructions a specific action is performed.
Prior to creating a flow , the OpenFlow controller and networking devices start exchanging basic information such as
OpenFlow enabled interfaces, port statistics, port status, and so on. This allows for the controller to obtain a holistic view or map of the OpenFlow enabled environment.
The first packet triggers the creation of the first flow . This flow is classified as a “ flow-miss ” indicating that no flow has been programmed into the switch’s forwarding table and thus a need the to punt such packet towards the controller. Once the controller receives this packet, it learns amongst many other parameters the source MAC address, switch ingress port, vlan ID – if any – and more. It then programs the switch’s forwarding table with a flow containing all the information aforementioned, the next packet is then simply switched without the controller’s involvement.
There are five type of flows defined in the OpenFlow standard:
1.
Layer 1 – Defined by two parameters (Ingress port, and Metadata)
2.
Layer 2 – Defined by five parameters (Ethernet source, Ethernet destination , Ethernet type, VLAN ID, and
VLAN priority)
3.
Layer 2.5
- Defined by two parameters (MPLS label, MPLS traffic class)
4.
Layer 3 – Defined by four parameters (IPv4 source, IPv4 destination, IPv4 protocol, and IPv4 ToS)
5.
Layer 4 – Defined by two parameters (TCP/UDP/SCTP source port, TCP/UDP/SCTP destination port)
Within each flow created by the controller there are two important sequence that take place that determines whether such flow is discarded, dropped, or punted towards the controller. A match condition tells the networking device what parameters to use within each flow before an action is triggered to make a final decision.
OpenFlow implementation on Dell Switches
Dell’s OpenFlow implementation supports three types of entries where each type of is stored into a separate forwarding table:
Controller Based/ACL Table
Layer 2 Table
Layer 3 Table
Dell Networking – OpenFlow Technical Brief
Each of these entries is used and programmed differently in the networking device. Dell’s implementation uses the
TCAM forwarding table space where ACL entries are by default programmed as ACL flows.
Any flow programmed by the controller is stored in this space unless it is specified by the controller to use a different table type in conjunction with certain features turned on at the openflow enabled device.
These flows are programmed by the controller into the respective tables using the Dell-OpenFlow extensions, however, not * all * controllers support these extensions. As a result, a default forwarding table is used; in this case the TCAM space. In order for the OpenFlow controllers to understand these extensions an additional configuration step is needed. Through the use of the command “ flow-map L2|L3 enable ” the controller understands whether a particular flow should be installed or programmed in the Layer2 or Layer 3 hardware based forwarding table. For detailed information on the command “ flow-map L2/L3 enable” please see the Ошибка! Источник ссылки не найден.
section.
A basic flow is defined by 12 different parameters from which a match condition is triggered by the openflow controller and then programmed into the switch’s respective forwarding table – see paragraph above. Table 3 captures these parameters.
Table 1 Flow parameters per Dell OpenFlow implementation
Parameter
Source MAC Address
Destination MAC Address
Source IP Address
Destination IP Address
Ethernet Type
Ingress Port
Destination Port
Source Port
IP Protocol
IP Type of Service (ToS)
VLAN ID
VLAN Priority
Controller Based Flow/ACL
There are two types of controller flows/entries: 1) controller installed , and 2) catch-all entries . By default, Dell switches configured as “openflow enabled” treat and store any flow into the internal TCAM space using the “ catchall ” entries. There are two types of internal catch-all entries used by openflow: 1) Default 2) Learning Bridge .
If an incoming packet does not match to any of the controller installed flows, the packet is punted to the controller via the openflow TCP session (OF_TCP). This session is configured as part of the openflow instance configuration on the switch.
The first type “Default” is used by all openflow instances configured on the switch. If an incoming packet does not match any of the Layer 2, Layer 3, and ACL flows, it will be forwarded to the switch CPU and then forwarded to the associated openflow controller.
These flows are treated as ACL flows and depending on the configuration of the TCAM space which can range between 4-8 block spaces, the number of flows supported by this space will range between 256-1,024 flows.
Because of the limited number of supported flows, additional forwarding tables (Layer 2 and Layer 3) are opened up by the implementation where the OF controller programs these flows in order to address scalability concerns. The
7 Dell Networking – OpenFlow Technical Brief
configuration of the TCAM space requires rebooting the switch. See the “Configuration” section for more details on how to configure these values.
The second entry type is not used and it will not be covered on this document.
Layer 2 Based Flow and programming
In order for Layer 2 flows to be programmed by the controller in the Layer 2 forwarding table, the following option needs to be configured under the openflow instance configuration “ flow-map L2 enable” (see “Device
Configuration”).
This type of flow is defined by two very distinct parameters: 1) DA MAC address, 2) VLAN ID tag. If a controller supports the creation of this type of flow
, then it will program the switch’s Layer 2 forwarding table making use of the switch’s ASIC forwarding capabilities achieving line-rate forwarding performance. Whenever the controller programs a Layer 2 flow in the forwarding table, the entry shows up as a static MAC entry.
Note: There are some controllers that do not support this functionality and instead use an ACL flow.
Layer 3 Based Flow and programming
Similar to Layer 2 flows, the same option needs to be configured under the openflow instance configuration. This type of flow is defined by three very distinct parameters: 1) Ethertype, 2) DA IP address, 3) DMAC.
Unlike Layer 2 flows, which use only one table (VLAN table) to install the relevant flows, Layer 3 flows use two tables: 1) Route and 2) ARP tables where Layer 3 flows are installed.
Note: Similar to Layer 2 flows, if a controller supports the creation of this type of flow , then these flows are programmed in the switch’s Layer 3 forwarding table.
Forwarding Tables
Every networking device usually has three forwarding tables: 1) TCAM (Ternary Content Addressable Memory), 2)
Layer 2, and 3) Layer 3. Each of these tables contain a specific type of flow programmed by the OF controller through the use of a specific table id. Dell’s openflow implementation uses the following table ids used by the openflow controller to specify the particular table where each flow is programmed.
Table 2 Dell OpenFlow Table ID values
Table Type
VLAN
MAC
Route (L3)
ACL
Value
10
20
30
40
A TCAM forwarding table consists of flows defined by several parameters including SA/DA MAC address, IP
SA/DA address, tcp port, Vlan id, ToS, CoS, etc. The size of this table is usually less than 1,000 flows and therefore it is not meant for a highly scalable deployment.
Table 3 Flow table size
S6000
CAM Entry
4 (ACL)
8 (ACL)
Layer 2
512
1,024
S4810
256
512
48,000
S4820T
256
512
48,000
S3048-ON
512
1,024
80,000
S4048-ON
512
1,024
160,000
Z9100
1,024
8 Dell Networking – OpenFlow Technical Brief
VLAN
LAG
Layer 3
500
50
6,000
500
50
6,000 16,000 128,000
The current OpenFlow implementation supports up to 64 separate openflow instances, where each instance can be configured to be part of a vlan, interface, or a combination of both. The following section talks about the different types of interfaces supported per instance.
Dell OpenFlow interface Type
Dell’s OpenFlow implementation supports three types of interfaces that allow the optimization of the IFP TCAM usage.
Port
The port option allows to customer to associate a single openflow instance to a single port. In this case, all packets tagged or untagged are accepted and forwarded using the flow entries programmed by the controller corresponding to the respective openflow instance to which the port has been associated.
Caution is recommended when using this option since the current implementation supports up to 64 individual instances. The potential of exceeding this number needs to be taken into account.
Sample Port configuration
Interface te0/3 no ip address
of-instance 5
Vlan
The second option is the vlan interface type. With this option, a single port can participate in multiple openflow instances. To accomplish this, the implementation associates an openflow instance to a vlan which in turn is associated with tagged or untagged port members.
This second option scales better in the sense that a single port is not limited to a single openflow instance.
Sample vlan configuration
Interface vlan 20 of-instance 2 no ip add tagged te0/2 no shut
!
Interface vlan 10 of-instance 3 no ip add tagged te0/2
!
Int te0/2
Swi no shut
Any
The third and final option places both an openflow interface and openflow vlan in a single instance. In this case 2 individual entries in the TCAM space is needed to accommodate the two (interface and vlan based) flows. Because
9 Dell Networking – OpenFlow Technical Brief
of the inefficient TCAM entry usage, it is recommended that this last option not be used unless absolutely indicated by the requirements.
The Dell Networking portfolio supports both Openflow version 1.0 and 1.3. Table 4 shows all the supported features as related to each OF version.
Table 4 OpenFlow Match table
Match Parameter
Ingress Port
Ethernet SA & DA (Source &
Destination Address)
Inner Ethertype
External VLAN ID
External VLAN priority
IP SA & DA
Openflow 1.0
Supported Values
N/A
MAC address (nn:nn:…) format
All supported IEEE values
0 – 4094
0 – 7
IP address (x.x.x.x/y) format with y as prefix length
Openflow 1.3
Supported Values
N/A
MAC address (nn:nn:…) format
All supported IEEE values
0 – 4094
0 – 7
IP address (x.x.x.x/y) format with y as prefix length
IP Protocol Type
ToS (Type of Service)
Transport source & destination port
ICMP type and code
SIP, Dynamic IP, ToS protocol
0 – 255
0 – 65535
0 – 255
SIP, Dynamic IP, ToS protocol
0 – 255
0 – 65535
0 – 255
Table 5, shows the supported actions between the different OF versions. These actions are implemented based on the matching conditions of the flow being programmed by the OF controller.
Table 5 OpenFlow 1.0 & 1.3 supported Flow actions
Openflow 1.0
Description
Flow Action
OFPAT_FLOOD or
OFPAT_ALL
OFPAT_CONTROLLER
OFPAT_out_port
OFPAT_DROP
Floods packets to all ports and vlans on the OF interface
Sends all NO MATCH or
ACTION packets to the controller specified by the packet’s VLAN tag
Displays a list of ports that can receive traffic
Drops all packets that match the specified criteria
MODIFY FIELD
MODIFY FIELD
MODIFY FIELD
MODIFY FIELD
OFPAT_ENQUEUE
Set VLAN ID
Set VLAN priority
Modify Ethernet SA & DA
(Source & DESTINATION
Address)
Modify Ipv4 ToS bits
Send the specified flow to the queue
OFPXMT12_OFB_ETH_TYPE Ethernet frame type
OFXMT12_OFB_VLAN_PCP VLAN priority
Openflow 1.0
Flow Action
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
NO
NO
Openflow 1.3
Flow Action
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
Supported
10 Dell Networking – OpenFlow Technical Brief
A Typical Hybrid OpenFlow Deployment and Configuration
Figure 2, illustrates a typical hybrid OpenFlow deployment where two OF (OpenFlow) enabled sites interconnect through a “ hybrid ” switch. This hybrid switch is configured with a mixture of traditional and OpenFlow switchports.
To the left and right side of the diagram, “ OpenFlow_Site_1 ” connects through the spine layer via ports 0/2 & 0/3, although the diagram shows only one physical link. These two ports have been configured to be part of an openflow instance, in this case “ openflow instance 1 ”.
In the center of the diagram, a non-OF deployment shows a basic use case where Layer 3 is deployed at the spine layer. Data from this non-OF site is directed upwards and then sent back down to simulate how the spine switches are performing a hybrid function, i.e. support for both openflow traffic and non-openflow traffic.
The OpenFlow controller communicates with all OF-enabled devices through the management subnet using the
OpenFlow protocol standard. For this particular test, the OF version used is 1.3
For redundancy, dual links are deployed between the spine and leaf switches. From an openflow perspective, a portchannel configuration is not needed between the leaf openflow enabled switchports and spine switch (Te0/2 &
Te0/3) see Figure 3.
Openflow is not subjected to the inherent spanning-tree limitations where links are blocked to prevent network loops. In an openflow deployment all links are enabled and forwarding achieving a full fabric link utilization.
In contrast, from a non-openflow perspective, in order to achieve high availability, VLT (Virtual Link Trunk) and standard port-channel configuration are needed at the spine and leaf layer respectively (see “ Non-OpenFlow Site ” figure 2). Through VLT, the spine switches are seen as a single virtual switch to the downstream leaf switch ( S55 switch ).
The switchports that are part of VLT and port-channel configurations are NOT openflow enabled and therefore the openflow controller has not visibility into these ports. As far as the openflow controller is concerned, it sees only figure 3’s topology.
The OF controller of choice for this particular technical brief document is NEC’s PFC (Programmable Flow
Controller 6800).
Through the use of OpenFlow, the controller programs all openflow enabled switchports and vlans with the correct forwarding entries on the switches configured as openflow enabled.
All aspects of all the flows covered in this document pertain only to NEC’s controller and no assumptions should be made with respect to any other different controller.
For this particular topology four Dell S4810s were used, out of which two S4810s were configured as a hybrid switch, i.e., openflow enabled switchports and legacy switchports.
Figure 2 Hybrid OpenFlow Deployment
11 Dell Networking – OpenFlow Technical Brief
Figure 3 OpenFlow topology and traffic flow as seen by the OF controller
Figure 3, shows the logical view and traffic flow (lines in green) as seen and programmed by the openflow controller. Notice how all links are in forwarding mode. Unlike a traditional network deployment where spanningtree would be needed to avoid network loops, openflow does not use spanning-tree. Network loop prevention is implemented by the openflow enabled controller where each controller creates an internal port forwarding map only visible to the controller.
With openflow, this capability not only does it provide link redundancy but it allows for flow programmability, i.e. two distinct flows can be programmed to use the respective interfaces simultaneously.
Device Configuration
12 Dell Networking – OpenFlow Technical Brief
Following is the applicable and detailed configuration explanation on all switches.
S4810_Spine_1#sh run hostname S4810_Spine_1
! cam-acl l2acl 2 ipv4acl 2 ipv6acl 0 ipv4qos 0 l2qos 1 l2pt 0 ipmacacl 0 vman-qos 0 ecfmacl 0 openflow 8
! cam-acl-vlan vlanopenflow 1 vlaniscsi 1
! interface TenGigabitEthernet 0/2
description link_2_174_4
no ip address
portmode hybrid
switchport
!
protocol lldp
advertise management-tlv management-address system-capabilities system-description system-name
advertise interface-port-desc
no shutdown
! interface TenGigabitEthernet 0/3
description link_2_174_4
no ip address
portmode hybrid
switchport
!
protocol lldp
advertise management-tlv management-address system-capabilities system-description system-name
advertise interface-port-desc
no shutdown
! interface Vlan 2 of-instance 1
description OF_management_network
no ip address
untagged TenGigabitEthernet 0/2-3
no shutdown
! interface Vlan 10 of-instance 1
description OF_data_network
no ip address
tagged TenGigabitEthernet 0/2-3
no shutdown
! interface Vlan 4094 of-instance 1
description VLAN_used_by_PFC_4_unicast
no ip address
tagged TenGigabitEthernet 0/2-3
no shutdown
!
openflow of-instance 1
controller 1 1.1.1.1 tcp
flow-map l3 enable
flow-map l2 enable
interface-type vlan
multiple-fwd-table enable
of-version 1.3
no shutdown
#1
#2
#3
#4
#5
Note: The sample configuration is for the spine switch. Notice Te0/0 is missing from the configuration. This is because at the spine switches, Te0/0 is not being used, however, at the leaf switches, Te0/0 is being used and therefore it should be included.
Part 1 – This is a mandatory cam-acl configuration piece. Once this configuration is entered, the switch MUST be restarted. There are two critical components highlighted in red. The vlan openflow configuration is 1. This is the
13 Dell Networking – OpenFlow Technical Brief
only value available for the vlan openflow block. The other component is the openflow block. For this setup, we have chosen 8. This translates into 512 total available ACL flows.
Part 2 – Vlan 2 is the untagged vlan created to carry all control packets such as LLDP between the openflow enabled switches and controller. The NEC OF controller process and expects control packets on an untagged vlan.
By attaching the participating OF switchports (Te0/0-3) to this untagged vlan, any LLDP packet that is generated by the NEC controller in order to implement neighbor link discovery can be processed or understood. This untagged vlan requirement is unique to this type of OF controller.
Part 3 – Vlan 10 is the user data traffic. It is the user data generated by the traffic generator. The leaf switch expects tagged vlan 10 traffic at Te0/0-3.
Part 4 – The NEC controller uses an internal private vlan used as a flow aggregator. This vlan is used to aggregate all flows from the leaf switch towards the spine switch. It is a required configuration and it is unique to the NEC OF controller. At the leaf switch, incoming vlan 10 traffic is remarked as 4094 as it egresses towards the spine switch.
This vlan (4094) is used ONLY by the spine switches as traffic is switched using this vlan ID.
The following outputs show the different flows programmed by the controller on the respective switches (Leaf_1 and Spine_1). It is not necessary to capture the flows programmed on Leaf_2 since they are identical to Leaf_1 and
Spine_2 is not being used to switch this pair of flows.
S4810_Leaf_1
Figure 4 shows a summary of the openflow instance running on the switch. It shows the status, openflow version, number of flows, overall packets per flow type and more.
Figure 4 Initial OpenFlow Instance information and actual flows with statistics
S4810_R5_R7_top_leaf(conf)#do sh openflow of-instance 1
Instance : 1
Admin State : Up
OF Version : V1-3 <<<<< The specific of version running on this instance
Interface Type : Vlan <<<<<< The openflow interface type. In this case vlan interface was configured
DP Id : 00:01:00:01:e8:8a:f1:c2
Forwarding Tbls : acl,mac,route <<<<<<<<< Here we see the three different tables available .
Flow map : l2,l3 <<<<<<<<< L2 and L3 tables enabled for programming flows into them.
EchoReq interval: 15 seconds
Connect interval: 15 seconds
Number of Flows : 14 (acl:12,mac:2 ) <<<<<< These are the number of flows programmed. Not all flows are used. We have two types of flows, ACL, and MAC
Packets (acl) : 2084492093
Bytes (acl) : 141745479116
Fail mode : secure
Flow misses : copy-to-controller <<<<<< Any flow that does not match the conditions for ACL, L2, or L3 parameters are copied to the controller.
Controller 1 : TCP, 1.1.1.1/6633, rcv/sndbuf 2000/2000, connected (equal) <<<< Only one controller is up.
Controller 2 : TCP, 2.2.2.2/6633, rcv/sndbuf 2000/2000, not-connected
Port List :
Vlan List :
Vl 2, Vl 10, Vl 20, Vl 4094 <<<<<< These are the vlans participating in the openflow environment.
Vlan Mbr list :
Te 0/0 (1), Te 0/2 (3), Te 0/3 (4 ) <<< These are the ports participating in the openflow environment.
S4810_leaf_1(conf)#
14 Dell Networking – OpenFlow Technical Brief
Figure 5 S4810_Leaf_1 active flows with statistics
Figure 5, show flows 3 & 15, where flow 15 is the flow programmed by the controller for incoming traffic at Te0/0 on Leaf_1. Notice how the matching parameters are port Te0/0, SMAC, DMAC, and vlan id 10. The actions match the output port Te0/2, and the interestingly the DMAC and vlan ID are completely different than what they came in as. The OF controller has programmed all incoming flows with a different vlan ID, DMAC, and outgoing port.
Flow 3 is the flow for all packets coming from Spine_1 towards Leaf_1. We know this because of the vlan ID being matched on (4094). The flow basically says that on any ingress port (denoted by the * character) facing spine_1 matching on vlan ID 4094 and DMAC (00:05) assign vlan ID 10, set the DMAC to 12:02, and send it out port
Te0/0.
The DMAC (00:05) is a unique DMAC used by Spine_1 switch that was programmed by the OF controller on
Leaf_2 as it was sent towards Spine_1 on Te0/3.
S4810_leaf_1(conf)# do show openflow flows of-instance 1
Instance: 1, Table: acl , Flow: 3 , Cookie: 0xc805808500000000
Priority: 24600, Internal Priority: 24600
Up Time: 3d 12:52:31, Hard Timeout: 0 seconds
Idle Timeout: 0 seconds, Internal Idle Timeout: 0 seconds
Packets: 434123993467, Bytes: 29520431557932
Match Parameters:
Valid Match: DMAC,Vid
In Port : * EType : *
SMAC : *
DMAC : 02:00:00:18:00:05 / ff:03:ff:ff:ff:ff
VLAN id : 4094 VLAN PCP : *
IP TOS : * IP proto : *
Src IP : * Dest IP : *
Src Port : * Dest Port : *
Actions:
Set VLAN id: 10
Set DMAC: 00:00:00:00:12:02
Output: Te 0/0
S4810_leaf_1(conf)# do show openflow flows of-instance 1
Instance: 1, Table: acl , Flow: 15 , Cookie: 0xc8075a190b1a1803
Priority: 25000, Internal Priority: 25000
Up Time: 3d 12:52:42, Hard Timeout: 0 seconds
Idle Timeout: 300 seconds, Internal Idle Timeout: 300 seconds
Packets: 434161017856, Bytes: 29522949216452
Match Parameters:
Valid Match: InPort,SMAC,DMAC,Vid
In Port : Te 0/0 EType : *
SMAC : 00:00:00:00:12:02 / ff:ff:ff:ff:ff:ff
DMAC : 00:00:00:00:12:01 / ff:ff:ff:ff:ff:ff
VLAN id : 10 VLAN PCP : *
IP TOS : * IP proto : *
Src IP : * Dest IP : *
Src Port : * Dest Port : *
Actions:
Set VLAN id: 4094
Set DMAC: 02:20:00:10:00:06
Output: Te 0/2
S4810_Spine_1
Figure 6 shows the two active flows that have been programmed by the NEC controller on one of the spine switches
(S4810_Spine_1). Spine_2 is not active in the switching of this flow pair (12:01
12:02) and therefore it does
by the spine switch to switch the traffic.
The DMACs being used are the DMACs that have been programmed by the OF controller as data traffic ingresses at the leaf switches, it is these DMACs that are used by the Leaf switches to match against and perform their respective actions.
Figure 6 Programmed flows at Spine_1
15 Dell Networking – OpenFlow Technical Brief
S4810_Spine_1# show openflow flows of-instance 1
Instance: 1, Table: acl, Flow: 7 , Cookie: 0xc804dca400000000
Priority: 24576, Internal Priority: 24576
Up Time: 3d 12:38:18, Hard Timeout: 0 seconds
Idle Timeout: 0 seconds, Internal Idle Timeout: 0 seconds
Packets: 432915939180, Bytes: 29438283866416
Match Parameters:
Valid Match: DMAC,Vid
In Port : * EType : *
SMAC : *
DMAC : 02:00:00:18:00:00 / ff:1f:ff:f8:00:00
VLAN id : 4094 VLAN PCP : *
IP TOS : * IP proto : *
Src IP : * Dest IP : *
Src Port : * Dest Port : *
Actions:
Output: Te 0/2
S4810_Spine_1# show openflow flows of-instance 1
Instance: 1, Table: acl, Flow: 8 , Cookie: 0xc804646800000000
Priority: 24576, Internal Priority: 24576
Up Time: 3d 12:38:19, Hard Timeout: 0 seconds
Idle Timeout: 0 seconds, Internal Idle Timeout: 0 seconds
Packets: 432916808710, Bytes: 29438342994456
Match Parameters:
Valid Match: DMAC,Vid
In Port : * EType : *
SMAC : *
DMAC : 02:00:00:10:00:00 / ff:1f:ff:f8:00:00
VLAN id : 4094 VLAN PCP : *
IP TOS : * IP proto : *
Src IP : * Dest IP : *
Src Port : * Dest Port : *
Actions:
Output: Te 0/3
S4810_R5_R8_top_core#
S4810_Leaf_2
At Leaf_2, flow 14 matches against packets coming in into Te0/0 and their respective parameters. The packets are then changed (vlan ID, DA MAC, and output port) and sent towards Spine_1.
Flow 4, on the other hand is the programmed flow for packets between Spine_1 and Leaf_2. Notice how it is
specific parameters expected as they (packets) go out Te0/0 and finally received by the ixia port.
Figure 7 Programmed flows at Leaf_2
S4810_Leaf_2# show openflow flows of-instance 1
Instance: 1, Table: acl, Flow: 4 , Cookie: 0xc805345f00000000
Priority: 24600, Internal Priority: 24600
Up Time: 3d 12:54:09, Hard Timeout: 0 seconds
Idle Timeout: 0 seconds, Internal Idle Timeout: 0 seconds
Packets: 434262075633, Bytes: 29529821145220
Match Parameters:
Valid Match: DMAC,Vid
In Port : * EType : *
SMAC : *
DMAC : 02:00:00:10:00:06 / ff:03:ff:ff:ff:ff
VLAN id : 4094 VLAN PCP : *
IP TOS : * IP proto : *
Src IP : * Dest IP : *
Src Port : * Dest Port : *
Actions:
Set VLAN id: 10
Set DMAC: 00:00:00:00:12:01
Output: Te 0/0
S4810_Leaf_2# show openflow flows of-instance 1
Instance: 1, Table: acl, Flow: 14 , Cookie: 0xc807f83f0b1a1924
Priority: 25000, Internal Priority: 25000
Up Time: 3d 12:54:22, Hard Timeout: 0 seconds
Idle Timeout: 300 seconds, Internal Idle Timeout: 300 seconds
Packets: 434301355815, Bytes: 29532492197664
Match Parameters:
Valid Match: InPort,SMAC,DMAC,Vid
In Port : Te 0/0 EType : *
SMAC : 00:00:00:00:12:01 / ff:ff:ff:ff:ff:ff
DMAC : 00:00:00:00:12:02 / ff:ff:ff:ff:ff:ff
VLAN id : 10 VLAN PCP : *
IP TOS : * IP proto : *
Src IP : * Dest IP : *
Src Port : * Dest Port : *
Actions:
Set VLAN id: 4094
Set DMAC: 02:20:00:18:00:05
Output: Te 0/3
S4810_R5_R7_bottom_leaf#
Miscellaneous
The debug messages show packet-in message which is a way for the OF switch to send a captured packet to the OF controller. This type of packet will be used whenever a flow-miss takes place, in other words, if a flow has not been programmed in the switch by the OF controller, a packet-in message will be generated by the switch to the controller. The buffer id tracks the buffered packet.
Packet-out on the other hand is used by the OF controller to inject program packets into the data plane of the OF switch so the direction of the message is controller to switch. This message can carry raw packets which are used to program the flows on the switch.
Figure 8 OpenFlow debug packet-in between switch and OF controller
16 Dell Networking – OpenFlow Technical Brief
S4810_Spine_1# 19w3d1h : Tx PacketIn in inst 1, controller 1.1.1.1/ 6633 - V1.3
19w3d1h : Tx PacketIn in inst 1, controller 1.1.1.1/ 6633 - V1.3
19w3d1h : bufferId: - 1, inPort: Te 0/ 2; len: 60; reason: 1 cookie: 0
19w3d1h : Enet data:
19w3d1h : dm: 01:80:c2:00:00:0e, sm: 02:25:5c:ca:ff:fe, dlType: 0x88cc
23w5d23h : Rx PacketOut in inst 1, controller 1.1.1.1/ 6633 - V1.3
23w5d23h : Buffer id: - 1, inPort: Controller
23w5d23h : Action Type: 0 len: 16
23w5d23h : output port: (0x4) Te 0/ 3, max_len: 65535
23w5d23h : Enet data:
23w5d23h : dm: 01:80:c2:00:00:0e, sm: 02:25:5c:ca:ff:fe, dlType: 0x88cc
23w5d23h :
Conclusion
SDN is completely new but familiar at the same time. It forces us to think of networking in a new light while keeping that familiar feeling of flows being programmed on the switch forwarding tables similar to the current existing switching architectures.
This brief technical document shows the power of openflow with its programmability aspects, spanning-tree less requirements, efficiency, and overall minimum manual configuration intervention by the network administrator.
Dell’s openflow implementation continues to evolve and provide new features to address new use cases for greenfield and brownfield SDN deployments. A Dell hybrid openflow deployment shows the benefits of both, a traditional field proven feature set while providing room for experimentation and innovation through openflow for an SDN enabled network.
17 Dell Networking – OpenFlow Technical Brief
