VRF lite for Dell Networking N-Series - Dell Technologies

A Dell EMC Deployment and Configuration Guide

Hybrid OpenFlow for Dell Networking N-Series Using OpenDaylight Dell Networking Solutions Engineering May 2016

DRAFT

r

SION

DR

draft

2 Hybrid OpenFlow for Dell Networking N-Series - Version 1.0

Revisions

Date Description Author

May 2016 Hybrid Openflow for Dell Networks N-Series using OpenDaylight – Version 1.0

Sambhu Kalaga, Victor Teeter

Copyright © 2016 Dell Inc. or its subsidiaries. All Rights Reserved.

Except as stated below, no part of this document may be reproduced, distributed or transmitted in any form or by any

means, without express permission of Dell.

You may distribute this document within your company or organization only, without alteration of its contents.

THIS DOCUMENT IS PROVIDED “AS-IS,” AND WITHOUT ANY WARRANTY, EXPRESS OR IMPLIED. IMPLIED

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE SPECIFICALLY

DISCLAIMED. PRODUCT WARRANTIES APPLICABLE TO THE DELL PRODUCTS DESCRIBED IN THIS DOCUMENT

MAY BE FOUND AT: http://www.dell.com/learn/us/en/vn/terms-of-sale-commercial-and-public-sector-warranties

Performance of network reference architectures discussed in this document may vary with differing deployment

conditions, network loads, and the like. Third party products may be included in reference architectures for the

convenience of the reader. Inclusion of such third party products does not necessarily constitute Dell’s recommendation of

those products. Please consult your Dell representative for additional information.

Trademarks used in this text: Dell™, the Dell logo, Dell Boomi™, PowerEdge™, PowerVault™, PowerConnect™,

OpenManage™, EqualLogic™, Compellent™, KACE™, FlexAddress™, Force10™ and Vostro™ are trademarks of Dell

Inc. EMC VNX®, and EMC Unisphere® are registered trademarks of Dell. Other Dell trademarks may be used in this

document. Cisco Nexus®, Cisco MDS®, Cisco NX-0S®, and other Cisco Catalyst® are registered trademarks of Cisco

System Inc. Intel®, Pentium®, Xeon®, Core® and Celeron® are registered trademarks of Intel Corporation in the U.S.

and other countries. AMD® is a registered trademark and AMD Opteron™, AMD Phenom™ and AMD Sempron™ are

trademarks of Advanced Micro Devices, Inc. Microsoft®, Windows®, Windows Server®, Internet Explorer®, MS-DOS®,

Windows Vista® and Active Directory® are either trademarks or registered trademarks of Microsoft Corporation in the

United States and/or other countries. Red Hat® and Red Hat® Enterprise Linux® are registered trademarks of Red Hat,

Inc. in the United States and/or other countries. Novell® and SUSE® are registered trademarks of Novell Inc. in the

United States and other countries. Oracle® is a registered trademark of Oracle Corporation and/or its affiliates. VMware®,

Virtual SMP®, vMotion®, vCenter® and vSphere® are registered trademarks or trademarks of VMware, Inc. in the United

States or other countries. IBM® is a registered trademark of International Business Machines Corporation. Broadcom®

and NetXtreme® are registered trademarks of QLogic is a registered trademark of QLogic Corporation. Other trademarks

and trade names may be used in this document to refer to either the entities claiming the marks and/or names or their

products and are the property of their respective owners. Dell disclaims proprietary interest in the marks and names of

others.

http://www.dell.com/learn/us/en/vn/terms-of-sale-commercial-and-public-sector-warranties


Contents

1 Introduction ................................................................................................................................................................... 5

2 OpenFlow Hybrid principles of operation ..................................................................................................................... 8

3 OpenDaylight controller .............................................................................................................................................. 10

4 POSTMAN configurations .......................................................................................................................................... 12

5 Enabling OpenFlow features on Dell N-Series Switches ........................................................................................... 14

6 OpenFlow configuration examples ............................................................................................................................. 16

6.1 Example 1: Simple hybrid networking example ................................................................................................ 17

6.2 Example 2: Multi switch OpenFlow................................................................................................................... 23

6.3 Traditional Networking ...................................................................................................................................... 39

A Additional Resources ................................................................................................................................................. 40

B Versions ...................................................................................................................................................................... 41

C Glossary of Terms ...................................................................................................................................................... 42


Executive summary

The introduction of server virtualization led to a revolution among enterprises that has consumed the

focus around IT infrastructure for the past decade. Virtualization changed the entire server

infrastructure operational model in such a profound way that it laid the foundation for a complete re-

imagining of enterprise IT. Prior to virtualization, IT services were encumbered by the realities of the

physical world. However, empowered by virtualization, the deployment of a new server became as

simple as the touch of a button. It has fundamentally changed efficiency levels, driven massive

improvements in asset efficiency and resulted in billions in savings across the industry. Server

Virtualization created the notion and promise that all other infrastructure domains could grow to

deliver simplicity and agility.

Until today, traditional networking technologies have not provided any of the tremendous advantages

of virtualized networks. Traditional networks have a vertically integrated stack, which slows

innovation. Traditional networking solutions built using legacy development methodologies that

prevent application ecosystems from emerging cannot drive high levels of automation and application

integration. In response to this need, leading cloud and enterprise application developers are turning

to a new method of network development known as Software-Defined Networking (SDN). SDN

enables network virtualization that provides the last piece of the puzzle required to deliver low-lost,

all-inclusive private cloud solutions to enterprise data centers.

SDN is the key to enabling significant technologies from the all-inclusive, elastic private cloud to

secure mobile access, bring your own device (BYOD) and beyond. These technologies comprise a

highly automated model that gives enterprise IT never-before-seen levels of agility. At the same time,

this model reduces both capital and operational overhead to the lowest levels ever delivered in

enterprise solutions. The OpenFlow protocol is a foundational element for building SDN solutions.

This document provides a background and understanding of SDN technology using Dell Networking

OpenFlow Hybrid switches and OpenDaylight SDN Controller. It provides basic instructions for and

examples of deploying OpenFlow on Dell N-Series switches.


1 Introduction Dell Networking provides customers with the most efficient use of current networking equipment at the lowest

cost. At the same time, Dell EMC equipment provides today’s great new technologies focused around the

explosive data growth in the industry. Various application demands have driven the need for increased

bandwidth, lower latency and converged infrastructure in today’s networks. Dell EMC’s portfolio covers all

these key areas to meet our customers’ critical business needs. In turn, our product support teams provide

the best in service and customer experience.

Today’s businesses find it difficult to keep pace with the changing networking and Enterprise landscape. With

limited resources, they must support a variety of devices that provide key business functions, deliver reliable,

flexible IT services and provide discernible cost savings.

Networking architecture overview

Remote Data Centers

Dell Servers

Dell Storage

Data Center

Dell Network Controllers

and Security

Campus

Remote/Branch Office

VRTX

Dell Campus Networking

Internet

Dell Data Center Networking

Public Cloud

Storage Network

WAN

This document serves as a supplement to the Dell N-Series User Guide. It provides easy, step-by-step

instructions to help users set up and configure Dell Networking N-Series OpenFlow Hybrid switches to use

the OpenFlow features.

ftp://ftp.dell.com/Manuals/all-products/esuprt_ser_stor_net/esuprt_networking/esuprt_net_fxd_prt_swtchs/networking-n3000-series_Administrator Guide3_en-us.pdf


Advantages of using SDN OpenFlow features over traditional networking include the following:

Directly Programmable: Network control is directly programmable because it is decoupled from

forwarding functions.

Agile: A centralized software-driven controller modifies the behavior of the network devices in

minutes, as compared to configuring each network device individually as in traditional networking.

Programmatically configured: Network operators new define and develop new feature

implementation or feature customizations rather than waiting for proprietary implementations from

network vendors. Automated configuration of network devices reduces networks errors, operating

expenses, manual efforts and network downtime. Business objectives can easily drive change

management.

Centrally managed: Operators gain a centralized perspective of entire network topology. They

define and identify specific traffic flows, load sharing policies and network failures across the topology

using the centralized software controller. However, in traditional networking, complex networking

protocols in the control plane of each networking device make it difficult to identify the traffic flows and

network failures.

The OpenFlow protocol is one instance of the SDN architecture, based on a set of specifications maintained

by the Open Networking Forum (ONF). The OpenFlow switch processes the packets using a combination of

packet contents and switch configuration state. A protocol is defined for manipulating the switch’s

configuration state as well as receiving certain switch events. Finally, a controller is an element that speaks to

the protocol to manage the configuration state of many OpenFlow enabled switches and respond to events.

Dell Networking offers pure OpenFlow networking switches as well as hybrid OpenFlow switches. The pure OpenFlow switches (N3xxx series) are supported using the Dell Networking Operating System for OpenFlow (DNOS-OF) firmware. Click the following link for more information about DNOS-OF:

http://www.dell.com/support/home/us/en/19/product-support/product/dell-netwroking-os-

openflow/manuals

Dell Networking OpenFlow Hybrid’s features implement a true hybrid model, that is, it supports both traditional

networking and OpenFlow features. On the interfaces with flows installed, packet forwarding proceeds based

on the flow-matching criteria. If the packets match the flows installed, then the forwarding is based on those

flows. Otherwise, forwarding proceeds normally based on traditional networking rules. Dell Networking

OpenFlow Hybrid enables switch management by the centralized OpenFlow Controller using the OpenFlow

protocol.

Note: Dell Networking OpenFlow Hybrid is supported in non-stacking deployments.

http://www.dell.com/support/home/us/en/19/product-support/product/dell-netwroking-os-openflow/manuals

http://www.dell.com/support/home/us/en/19/product-support/product/dell-netwroking-os-openflow/manuals


+The Dell Networking OpenFlow Hybrid switch contains OpenFlow agent version 2.3.0 from the Open

vSwitch (OVS) Project. OVS code is licensed under the Apache 2 License. The OpenFlow agent has been

validated with the Helium release of OpenDaylight (ODL). Dell Networking partially supports both OpenFlow

1.0 and OpenFlow 1.3 standards.

The OpenFlow 1.0 standard supports a single-table data-forwarding path. Dell Networking switches

support OVS proprietary extensions to enable the OpenFlow controller access to multiple forwarding

tables.

While the OpenFlow 1.3 standard enables a multi-table data-forwarding path, Dell Networking

switches use a single-table OpenFlow 1.3 data-forwarding path.

The OpenFlow examples in this document use Dell Networking N3xxx and N4xxx switches. Any N-Series

switch running firmware version 6.3 or later accepts the commands in this paper for configuring OpenFlow.

As of this writing, the following N-Series models offer OpenFlow support:

N2024 N3024 N4032

N2024P N3024F N4032F

N2048 N3024P N4064

N2048P N3048 N4064F

N3048P

The Dell Networking OpenFlow feature offers the following major functions:

Enables Dell Networking OpenFlow Hybrid

Deploys OpenFlow Configuration

Interacts with the OpenFlow controllers

Deploys OpenFlow controller flows

Collects Port and Queue status and statistics

Supports OpenFlow Controller Group tables


2 OpenFlow Hybrid principles of operation Strategic aspects of the OpenFlow 1.0/1.3 specifications are supported with the Dell Networking N-Series

OpenFlow Hybrid implementation. Some other features have also been added in order to enhance further the

networking environment. The following two lists show the behaviors and the limitations you can expect to

experience with Dell OpenFlow Hybrid.

The following behavior characterized the Dell Networking OpenFlow Hybrid implementation:

The switch simultaneously forwards OpenFlow and normal traffic on the same ports and VLANs.

When the controller adds flows, the switch automatically assumes the ports mentioned in the match

criteria or egress actions are OpenFlow ports. Therefore, the switch disables ingress and egress

filtering on those ports and allows them to receive and transmit traffic for any VLAN. This change in

the ingress and egress filtering behavior may affect how the switch handles the non-OpenFlow traffic

on those ports.

The switch’s OpenFlow implementation supports one bridge instance. The physical switch may not be

broken up into multiple, individual virtual switches at Layer 2.

In OpenFlow 1.0 mode, the switch supports several backup OpenFlow controllers. The backup

controllers can exchange hello messages with the switch, but cannot add flows or monitor switch

status. A vendor message allows a backup controller to become a primary controller. In the

OpenFlow 1.3 mode, several OpenFlow controllers can manage the switch at the same time.

In the OpenFlow 1.0 mode, the switch supports multiple hardware tables to which it adds flows. The

switch notifies the controller that it has multiple tables. The multi-table support in OpenFlow 1.0 does

not allow the OpenFlow controller to specify the table that the flow joins. Dell Networking OpenFlow

Hybrid extends the OpenFlow 1.0 protocol to specify the table number the flow joins by using the

most significant byte of the command field in the OFPT_FLOW_MOD message. "OpenFlow 1.0

Supported Flow Match Criteria, Actions and Status" defines which flows join which hardware tables.

The switch does not support the OpenFlow 1.0 emergency flow table.

In OpenFlow 1.3 mode, the switch supports only one hardware table and the group table.

The switch does not support forwarding packets in software. If a flow cannot be added to the

hardware, the switch generates an error message.

The switch only supports adding flow match criteria and forwarding actions for ports that are not

currently present in the system. However, port forwarding rules update correctly for ports removed

after flow installation. If the match port is not present on the switch, the switch holds the flow in a

software table. The switch then applies the flow to the hardware when the port becomes available. If

the port for a forwarding action is not present on the switch, the switch adds the flow without the

missing port. The switch then modifies the flow when the port becomes available. This behavior

enables the addition of flow with no egress ports. This causes the switch to drop packets matching

the flow.


When the switch loses connection to the OpenFlow controller, it continues to forward traffic using the

flows previously programmed by the controller. When the switch reconnects to the controller, it keeps

using the previously programmed flows until the OpenFlow controller tells it otherwise.

At boot time, the switches that do not have any flows forwards traffic normally using the Layer 2/Layer

3 forwarding rules.

The switch supports sending data packets to the controller. However, the controller must explicitly

install a flow to forward packets to the controller. The switch forwards the packets that do not match

any flow entries using normal Layer 2 or Layer 3 logic.

The switch allows the controller to inject packets into the network via the switch.

The switch supports flows for physical ports and LAGs. These ports can be used as destinations and

match criteria. Status and statistics are reported for these ports.

The switch supports eight Class of Service (CoS) queues per physical port.

Only switches running OpenFlow 1.3 support redirection queues.

The switch supports queue status reporting.

Key limitations are:

Dell Networking OpenFlow Hybrid Switches support only a single bridge instance.

Dell Networking OpenFlow Hybrid Switches support limited subset of flow actions.

Simultaneous support for IPv4 and IPv6 flows on N4xxx Series switches require disabling iSCSI.

N4xxx Series switches do not support the IPv6 destination address field.


3 OpenDaylight controller SDN offers centralized, programmable networking that can dynamically meet the changing needs of a

business. In the traditional networking architecture (see in Figure 2), the control, management and data

planes all reside in the networking device. The SDN architecture, however, decouples the control and

forwarding functions. This enables direct programming of network control and abstraction of the underlying

infrastructure for applications and network services. SDN architecture consists of three main components: the

SDN controller, the southbound application programming interfaces (APIs), and the northbound APIs. See

Figure 3.

Traditional networking switch architecture

Control Plane Management Plane

Data Plane

Switch

An SDN controller is an application installed on a server that manages flow control to enable intelligent

networking. Control plane solutions provide a separation of the control and data planes by using this central

server to maintain networking protocols and databases. These solutions also use the central server to

program forwarding information directly into switch forwarding tables. There are several control plane

solutions available in the market including, but not limited to ODL, NEC Programmable Flow Networking Suite

and RYU component-based SDN framework.

The Dell OpenFlow Hybrid switch validation in this document used the OpenDaylight controller. OpenDaylight

is an SDN controller that allows the user to manage programmatically OpenFlow-capable switches. It is an

open source, general purpose SDN controller with a modular, pluggable and flexible controller platform at its

core. This controller is implemented strictly in software and contained within its own Java Virtual Machine

(JVM). As such, you can deploy it on any hardware and operating system platform that supports Java.


Software defined networking architecture

Application Layer

Business Applications

Cloud Orchestration

(e.g. OpenStack, CloudStack)

SDN Applications

SDN Northbound Programmable

Open APIs

SDN Controllers

OpenFlow Controller

OpenFlow Controller

SDN Southbound APIs (e.g. Openflow)

OpenDaylight Helium SR4

OpenFlow Controller

Dell Networking OpenFlow Hybrid (e.g N4064, N3048P,

N2048P) and other OpenFlow Switches

The northbound programmable open APIs are used for communication between the SDN controller and the

services and applications running over the network. These services and applications include automation

stacks such as Puppet, Chef, and so on, and orchestration platforms such as OpenStack, CloudStack, and so

on. OpenDaylight’ s Flow Programmer service uses flows to query, add or modify the state of these

networking resources by using a REST (Representational State Transfer) interface. The state of these

networking resources can be represented in different formats, namely XML or JSON.

The southbound APIs provide communication between the SDN controller and the network devices.

Examples of OpenDaylight southbound APIs include OpenFlow (1.0 and 1.3), OVSDB, NETCONF, LISP,

BGP, PCEP, SNMP and so on. OpenDaylight controller adds and deletes entries in internal flow-tables of Dell

Networking OpenFlow Hybrid switches. It uses OpenFlow protocol communication with OpenFlow agent

version 2.3.0 from the Open vSwitch (OVS) project.

OpenDaylight Helium SR4 version is installed in the Ubuntu 14.04 operating system on the Dell PowerEdge

R600-series server. Java (version 1.7.0_95) is installed in the Ubuntu OS prior to installation of the Helium.

Instructions on installing OpenDaylight are out of scope for this document. Visit the OpenDaylight website for

more information on obtaining and installing the Helium SR4 version of OpenDaylight project by clicking on

the following link: https://www.opendaylight.org/software/downloads/helium-sr4

https://www.opendaylight.org/software/downloads/helium-sr4


4 POSTMAN configurations The Dell Networking OpenFlow Hybrid switch configurations in this document used POSTMAN Chrome API

service connected to OpenDaylight controller for validation. POSTMAN constructs and analyzes the API

requests, which are then sent / received to the ODL controller data store. The data store then communicates

to the switch using OpenFlow 1.3 as southbound API. POST, GET, PUT and DELETE are different options in

POSTMAN to create, read, update and delete the resource state in the OpenDaylight data store.

The following parameters have to be set to the following values in the Headers tab of POSTMAN to work with

the OpenDaylight controller:

Authorization: Basic (admin/admin)

Content-Type: application/xml or application/json

Accept: application/xml or application/json

POSTMAN Chrome service

The following URL in POSTMAN pushes the flows to specific networking devices using OpenDaylight

controller:

http://<ctrl-addr>:<tcp-port>/restconf/config/opendaylight-inventory:nodes/node/<Node-id>/table/<Table-

#>/flow/<Flow-#>

ctrl-addr – OpenDaylight controller server IP address

tcp-port – 8181

Node-id – OpenFlow id of the Node

Table-# - Table number

Flow-# - Flow number

The Table-# and Flow-# in the URL should match the XML script present in the Body tab of POSTMAN.


The following modules must be initialized in ODL Helium SR4 karaf to ensure connectivity with POSTMAN.

Locate details for installing ODL Helium in the OpenDaylight documentation.

odl-restconf

odl-l2switch-switch

odl-mdsal-apidocs

odl-dlux-core


5 Enabling OpenFlow features on Dell N-Series Switches Enable and disable the OpenFlow feature administratively on Dell N-series switches. The administrator allows

the switch to assign an IP address automatically to OpenFlow or specifically selects the address to use. The

administrator can also direct the OpenFlow Feature always to use the out-of-band (OOB) interface.

Automatic IP address selection occurs in the following order:

1. Loopback interfaces

2. Routing interfaces

3. OOB interfaces

The OpenFlow feature configures the Dell Networking OpenFlow Hybrid switch to be managed by an

OpenDaylight OpenFlow controller (ODL). In this example, the communication between the ODL controller

and the Dell Networking OpenFlow Hybrid switch (N4032) takes place over OOB IP using the OpenFlow 1.3

protocol.

Note: Dell N4xxx and N3xxx series switches support all (auto, static, OOB) OpenFlow modes. However,

N2xxx series switches do not support OOB mode.

Enter the following commands to enable the OpenFlow feature on Dell N4032 switch:

N4032#configure terminal

N4032(config)#openflow

WARNING! OpenFlow does not operate on stack members. Enable OpenFlow on stand-alone switches

only.

N4032(config-of-switch)#mode oob

N4032(config-of-switch)#controller ipv4 172.25.193.16 port 6633 security none

N4032(config-of-switch)#end

Enter the following show command to verify the status of the OpenFlow feature:

N4032#show openflow

Administrative Mode............................ Enable

Operational Status…………………………… Enabled

Disable Reason………………………………… None

IP Address………………………………………… 172.25.193.16

IP Mode……………………………………………. OOB IP

Static IP Address……………………………… 0.0.0.0

Network MTU………………………………….. 1518

OpenFlow Variant…………………………… OpenFlow 1.3

Passive Mode…………………………………… Disable


This example configures the Dell N2024 series switch to operate with OpenFlow version 1.3 and to connect to

the controller at IP address 1.2.3.4 on port 3435 with no security.

Enter the following commands to enable the OpenFlow feature on Dell N2024 switch:

N2024#configure terminal

N2024(config)#vlan 10

N2024(config-vlan10)#interface vlan 10

N2024(config-if-vlan10)#ip address 1.2.3.1 255.255.0.0

N2024(config-if-vlan10)#interface gi1/0/1

N2024(config-if-Gi1/0/1)#switchport mode access

N2024(config-if-vlan10)#switchport access vlan 10

N2024(config-if-vlan10)#exit

N2024(config)#openflow

WARNING! OpenFlow does not operate on stack members. Enable OpenFlow on stand-alone switches

only.

N2024(config-of-switch)#mode auto

N2024(config-of-switch)#controller ipv4 1.2.3.4 port 3435 security none

N2024(config-of-switch)#protocol-version 1.3

N2024(config-of-switch)#end


6 OpenFlow configuration examples Dell Networking OpenFlow Hybrid switches support multiple hardware tables, allowing the OpenFlow

controller to specify into which table to add the flow. When an OpenFlow protocol adds a flow to the Dell

Networking Hybrid flow database, the flow is not immediately added to the hardware. The flow additions and

removals take place separately. This enables the OpenFlow controller to be unblocked while waiting for the

flows to be added / removed from the hardware. If the OpenFlow controller adds a flow with the same match

criteria as an existing flow, Dell Networking OpenFlow Hybrid treats the new flow as a modification. Dell

Networking OpenFlow Hybrid switch deletes the old flow from the hardware and the new flow is added to the

hardware. Each time the switch fails to add a flow to the hardware, it sends a syslog message indicating the

flow XID.

The OpenFlow switch operates on two simple rules – match and action. The switch executes the flow entries

if the packet received on the switch matches a match entry in the hardware match-flow entry table. The

actions included in the flow entry may describe instructions for packet forwarding, modification or group table

processing. If there is no match, the Dell Networking OpenFlow Hybrid switch applies the traditional

networking rules to forward or drop the packet. The switch’s configuration can also instruct it to forward the

packet to the controller and await further instructions. Please refer to the Dell Networking OpenFlow Hybrid

principles of operation section for more details.


6.1 Example 1: Simple hybrid networking example This section demonstrates the true hybrid capabilities of the Dell Networking OpenFlow Hybrid switches. In

the topology below, the OpenDaylight controller manages the Dell Networking OpenFlow Hybrid switch

(N4032) through OOB management.

OpenFlow topology example

2 864

1 753

10 161412

9 151311

18 242220

17 232119 ACTLNK

N4032

OpenFlow Topology

Traditional Networking

OpenFlow Networking

Engineering Department (VLAN 20)

Finance Department(VLAN 40)

Te 1/0/1 Te 1/0/3

Te 1/0/4 Te 1/0/2

Te 1/0/1

Engineering Department (VLAN 20)

Finance Department(VLAN 40)

In the example shown in Figure 5, the N4032 Dell Networking switch connects the Engineering (VLAN 20)

and Finance (VLAN 40) departments at different locations. The Engineering department achieves connectivity

using OpenFlow. The Finance department achieves the connectivity through traditional networking. The

instructions below describe how to setup the Engineering department first, followed by the Finance

department.


6.1.1 Configuring OpenFlow networking on a hybrid switch (Engineering

department) For the Engineering department to be connected, install the flow shown below on the Dell N4032 switch using

Google’s Postman interface, which calls the REST APIs of the OpenDaylight controller. The ODL controller

then installs the flow in the switch through the OpenFlow 1.3 protocol.

6.1.2 OpenFlow postman XML script example with VLAN matching criteria

Note: The URL Flow-id and Table-id must match the XML script present on the Body tab.

PUT -> http://<ctrl-addr>:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:<N4024-OF-

ID>/table/0/flow/411

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>2</priority> <flow-name>Foo</flow-name> <match> <in-port>2</in-port> <vlan-match> <vlan-id> <vlan-id>20</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </match> <id>411</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>

Defining xml version Flow priority and Flow Name Define match criteria

Traffic from ingress port 2 i.e. Te1/0/2 VLAN Match – VLAN 20

Flow ID – 411 Table ID – 0 (default) Define Instruction set if there is a match. There can be multiple actions in each instruction set.

Send traffic to egress port 1 i.e. Te1/0/1


After successfully installing the flow on the switch, the switch checks for specific matching criteria <match> for

all the incoming packets on port 2 (<in-port> for Te1/0/2). These packets have the VLAN ID 20. In case of a

match, those packets are forwarded to the egress interface <output-node-connector> as defined in the flow

i.e. port 1 (Te1/0/1). All other packets are forwarded as per traditional networking forwarding rules.

6.1.2.1 Verify OpenFlow installation on the switch by OpenDaylight controller

N4032#show openflow switch flows

Flow: 49 Type: 1DOT3

Flow table: 60 Priority: 2

Ingress port: Te1/0/2 VLAN: 20 VLAN Mask: 4095

Actions:

Egress port: Te1/0/1

Status:

Duration (secs): 8 Idle: 0 In HW yes

The format of the XML that describes the OpenFlow matches is determined by the opendaylight-match-types

yang model. These match types can be broadly classified under the following groups:

mac-address-filter, vlan-match-fields, ethernet-match-fields, arp-match-fields, ipv4-match-fields, ipv6-match-

fields, ip-match-fields, udp-match-fields, tcp-match-fields, icmpv4-match-fields, icmpv6-match-fields, of-

metadata, protocol-match-fields, sctp-match-fields.

Refer to OpenDaylight documentation to understand and explore more about the match types. Basic match

criteria examples including ethernet-match-fields and ipv4-match-fields are illustrated below.


6.1.3 OpenFlow postman XML Script example with Ethernet

source/destination match criteria This XML script forwards the traffic matching the packets with ethernet source mac-address

00:00:42:A8:FF:CO and destination mac-address 00:00:00:05:00:01 to egress port Te1/0/1.


ID>/table/0/flow/11

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>11</priority> <flow-name>Foo</flow-name> <match> <ethernet-match> <ethernet-destination> <address>00:00:00:50:00:01</address> </ethernet-destination> <ethernet-source> <address>00:00:42:A8:FF:C0</address> </ethernet-source> </ethernet-match> </match> <id>11</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>

Defining xml version

Flow priority and Flow Name

Define match criteria

Ethernet destination mac address 00:00:00:50:00:01

Ethernet source mac address 00:00:42:A8:FF:C0




6.1.4 OpenFlow XML script example with IPv4 match criteria This XML script forwards the traffic matching the packets with IP destination address 20.20.20.0 to egress

port Te 1/0/1.


ID>/table/0/flow/11

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>11</priority> <flow-name>Foo</flow-name> <match> <ethernet-match> <ethernet-type> <type>2048</type> </ethernet-type> </ethernet-match> <ipv4-destination>20.20.20.0/24</ipv4-destination> </match> <id>11</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>

Defining xml version

Flow priority and Flow Name

Define match criteria

Ethernet type 2048 IPv4 destination address 20.20.20.0 /24




6.1.5 Configuring traditional networking on a hybrid switch (Finance

department) The Finance departments are connected using traditional networking practices. The commands and concept

are identical to using any traditional switch. Here, switch ports (Te1/0/3, Te1/0/4) are first configured with

trunk mode and a tagged VLAN 40 is allowed through the ports.

Enter the following to configure tagged VLAN 40 on the interfaces (Te1/0/3, Te1/0/4):

N4032#config terminal

N4032(config)#vlan 40

N4032(config-vlan40)#exit

N4032(config)#interface range tengigabitethernet 1/0/3-4

N4032(config-if)#switchport mode trunk

N4032(config-if)#switchport trunk allowed vlan 40

N4032#end

Enter the following show command to display the interface VLAN status:

N4032#show interface status

Port Description Duplex Speed Neg Link Flow M VLAN

State Ctrl

--------- --------------- ------ ------- ---- ------ ----- -- -------------------

Te1/0/3 Full 1000 Auto Up On T (1),40

Te1/0/4 Full 1000 Auto Up On T (1),40

As shown above, Example 1 depicts how a single switch can simultaneously do both OpenFlow and

traditional networking, allowing the administrator to select the best method per port that will provide the most

benefit to the network. This flexibility is what gives an Openflow hybrid switch the advantage over traditional

switching alone.


6.2 Example 2: Multi switch OpenFlow This example demonstrates the OpenFlow functionality across multiple switches. The Accounting team

(VLAN20) and the HR team (VLAN 40) are connected to different switches in the organization as shown in the

below topology.

Multi switch OpenFlow topology

Accounting TEAM

HR(vlan 40)

Accounting(vlan 20)

PowerEdge

2900

ODL Controller

Management Network

Switch1 = N3024-OF-ID1



Stack No.

1

2

1 2SFP+

3 5 7 9 11

4 6 8 10 12

13 15 17 19 21

14 16 18 20 22 24

LNK ACT1

2 COMBO P

23

LNK ACT

G1/0/1

Stack No.

1

2

1 2SFP+

3 5 7 9 11

4 6 8 10 12

13 15 17 19 21

14 16 18 20 22 24

LNK ACT1

2 COMBO P

23

LNK ACT

G1/0/2 G1/0/4

G1/0/1

G1/0/2 G1/0/4

Stack No.

1

2

1 2SFP+

3 5 7 9 11

4 6 8 10 12

13 15 17 19 21

14 16 18 20 22 24

LNK ACT1

2 COMBO P

23

LNK ACT

HR TEAM Accounting TEAM

G1/0/3

G1/0/1 G1/0/3

HR TEAM

G1/0/2

Switch 1

Switch 2

Switch 3

To configure OpenFlow on Dell Networking OpenFlow Hybrid switches, the administrator sends the flow

configurations through REST API (XML scripts) to the OpenDaylight controller. These OpenFlow XML scripts

are unidirectional. For bi-directional forwarding, the administrator has to develop two XML OpenFlow scripts.

The below XML Open scripts configure and send traffic from the internet to Accounting and HR teams.

All the traffic to Accounting / HR teams from Dell N3024 Switch1 should be forwarded to Dell switch2 and

switch3. Similarly, traffic from switch3 should be forwarded to switch2 and switch1.


6.2.1 Switch1 configurations The following POSTMAN XML scripts are used to configure switch1 to forward the Accounting / HR traffic.

6.2.1.1 Accounting team traffic (VLAN 20) from cloud to Switch2 Configure switch1 to forward Accounting traffic received on port Gi1/0/1 to port Gi1/0/4 as in Figure 6.


ID1>/table/0/flow/20

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>2</priority> <flow-name>VLAN20</flow-name> <match> <in-port>1</in-port> <vlan-match> <vlan-id> <vlan-id>20</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </match> <id>20</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>

Defining xml version Flow priority and Flow Name

Define match criteria Traffic from ingress port 1 i.e. Gi1/0/1 VLAN match - VLAN ID 20


Send traffic to egress port 4 i.e. Gi1/0/4


6.2.1.2 HR traffic (VLAN 40) from Dell N3024 cloud to switch2 Configure switch1 to forward HR traffic received on port Gi1/0/2 to port Gi1/0/4, as in Figure 6.





Define match criteria Traffic from ingress port 2 i.e. Gi1/0/2 VLAN match - VLAN ID 40 Flow ID – 40 Table ID – 0 (default) Define Instruction set if there is a match. There can be multiple actions in each instruction set.



6.2.1.3 Accounting traffic (VLAN 20) from switch2 to cloud Configure switch1 to forward Accounting traffic received on port Gi1/0/4 to port Gi1/0/1, as in Figure 6.



<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>2</priority> <flow-name>VLAN20_1</flow-name> <match> <in-port>4</in-port> <vlan-match> <vlan-id> <vlan-id>20</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </match> <id>21</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>






6.2.1.4 HR traffic (VLAN 40) from switch2 to cloud Configure switch1 to forward HR traffic received on port Gi1/0/4 to port Gi1/0/2 as in Figure 6.









6.2.1.5 Verify flow entries in Dell N3024 switch1

N3024_Switch1#show openflow switch flows

Flow: 7 Type: 1DOT3


Ingress port: Gi1/0/1 VLAN: 20 VLAN Mask: 4095

Actions:

Egress port: Gi1/0/4

Status:


Flow: 8 Type: 1DOT3



Actions:


Status:


Flow: 6 Type: 1DOT3



Actions:


Status:


Flow: 9 Type: 1DOT3



Actions:


Status:




6.2.2.1 Accounting traffic (VLAN20) from switch1 to switch3 and Accounting team Configure switch2 to forward Accounting traffic received on port Gi1/0/4 to port Gi1/0/3 and port Gi1/0/1 as in

Figure 6.



<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>2</priority> <flow-name>VLAN20</flow-name> <match> <in-port>4</in-port> <vlan-match> <vlan-id> <vlan-id>20</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </match> <id>20</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>1</order> <output-action> <output-node-connector>3</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>




Send traffic to egress port 1 i.e. Gi1/0/1 Send traffic to egress port 3 i.e. Gi1/0/3


6.2.2.2 HR Traffic (VLAN40) from switch1 to switch3 and HR Team Configure switch2 to forward HR traffic received on port Gi1/0/4 to port Gi1/0/3 and port Gi1/0/2 as in Figure

6.



<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>2</priority> <flow-name>VLAN40</flow-name> <match> <in-port>4</in-port> <vlan-match> <vlan-id> <vlan-id>40</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </match> <id>40</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>2</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>1</order> <output-action> <output-node-connector>3</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>






6.2.2.3 Accounting traffic (VLAN20) from switch3 to switch1 and Accounting Team Configure switch2 to forward Accounting traffic received on port Gi1/0/3 to port Gi1/0/4 and port Gi1/0/1 as in

Figure 6.



<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>2</priority> <flow-name>VLAN20_1</flow-name> <match> <in-port>3</in-port> <vlan-match> <vlan-id> <vlan-id>20</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </match> <id>21</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>1</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>






6.2.2.4 HR Traffic (VLAN40) from switch3 to switch1 and HR Team Configure switch2 to forward HR traffic received on port Gi1/0/3 to port Gi1/0/4 and port Gi1/0/2 as in Figure

6.



<?xml version="1.0" encoding="UTF-8" standalone="no"?> <flow xmlns="urn:opendaylight:flow:inventory"> <priority>2</priority> <flow-name>VLAN40_1</flow-name> <match> <in-port>3</in-port> <vlan-match> <vlan-id> <vlan-id>40</vlan-id> <vlan-id-present>true</vlan-id-present> </vlan-id> </vlan-match> </match> <id>41</id> <table_id>0</table_id> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>2</output-node-connector> <max-length>60</max-length> </output-action> </action> <action> <order>1</order> <output-action> <output-node-connector>4</output-node-connector> <max-length>60</max-length> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>


Define match criteria Traffic from ingress port 3 i.e. Gi1/0/3 VLAN match - VLAN ID 40 Flow ID – 41 Table ID – 0 (default) Define Instruction set if there is a match. There can be multiple actions in each instruction set.





Flow: 9 Type: 1DOT3



Actions:

Egress port: Gi1/0/1, Gi1/0/4

Status:


Flow: 10 Type: 1DOT3



Actions:


Status:


Flow: 8 Type: 1DOT3



Actions:


Status:


Flow: 7 Type: 1DOT3



Actions:


Status:


Note: Use the same methodology as shown above to configure switch2 to forward Accounting/HR team

traffic (port Gi1/0/1 and port Gi1/0/2) to switch1 and switch3.



6.2.3.1 Accounting traffic (VLAN20) from switch2 to Accounting Team Configure switch3 to forward Accounting traffic received on port Gi1/0/3 to port Gi1/0/1 as in Figure 6.






Flow ID – 20 Table ID – 0 (default) Define Instruction set of there is a match. There can be multiple actions in each instruction set.



6.2.3.2 HR traffic (VLAN 40) from switch2 to HR Team Configure switch3 to forward HR traffic received on port Gi1/0/3 to port Gi1/0/2 as in Figure 6.









6.2.3.3 Accounting traffic (VLAN20) from Accounting Team to switch2 Configure switch3 to forward Accounting traffic received on port Gi1/0/1 to port Gi1/0/3 as in Figure 6.









6.2.3.4 HR traffic (VLAN 40) from HR team to switch2 Configure switch3 to forward Accounting traffic received on port Gi1/0/2 to port Gi1/0/3 as in Figure 6.











Flow: 8 Type: 1DOT3



Actions:


Status:


Flow: 7 Type: 1DOT3



Actions:


Status:


Flow: 4 Type: 1DOT3



Actions:


Status:


Flow: 6 Type: 1DOT3



Actions:


Status:



6.3 Traditional Networking Starting with version 6.3, Dell Networking OpenFlow Hybrid switches support OpenFlow capabilities in

addition to supporting all the legacy protocols and commands used by non-hybrid firmware versions, as

demonstrated in example 1. It is sometimes desired to use traditional networking in areas like VOIP, PoE,

storage, QoS etc. where OpenFlow 1.0/1.3 specifications or Dell DNOS hybrid SDN specifications are not yet

supported. For traditional networking configuration guides and white papers regarding these areas please see

Appendix A, Additional Resources.


A Additional Resources

Support.dell.com focuses on meeting your needs with proven services and support.

DellTechCenter.com is an IT Community where you can connect with Dell EMC Customers and Dell EMC

employees to share knowledge, best practices and information about Dell EMC products and installations.

Referenced or recommended Dell publications:

Dell Networking Support

- http://www.dell.com/support

Dell TechCenter (community forums and blogs for Dell customers)

- http://delltechcenter.com

Dell Networking Whitepapers

- http://en.community.dell.com/techcenter/networking/p/guides

Dell Networking N2xxx User Guides and Firmware downloads

- http://www.dell.com/support/home/us/en/19/product-support/product/networking-n2000-

series/drivers



series/drivers



series/drivers

OpenFlow from Flowgrammable website

- http://flowgrammable.org/

OpenFlow from Open Networking Spec site

- https://www.opennetworking.org/sdn-resources/openflow

OpenDaylight website for latest documentations and builds

- https://www.opendaylight.org/

http://www.dell.com/support

http://delltechcenter.com/

http://en.community.dell.com/techcenter/networking/p/guides

http://www.dell.com/support/home/us/en/19/product-support/product/networking-n2000-series/drivers






http://flowgrammable.org/


B Versions

This document was compiled using the following components and versions.

Component Firmware Version

Dell Networking N3xxx series, N4xxx series 6.3.0.0 firmware

Ubuntu 14.0.4

Java 1.7.0_95

OpenDaylight Helium SR4


C Glossary of Terms

API (application programming interface) is a set of tools a programmer uses in creating a software

application.

CLI (Command Line Interface): Text-based telnet, secure shell (SSH), or serial type interface that is used

for issuing commands to a device.

SDN: Software-defined networking (SDN) is an approach to computer networking that allows network

administrators to manage network services through abstraction of higher-level functionality

OpenFlow: OpenFlow is a communication protocol that gives access to the forwarding plane of a network

switch or router over the network.

ODL: OpenDaylight is a collaborative open source project, for accelerating the adaption of software-defined

networking and create solid foundation for Network function Virtualization.

NFV: Network function virtualization is an initiative to virtualize the network services that are now being

carried out by proprietary, dedicated hardware.

REST: stands for Representational State Transfer. It relies on stateless, client-server, cacheable

communication protocol. It is an architecture style designed for networked applications.

Chrome Postman: Postman is a powerful API testing suite.


Support and Feedback

Contacting Technical Support

Support Contact Information Web: http://Support.Dell.com/ Telephone: USA: 1-800-945-3355

Feedback for this document

We encourage readers of this publication to provide feedback on the quality and usefulness of this

deployment guide by sending an email to [email protected]

About Dell EMC

Dell EMC is a worldwide leader in data center and campus solutions, which includes the manufacturing and

distribution of servers, network switches, storage devices, personal computers, and related hardware and

software. For more information on these and other products, please visit the Dell EMC website at

http://www.dell.com.

http://support.dell.com/

mailto:[email protected]?subject=Feedback:%20Hybrid%20OpenFlow%20for%20Dell%20Networking%20N-Series%20Using%20OpenDaylight

http://www.dell.com/

Documents

VRF lite for Dell Networking N-Series - Dell Technologies