Dell Networking OS for OpenFlow User Manual

Dell Networking Operating System for OpenFlow on N-Series (DNOS-OF)

User Guide v1.1b

Dell Networking Engineering (Campus)

June 2016

©2016 Dell Inc., 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™, Dell Precision™ ,OptiPlex™, Latitude™, PowerEdge™, PowerVault™, PowerConnect™, OpenManage™, EqualLogic™, Compellent™, KACE™, FlexAddress™, Force10™ and Vostro™ are trademarks of Dell Inc. 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. EMC VNX®, and EMC Unisphere® are registered trademarks of EMC Corporation. 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. Citrix®, Xen®, XenServer® and XenMotion® are either registered trademarks or trademarks of Citrix Systems, Inc. in the United States and/or other countries. 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 Broadcom Corporation. 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.

NOTE: A NOTE indicates important information that helps you make better use of your computer.

CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid the problem. WARNING: A WARNING indicates a potential for property damage, personal injury, or death.

2015–03, Rev. A02

Table of contents

1 Executive summary – DNOS-OF ............................................................................................................................................ 7

1.1 DNOS-OF Overview ....................................................................................................................................................... 7

1.2 About This Document .................................................................................................................................................... 7

1.3 Additional Documentation ............................................................................................................................................ 7

2 User Guide .................................................................................................................................................................................. 8

2.1 Embedded Management (CLI/GUI) ............................................................................................................................. 8

2.2 Supported Hardware ...................................................................................................................................................... 8

2.3 Limitations and Product Constraints ........................................................................................................................... 8

3 Product Features – SDN/OpenFlow and DNOS-OF ......................................................................................................... 10

3.1 Overview – What is SDN? ............................................................................................................................................ 10

3.2 Overview – What is OpenFlow? ................................................................................................................................. 10

3.3 Overview – What is DNOS-OF? .................................................................................................................................. 11

4 Product Details ......................................................................................................................................................................... 12

4.1 SDN and the OpenFlow Architecture ........................................................................................................................ 12

4.1.1 SDN/OpenFlow High Level Architectural Components ........................................................................................ 12

4.2 DNOS-OF Product Details........................................................................................................................................... 13

4.2.1 High Level Architecture................................................................................................................................................ 13

4.2.2 Indigo .............................................................................................................................................................................. 14

4.2.3 of-switch Main Application ......................................................................................................................................... 14

4.2.4 OF-DPA SDK .................................................................................................................................................................. 14

4.3 OpenFlow Multi Table Programming supported by DNOS-OF ........................................................................... 15

4.3.1 Bridging and Routing Functions ................................................................................................................................. 15

4.3.2 DNOS-OF Object Descriptions – Flow Tables and Group Tables ....................................................................... 16

4.3.2.1 Ingress Port Flow Table .................................................................................................................... 17

4.3.2.1.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry ............ 17

4.3.2.2 VLAN Flow Table .......................................................................................................................... 18

4.3.2.2.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry ........... 18

4.3.2.3 Termination MAC Flow Table ..................................................................................................... 20

4.3.2.3.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry ........... 20

4.3.2.4 Bridging Flow Table ..................................................................................................................... 22

4.3.2.4.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry ........... 22

4.3.2.5 Unicast Routing Flow Table ........................................................................................................ 24

4.3.2.5.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry ........... 24

4.3.2.6 Multicast Routing Flow Table ..................................................................................................... 26

4.3.2.6.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry ........... 26

4.3.2.7 Policy ACL Flow Table ..................................................................................................................... 28

4.3.2.7.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry ........... 28

4.4 Group Table ................................................................................................................................................................... 32

4.4.1 DNOS-OF flow tables................................................................................................................................................... 33

4.4.2 DNOS-OF L2 Interface Group Entries ....................................................................................................................... 33

4.4.2.1 Naming Convention ........................................................................................................................ 34

4.4.2.2 Action Buckets.............................................................................................................................. 34

4.4.2.3 Counters ....................................................................................................................................... 34

4.4.3 DNOS-OF L2 Rewrite Group Entries ......................................................................................................................... 35

4.4.3.1 Naming Convention ........................................................................................................................ 35

4.4.3.2 Action Buckets.............................................................................................................................. 35

4.4.3.3 Counters ....................................................................................................................................... 35

4.4.4 DNOS-OF L3 Unicast Group Entries ......................................................................................................................... 36

4.4.4.1 Naming Convention .................................................................................................................... 36

4.4.4.2 Action Buckets.............................................................................................................................. 36

4.4.4.3 Counters ....................................................................................................................................... 37

4.4.5 DNOS-OF L2 Multicast Group Entries....................................................................................................................... 37

4.4.5.1 Naming Convention ........................................................................................................................ 37

4.4.5.2 Action Buckets.............................................................................................................................. 37

4.4.5.3 Counters ....................................................................................................................................... 38

4.4.6 DNOS-OF L2 Flood Group Entries............................................................................................................................. 38

4.4.6.1 Naming Convention ........................................................................................................................ 38

4.4.6.2 Action Buckets.............................................................................................................................. 39

4.4.6.3 Counters ....................................................................................................................................... 39

4.4.7 DNOS-OF L3 Interface Group Entries ....................................................................................................................... 39

4.4.7.1 Naming Convention ........................................................................................................................ 40

4.4.7.2 Action Buckets.............................................................................................................................. 40

4.4.7.3 Counters ....................................................................................................................................... 40

4.4.8 DNOS-OF L3 Multicast Group Entries ....................................................................................................................... 41

4.4.8.1 Naming Convention .................................................................................................................... 42

4.4.8.2 Naming Convention .................................................................................................................... 42

4.4.8.1 Counters ....................................................................................................................................... 42

4.4.9 DNOS-OF L3 ECMP Group Entries ............................................................................................................................ 42

4.4.9.1 Naming Convention ........................................................................................................................ 43

4.4.9.2 Action Buckets.............................................................................................................................. 43

4.4.9.3 Counters ....................................................................................................................................... 43

4.4.10 Fast Failover Group Entries ..................................................................................................................................... 43

4.4.11 Meters.............................................................................................................................................................................. 43

4.4.12 Ports ............................................................................................................................................................................ 44

4.4.12.1 Physical Ports ............................................................................................................................... 44

4.4.12.2 Counters ....................................................................................................................................... 46

4.4.12.3 Reserved Ports .............................................................................................................................. 47

4.4.13 Vendor Extension Features ..................................................................................................................................... 48

4.4.13.1 Source MAC Learning .................................................................................................................. 48

4.4.13.2 Group Properties .......................................................................................................................... 48

4.5 OpenFlow Single Table Programming Supported by DNOS-OF (NEC PF6800 PFC Cluster Controller

compatibility mode) ................................................................................................................................................................ 49

4.5.1 Bridging and Routing Functions in NEC ................................................................................................................... 49

5 Installation, Configuration, Deployment ............................................................................................................................. 56

5.1 View current installed OS ............................................................................................................................................ 56

5.2 Install DNOS-OF ............................................................................................................................................................ 57

5.3 Configure Management Access ................................................................................................................................. 57

5.4 Configure Controller Communications Channel.................................................................................................... 58

5.4.1 Example Multitable (Ryu) Controller Configuration................................................................................................ 58

5.4.2 Example Singletable (NEC) Controller Configuration ............................................................................................ 61

5.5 Verifying the Switch to Controller Communications ............................................................................................. 64

5.5.1 Verfying Topology with Ryu Controller .................................................................................................................... 67

5.5.2 Verifying Topology with NEC Controller .................................................................................................................. 69

5.6 Logging ........................................................................................................................................................................... 72

5.6.1 View Logging Configuration ....................................................................................................................................... 72

5.6.1.1 show logging .................................................................................................................................... 72

5.6.1.2 show ip syslog service ..................................................................................................................... 73

5.6.2 Enable or Change Runtime Logging Levels/Components .................................................................................... 73

5.6.2.1 set logging component................................................................................................................... 73

5.6.2.2 set logging level ........................................................................................................................... 73

5.6.3 Enable or Change Default Logging Levels/Components ...................................................................................... 73

5.6.3.1 set default logging component ..................................................................................................... 73

5.6.3.2 set default logging level .............................................................................................................. 74

5.6.4 Syslog Configuration .................................................................................................................................................... 74

5.7 Switch Configuration Storage..................................................................................................................................... 74

5.7.1 startup-config ................................................................................................................................................................ 74

5.7.2 running-config .............................................................................................................................................................. 75

5.7.3 backup-config ............................................................................................................................................................... 76

A Appendix - DNOS-OF CLI Command Reference .............................................................................................................. 79

A.1 Commands .....................................................................................................................................................................80

B Appendix – Setting up flows with the DNOS-OF SDN Agent, Ryu SDN Controller, and Ryu REST API ................ 137

1. Ryu 3.23.2 Installation ................................................................................................................................................ 137

2. Starting the Ryu controller with the REST API enabled ........................................................................................ 137

3. Where within the Ryu directory structure to find the REST API script .............................................................. 142

C Appendix - Example of setting up a basic Ethernet L2 Bridging topology for end to end traffic with Ryu .......... 143

C.1 System Diagram for example flow ........................................................................................................................... 143

C.2 Step 1 - Set up a VLAN flow with Ryu ...................................................................................................................... 144

C.3 Step 2 - Set up a Group Entry in Ryu ....................................................................................................................... 147

C.4 Step 3 - Set up a Bridging Flow in Ryu .................................................................................................................... 147

D Appendix - additional resources ......................................................................................................................................... 149

1 Executive summary – DNOS-OF

SDN and OpenFlow is fast becoming a requirement in campus networking products due to the perceived strategic value of SDN and the high perceived cost of proprietary legacy network gear. DNOS-OF is a campus networking product based on existing N Series hardware and a custom firmware image.

1.1 DNOS-OF Overview

DNOS-OF is a web downloadable firmware image available for the Dell Networking N-Series hardware that enables OpenFlow 1.3.4 support as a pure OpenFlow switch. It is intended to:

• Provide basic easy to use pure OpenFlow mode support on N-Series switches to enable SDN for Campus

networks, no hybrid mode is supported.

• Co-exist with the existing N-Series firmware images and image management, while not affecting any

existing functionality. This requires the ability to load DNOS-OF code from within the users existing firmware, run as a pure OF switch, and revert back with no impact to the users existing firmware, including their running configuration and switch settings.

• Leverage Broadcom’s OFDPA (OpenFlow Data Path Abstraction) SDK to provide basic OpenFlow agent

integration, along with abstracting the SOC hardware tables when presenting them as OpenFlow flow tables.

• Network administrators are able to select the OS for the switch in the same manner they select which

firmware image they want to run today.

• Provide limited and simpler features and functionality in order to allow for delivery of a quick and low cost

solution that is easy to test out in customer lab environments.

• Provide support for the Ryu OpenFlow controller and the NEC PF6800 PFC controller cluster.

1.2 About This Document

This guide describes the product and its purpose, how to configure, monitor, and maintain DNOS-OF on the Dell Networking N-Series switches, a reference for the DNOS-OF command-line interface (CLI) and some basic examples showing how to set up Ryu for a single end to end Layer 2 traffic flow in DNOS-OF,

and a configuration guide for setting up Layer 2 vBridges and Layer 3 vRouters with VTN’s (virtual tenant

networks) in the NEC controller.

1.3 Additional Documentation

Documents for the Dell Networking series switches are available at dell.com/support.

2 User Guide

2.1 Embedded Management (CLI/GUI)

There is a CLI provided by the DNOS-OF platform that is accessible from the serial port, telnet, and SSH. There is currently no other management access, however a GUI is planned for release with DNOS-OF 1.1. The CLI reference is also included in an appendix at the end of this document.

2.2 Supported Hardware

The DNOS-OF firmware is supported on the following N-Series platforms as of release 1.1:

– 1524 – 1524P – 1548 – 1548P – 2024 – 2024P – 2048 – 2048P – 3024 – 3024P – 3048 – 3048P – 4032 – 4032F – 4064 – 4064F

2.3 Limitations and Product Constraints

 Dell Networking N-Series switches with the DNOS-OF firmware installed are pure OpenFlow only

switches. No legacy functions are available, nor is hybrid mode

 The primary user interface is CLI, however there is a GUI under development.  Only a single OpenFlow instance is supported, which includes all physical ports.  The OpenFlow 1.3.4 spec is the only initial mode of compatibility supported, there is no backwards

compatibility with prior versions of the OpenFlow spec.

 DNOS-OF is only qualified with the Ryu controller and the NEC PF6800 PFC cluster controller. This is in

alignment with DNOS-9.x and their OpenFlow / SDN mode release compatibility and testing.

 All OpenFlow 1.3.4 commands that are listed as “mandatory” in the spec are supported except for those

having to do with hybrid mode. Some OpenFlow 1.3.4 commands that are “optional” but that enhance the product serviceability and value, or that are required for controller function are supported as well.

 Stacking of DNOS-OF OpenFlow switches is not supported.  Basic SSH is provided in 1.1. TLS is planned for a future release,  Packet buffering is not supported.

 Except for minimal system internal and OpenFlow packet debugging, logging and output to the serial

console, only remote logging via SysLog is currently supported so as not to impact existing N Series code.

Traditional non SDN networks vs SDN networks

3 Product Features – SDN/OpenFlow and DNOS-OF

3.1 Overview – What is SDN?

Software-Defined Networking (SDN) is a networking architecture that is dynamic, manageable, and adaptable, making it useful for high-bandwidth applications. This architecture decouples the network control and data plane forwarding functions, enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services. The OpenFlow™ protocol is a foundational element for building SDN solutions.

Some attributes of SDN architecture are:

 Directly programmable: Network control is directly programmable because it is decoupled from forwarding functions.

 Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs.

 Centrally managed: Network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.

 Programmatically configured: SDN lets network managers configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs, which they can write themselves because the programs do not depend on proprietary software.

 Open standards-based and vendor-neutral: When implemented through open standards, SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols.

3.2 Overview – What is OpenFlow?

The OpenFlow protocol is one instance of an SDN architecture, based on a set of specifications maintained by the Open Networking Forum (ONF). At the core of the specifications is a definition of an abstract packet processing machine, called a switch. The switch processes 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 the protocol to manage the configuration state of many switches and respond to events.

More Information on the overview and genesis, current state of protocol:

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdnnewnorm.pdf

OpenFlow from Flowgrammable website: http://flowgrammable.org/

OpenFlow from Open Networking Spec website:

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

3.3 Overview – What is DNOS-OF?

As a product line, the Dell Networking Operating System – for OpenFlow, DNOS-OF is a firmware bundle that allows a traditional N series switch to be used as a pure OpenFlow switch. DNOS-OF is designed to

1. Deliver a pure OpenFlow switch for the N series

2. Enable SDN in campus networks

3. Interoperate with any controller supporting OpenFlow 1.3.4 and multiple table support, as well

as with the NEC PF6800 PFC cluster controller.

DNOS-OF leverages the BigSwitch Networks open source Indigo agent (Indigo) and Broadcom’s OpenFlow Data Plane Abstraction (OF-DPA) packages to provide OpenFlow support.

The DNOS-OF based abstract switch is a specialization of the OpenFlow 1.3.4 OFLS (OpenFlow logical switch).

The DNOS-OF abstract switch objects can be thought of as programming points for the Ethernet switching hardware. These include flow tables with action sets, group table entries, physical ports, and queues. The DNOS-OF adaptation layer provides support for OpenFlow specific state, for example, statistics counters. It also maps OpenFlow objects to hardware and manages hardware resources. Supporting OpenFlow in switch hardware involves some tradeoffs. As has been noted elsewhere, the generality promised by OpenFlow can come at a cost of latency, as well as cost and power inefficiencies. In addition, to effectively use this generality a specific multi-table pipeline first needs to be designed and configured. The DNOS-OF Abstract Switch may be viewed as coming preconfigured and optimized to support single pass, full bandwidth packet processing performance that makes efficient use of the hardware and available table memory resources, trading off unrestricted generality in favor of latency, performance, and cost, while enabling a logically centralized control plane with programming flexibility.

The DNOS-OF Abstract Switch includes functionality to support bridging and routing functionality on the switch chip, among other functions, by the use of flow descriptors. Flows represent groups of data plane traffic that match the same flow description lasting for varying durations. The flow descriptors expose the proper functionality in the switching hardware control the data path of the flows. Future versions of DNOS-OF are expected to support additional features and packet flow use cases.

DNOS-OF implements a basic SDK based switch OS, with the primary functionality being an SDN agent, a CLI and platform support for the various N-Series hardware components.

OpenFlow Controller

User applic ation

REST

API

OpenFlow Agent

OpenFlow 1.3.4 protocol

TCP or TLS

OpenFlow Logical Switch Op enFlow Logical Switch

OpenFlow Agent

OpenFlow 1 .3.4 protocol

TCP or TLS

4 Product Details

4.1 SDN and the OpenFlow Architecture

4.1.1 SDN/OpenFlow High Level Architectural Components

At the core of the OpenFlow specifications is the definition of an abstract packet processing machine, called a switch. The switch processes 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 the OpenFlow protocol down to the switch based agent in order to manage the configuration state of many switches and respond to switch events.

Controller Topology

The controllers provide flow programming instructions to agents running in the switches for setting up switch functions and tables that are normally programmed to run on the legacy firmware on the switch itself, such as VLAN’s, ACL entries, routing and bridging.

4.2 DNOS-OF Product Details

4.2.1 High Level Architecture

The network OS portion of DNOS-OF consists of minified Debian Linux kernel with a BusyBox distribution for the main underlying core of the platform operating environment. There is some additional kernel framework consisting of the kernel mode interface BDE drivers provided by the switch SDK.

There are also user mode drivers for all of the target platform hardware, which together makes up the Board Support Package (BSP). There is also SDN agent functionality that handles the northbound interface to the SDN controller. There is also functionality that implements, translates and encapsulates the SDN OpenFlow

1.3.4 protocol capability into instructions specific to the switch ASIC (the OF-DPA layer), as well as functionality that controls the interface between the open source agent and the switch application. This includes a CLI provided by the underlying platform interface.

The DNOS-OF 1.0 firmware was initially targeted for the N3024 and N3048 N-series family of campus Ethernet switches from Dell and later added the PoE versions, N3024P and N3048P. DNOS-OF 1.1 added support for the remaining N Series platforms, N1524, N1524P, N1548, N1548P, N2024, N2024P, N2048, N2048P, N4032, N4032F, N4064, and N4064F.

Below are the primary components that make up the DNOS-OF firmware architecture in release 1.1.

Note that the OpenFlow controllers shown in this diagram are the ones officially supported by DNOS-OF

1.1, but any controller that is OpenFlow 1.3.4 compliant should work with DNOS-OF. This is mainly dependent on the ability of the specific controller software to work with 1) OpenFlow 1.3.4, and 2) some knowledge and support for the limitations of the hardware SOC based flow tables.

4.2.2 Indigo

Indigo is an open source Big Switch Networks provided north bound OpenFlow API layer which has been tied into the OF-DPA libraries and consequently into the switch application. It handles communications from the OpenFlow controller to the OpenFlow agent in the DNOS-OF switch.

4.2.3 of-switch Main Application

The SDN agent providing a northbound interface to the SDN controller, the CLI, the board support package providing platform monitoring, and the overall initiation and control of the switch applications and various tasks takes place in the switch application.

The CLI is provided by the underlying DNOS-OF platform layer, and is currently accessible through the serial console as well as telnet and SSH. Support for a REST API based GUI, SNMP MIB’s, and various other management approaches are planned for a later release.

4.2.4 OF-DPA SDK

The OpenFlow Data Plane Abstraction SDK translates general OpenFlow protocol commands received and processed by the Indigo OpenFlow agent on an abstract or virtual switch into specific rules and tables as implemented on a Broadcom SOC product in order to establish flow directives on the hardware.

Here is a high level diagram of what is provided by OF-DPA.

4.3 OpenFlow Multi Table Programming supported by DNOS-OF

4.3.1 Bridging and Routing Functions

Figure 2. Abstract switch Objects Used for Bridging and Routing

The DNOS-OF Abstract Switch objects that can be programmed for bridging and routing in multi table mode are shown in Figure 2.

Multi table mode exposes the tables highlighted and shown above to support direct flow table programming access to controllers that can address multiple flow tables. The following sections describe the interface provided by the DNOS-OF switch to the OpenFlow controller for the internal switch tables. The key OpenFlow instruction required for multi table support is the “goto table” instruction, allowing the user to control the data plane pipelining through the DNOS-OF switch.

Packets enter and exit the pipeline on physical ports local to the switch. The Ingress Port Flow Table (table 0) is always the first table to process a packet. Flow entries in this table can distinguish traffic from different types of input ports by matching associated Tunnel Id metadata. Normal bridging and routing packets from physical ports have a Tunnel Id value of 0. To simplify programming, this table provides a default rule that passes through packets with Tunnel Id 0 that do not match any higher priority rules. Logical ports are not supported in DNOS-OF, so the Tunnel Id will always be 0.

All packets in the Bridging and Routing flow must have a VLAN. The VLAN Flow Table can do VLAN filtering for tagged packets and VLAN assignment for untagged packets. If the packet has more than one VLAN tag, the outermost VLAN Id is the one used for forwarding.

The Termination MAC Flow Table matches destination MAC addresses to determine whether to bridge or

route the packet and, if routing, whether it is unicast or multicast. MAC learning is supported using a “virtual”

flow table that is logically synchronized with the Bridging Flow Table.

When MAC learning is enabled, DNOS-OF does a lookup in the Bridging Flow Table using the source MAC, outermost VLAN Id, and IN_PORT. A miss is reported to the controller using a Packet In message. Logically this occurs before the Termination MAC Flow Table lookup. The MAC Learning Flow Table cannot be directly read

or written by the controller. The MAC Learning Flow Table has a “virtual” table number which is reported to the Controller in a table miss Packet-In message. It does not appear as part of the pipeline since its table number assignment would violate the OpenFlow requirement for packets to traverse tables in monotonically increasing order.

The ACL Policy Flow Table can perform multi-field wildcard matches, analogous to the function of an ACL in a conventional switch.

DNOS-OF makes extensive use of OpenFlow Group entries, and most forwarding and packet edit actions are applied based on OpenFlow group entry buckets. Groups support capabilities that are awkward or inefficient to program in OpenFlow 1.0, such as multi-path and multicast forwarding, while taking advantage of functionality built into the hardware.

4.3.2 DNOS-OF Object Descriptions – Flow Tables and Group Tables

DNOS-OF presents the application writer with a set of objects that can be programmed using OpenFlow 1.3.4. The programmable objects include flow tables and group table entries.

This section provides programming descriptions for these objects. For details consult the DNOS-OF TTP (Table Type Patterns) supplied with the firmware.

Flow tables have specific attributes, including entry types (rules) that have specific match fields, actions, and instructions. Flow entries can have “Goto-Table” instructions that determine the next table to process the packet. In other words, the flow entry programming determines the order in which packets traverse tables and accumulate actions in an action set. Actions in the action set are applied prior to the packet being forwarded when there is no next table specified. Specific forwarding actions, including egress packet edits, are for the most part included within the action sets of the group entries. DNOS-OF uses specific types of group entries to support different packet flow scenarios. Apply-actions instructions and action lists are also used for some VLAN tag packet editing, and to send packets to the controller.

In the general OpenFlow case packets pass from flow table to flow table and can be arbitrarily modified between tables. To take advantage of this generality each table stage would need to include a packet parser. In DNOS-OF this kind of packet flow is conceptual - packets are parsed early in the pipeline and header fields are extracted. After that it is only these fields that are passed between tables and used for matching or modification by “apply actions” instructions. It is not expected that this distinction will matter to applications.

The next section describes the DNOS-OF flow tables in terms of their supported match fields, flow entry rule types, instructions, actions, expiration provisions, and statistics counters. Default miss actions are also specified for each table as applicable. Group table entry types and action set constraints are then described.

Ingress packets always have an associated Tunnel Id metadata value. For packets from physical ports this value is always zero. Only Physical ports are supported in DNOS-OF, so no Tunnel Id values other than 0 are allowed.

NOTE: The software has other undocumented tables and groups implemented, but only the features described here to support bridging and routing are described here. For complete table descriptions and flow table programming capability, please consult the OF-DPA documentation.

Type

Description

Normal Ethernet Frames

Matches packets from local physical ports, identified by zero Tunnel Id. Normal Ethernet rules have Goto-Table instructions that specify the VLAN Flow Table.

Field

Bits

Maskable

Optional

Description

IN_PORT

Yes

Ingress port. Depending on rule may be omitted to match any IN_PORT.

Name

Argument

Description

Goto-Table

Table

Next table. For this release, must be the VLAN Flow Table.

Apply-Actions

Action list

Can contain at most one instance of each of the actions listed in Table 3.1

Name

Argument

Description

Set-Field

VRF

VRF for L3 lookups. Only applicable to Normal Ethernet Frame rules. Optional.

Name

Type

Description

Active Entries,

Table

Reference count of number of active entries in the table

Duration

Per-entry

Seconds since this flow entry was installed

4.3.2.1 Ingress Port Flow Table

The Ingress Port Flow Table is the first table in the pipeline and, by convention, is numbered zero. OpenFlow uses a 32 bit value for ifNums. In this version of DNOS-OF, the high order 16 bits are zero for physical ports since no other port types are supported in 1.0.

The Ingress Port Flow Table presents what is essentially a de-multiplexing logic function as an OpenFlow table that can be programmed from the controller. By default, packets from physical ports with null (zero) Tunnel Id metadata go to the VLAN Flow Table. Entries in this table must admit ingress packets by matching the ingress ifNum exactly, by matching Tunnel Id, or by some combination.

Note: DNOS-OF may prevent certain types of rules from being added to other tables unless there is appropriate flow entry in the Ingress Port Flow Table. The default on miss is for packets from physical ports to go to the VLAN Flow Table. There is no default rule for data center overlay tunnel packets from logical ports, which are dropped on miss.

4.3.2.1.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry

The Ingress Port Flow Table supports the flow entry types listed in Table 1. This table would typically have one rule enabling ingress packets from each port type. However, since in this release, only the physical port type is supported, only one rule is enabled.

Table 1: Ingress Port Flow Table Entry Types

Table 2: Ingress Port Flow table Match Fields

Table 3: Ingress Port Flow Table Instructions

The Ingress Port Flow Table supports the single Goto-Table instruction listed in Table 3.

The Ingress Port Flow Table actions can optionally set the packet VRF using an action list.

Table 4: Ingress Port Flow Table Action List

Table 5: Ingress Port Flow Table Counters

Type

Description

VLAN Filtering

Exact match on IN_PORT and VLAN_VID parsed from the packet. For tagged packets with a VLAN tag containing a VLAN_VID greater than zero. Cannot be masked. VLAN_VID cannot be used in a Port VLAN Assignment rule for untagged packets. The only instruction is Goto-Table and must specify the Termination MAC Flow Table. Tagged packets that do not match any rule are treated as VLAN_VIDs that are not allowed on the port and are dropped. Can optionally assign a VRF for routed packets.

Untagged Packet Port VLAN Assignment

Exact match on IN_PORT and VLAN id == 0 (lower 12 bits of match field) value using a mask value of 0x0fff (masks off OFPVID_PRESENT). Action set must assign a VLAN_VID. The VLAN_VID value cannot be used in a VLAN Filtering rule. If the packet does not have a VLAN tag, one will be pushed if necessary at packet egress. Rule must have a Goto-Table instruction specifying the Termination MAC Flow Table. Untagged packets are dropped if there is no port VLAN assignment rule. Can optionally assign a VRF for routed packets.

Allow All VLANs

Wildcard VLAN match for a specific IN_PORT. Essentially turns off VLAN filtering and/or assignment for a physical port. Must be lower priority than any overlapping translation, filtering, MPLS, or VLAN assignment rule. Untagged packets that match this rule will be assigned an illegal VLAN and may be subsequently dropped. Should also define an L2 Unfiltered Interface group entry for the port.

VLAN Translate, Single Tag, or Single Tag to Double Tag

Used to either modify the VLAN id on a single tagged packet, or to optionally modify the VLAN id and then push another tag onto a single tagged packet. Can also optionally assign a VRF for routed packets. By OpenFlow convention, the outermost VLAN tag is matched independent of TPID.

4.3.2.2 VLAN Flow Table

The VLAN Flow Table is used for IEEE 801.Q VLAN assignment and filtering to specify how VLANs are to be handled on a particular port. All packets must have an associated VLAN id in order to be processed by subsequent tables. Packets that do not match any entry in the VLAN table are filtered, that is, dropped by default. Note that IEEE defined BPDUs are always received untagged. The VLAN Flow Table can optionally assign a nonzero VRF value to the packet based on the VLAN. OF-DPA defines VRF as a new pipeline metadata field. The VRF defaults to zero if not set.

4.3.2.2.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry

The VLAN Flow Table supports the Flow Entry Types listed in Table 10. Flow entries are differentiated based on IN_PORT, whether or not the packet was tagged, and the VLAN id in the tag.

OpenFlow has traditionally used a 16-bit field for VLAN id. Since only the low order 12 bits are needed to express a VLAN id, OpenFlow has defined special values to indicate tagged and untagged packets. In particular, the VLAN id 0x0000 (OFPVID_NONE, defined in the OpenFlow specification) is used to represent an untagged packet, and 0x1000 (OFPVID_PRESENT) for a priority tagged packet. All tagged packets are represented by VLAN id values between 0x1001 and 0x1FFE24 (OFPVID_PRESENT | VLAN id value). This convention must be followed in programming rules from the controller. For further explanation consult the OpenFlow 1.3.4 specification.

Note: DNOS-OF does not support matching packets just on whether or not they have a VLAN tag as described in Table 13 of OpenFlow 1.3.4.

Note: At most two tags are supported. Entries in the OF-DPA VLAN Flow table are mutually exclusive. Any explicit rule priority assignments are ignored.

Table 6: VLAN Flow Table Flow Entry Types

Name

Argument

Description

Apply-Actions

Action List

The VLAN Flow Table supports the actions specified in Table 13.

Goto-Table

Table

For VLAN filtering or Port VLAN assignment the next table should be the Termination MAC Flow Table.

Name

Argument

Description

Set Field

VLAN_VID, must be between 1 and 4094.

Sets the VLAN id on the outermost tag. If the packet is untagged then one is pushed with the specified VLAN id and priority zero.

Set Field

VRF

Optionally sets the VRF pipeline field. VRF must be the same in all rules for the same VLAN.

Push VLAN

TPID

Used in translating single to double tag. TPID must be 0x8100 (inner VLAN tag) or 0x88a8 (outer VLAN tag).

Note: The untagged packet rule applies to both untagged packets, which match VLAN_VID = 0x1000, and IEEE 802.1P priority tagged packets, which match VLAN_VID = 0x0000. However the VLAN-PCP match field will be set from the value in a priority VLAN tag rather than default to zero in the case of a packet without a VLAN tag.

Note: A VLAN Flow Table rule cannot specify an IN_PORT and VLAN_VID combination that is used in a VXLAN Access Logical Port configuration. Conversely, it must include a rule to permit an IN_PORT and VLAN_VID combination used in a VXLAN Tunnel Next H

Table 8. VLAN Flow Table Instructions

The VLAN table uses Apply Actions for port VLAN tagging and assignment. The action list can have at most one of each action type.

Table 9: VLAN Flow Table Action List

Note: The untagged packet action is the same as in OpenFlow 1.0. The implicit addition of a tag to an untagged packet is tolerated but not condoned in OpenFlow 1.3.4.

Only hard interval time-out ageing per entry is supported, as indicated in Table 9.

\Field

Bits

Maskable

Optional

Description

IN_PORT

Yes

Physical (local) input port.

ETH_TYPE

Prerequisite for IPv4 (0x0800) or IPv6 (0x86dd).

ETH_DST

Ethernet destination MAC. Prefix maskable for only the specific multicast IP flow entries in Table 28. Can only be field masked for unicast destination MACs.

VLAN_VID

Yes

Matches against the Outer VLAN id. Must be either omitted or exact.

IPV4_DST

\Yes

Yes

Can only be used with 224/8 address and

224.0.0.0 mask values, otherwise must be omitted. Prerequisite ETH_TYPE must be 0x0800.

IPv6_DST

128

Yes

Can only be used with FF00::/8 address and FF00:0:0:0:0:0:0:0 mask values, otherwise must be omitted. Prerequisite ETH_TYPE must be 0x86dd.

4.3.2.3 Termination MAC Flow Table

The Termination MAC Flow Table determines whether to do bridging or routing on a packet. It identifies destination MAC, VLAN, and Ethertype for routed packets. Routed packet rule types use a goto instruction to indicate that the next table is one of the routing tables. The default on a miss is to go to the Bridging Flow Table.

4.3.2.3.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry

The Termination MAC Flow Table implements the flow entry types listed in Table 12.

The Termination MAC Flow Table match fields are listed in Table 13. Strict rule priority must be assigned by the controller so that every flow entry has a unique priority.

Table 13: Termination MAC Flow Table Match Fields

Name

Argumen t

Description

Goto-Table

T a b l e

Unicast MAC rules with multicast IPV4_DST or IPV6-DST should specify the Multicast Routing Flow Table, otherwise they can only specify the Unicast Routing Flow Table. Multicast MAC rules can only specify the Multicast Routing Flow Table. The packet is dropped if the rule matches and there is no Goto-Table instruction.

Apply Actions Ac

t i o n

L i s t

Optional. If supplied can only contain one action, output a copy to CONTROLLER.

The Termination MAC Flow Table can have the instructions shown in Table 14.

Type

Description

Unicast VLAN Bridging

Matches switched unicast Ethernet frames by VLAN id and MAC_DST. MAC_DST must be unicast and cannot be masked. VLAN id must be present and nonzero. Tunnel id must be masked or omitted.

Multicast VLAN Bridging

Matches switched multicast Ethernet frames by VLAN id and MAC_DST. MAC_DST must be multicast and cannot be masked. VLAN id must be present and nonzero. Tunnel id must be masked or omitted.

DLF VLAN Bridging

Matches switched Ethernet frames by VLAN id only. MAC_DST must be field masked and match any destination. Must have lower relative priority than any unicast or multicast flow entries that specify this VLAN. VLAN id must be present and nonzero. Tunnel id must be masked or omitted.

Field

Bits

Maskable

Optional

Description

ETH_DST

Yes

Ethernet destination MAC, allowed values depend on flow entry type. Exact match only (mask must be all 1’s if supplied).

VLAN_VID

Yes

VLAN id, allowed values depend on flow entry type. Exact match only (mask

must be all 1’s if

supplied).

4.3.2.4 Bridging Flow Table

The Bridging Flow Table supports Ethernet packet switching for potentially large numbers of flow entries using the hardware L2 tables. The default on a miss is to go to the Policy ACL Flow Table. Note: The Policy ACL Flow Table is preferred for matching BPDUs. The Bridging Flow Table forwards based on VLAN (normal switched packets) using the flow entry types in

Table 17.

Table 17: Bridging Flow Table Flow Entry Types

Note: Exact match rules must be given higher priority assignments than any wildcard rules. In any event,

exact match rules are evaluated before any wildcard rules.

4.3.2.4.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry

Match fields for flow entry types are described in the following tables.

Table 18. Bridging Flow Table Match Fields

Default next table if no match is the ACL Policy Flow Table.

Type

Argument

Description

Unicast VLAN Bridging

Group ID

Must be a DNOS_OF L2 Interface group entry for the forwarding VLAN.

Multicast VLAN Bridging

Group ID

Must be a DNOS_OF L2 Multicast group entry for the forwarding VLAN.

DLF VLAN Bridging

Group ID

Must be a DNOS_OF L2 Flood group entry for the forwarding VLAN.

The Bridging Flow Table supports the actions in Table 20 by flow entry type. The DNOS-OF API validates consistency of flow entry type and DNOS-OF group entry type references.

Table 20: Bridging Flow Table Actions by Flow Entry Type

The Bridging Flow Table counters are listed in Table 21.

Bridging Flow Table expiry provisions are shown in Table 22.

Type

Table

Prerequisite(s)

Description

IPv4 Unicast

Table 40

Ethertype=0x0800

Matches routed unicast IPv4 packets. The Goto-Table instruction specifies the Policy ACL Table.

IPv6 Unicast

Table 41

Ethertype=0x86dd

Matches routed unicast IPv6 packets. The Goto-Table instruction specifies the Policy ACL Table.

Field

Bits

Maskable

Optional

Description

ETH_TYPE

Must be 0x0800

VRF

Yes

If omitted or zero indicates the default routing table.

IPv4 DST

Yes

Must be a unicast IPv4 address. Prefix maskable only, mask used for LPM forwarding.

Field

Bits

Maskable

Optional

Description

ETH_TYPE

Must be 0x86dd

VRF

Yes

If omitted or zero indicates the default routing table.

IPV6_DST

128

Yes

Must be a unicast IPv6 address. Prefix maskable only, used for LPM forwarding.

Name

Argument

Description

Write-Actions

Action set

Only the actions in Table 27 can be specified.

Clear-Actions

Used to delete any forwarding decision so that the packet will be dropped.

4.3.2.5 Unicast Routing Flow Table

The Unicast Routing Flow Table supports routing for potentially large numbers of IPv4 and IPv6 flow entries using the hardware L3 tables.

The Unicast Routing Flow Table is a single table organized as two mutually exclusive logical subtables by IP protocol, and supports flow entry types listed in Table 23. One table number is used for both logical tables.

Table 23. Unicast Routing Flow Table Entry Types

4.3.2.5.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry

Table 24. Unicast Routing Flow Table IPv4 Header Match Fields

Table 25. Unicast Routing Flow Table IPv6 Header Match Fields

Note: Exact match rules must be given higher priority assignments than any LPM prefix match rules. In any

event, the hardware evaluates exact match rules before any wildcard rules.

Note: Rules that specify a nonzero VRF must have higher relative priority than other overlapping rules. The

wildcard rules are effectively “global” or “default” in that they are matched last, that is, if no specific VRF

rule matches the packet. If the packet VRF is zero it can only match one of the wildcard rules. Default next table on a miss is the ACL Policy Flow Table.

Table 26: Unicast Routing Flow Table Instructions

Name

Argument

Description

Group

Group ID

Must be a DNOS-OF L3 Unicast Group Entry.

Decrement TTL and do MTU check

MTU check is a vendor extension. An invalid TTL (zero before or after decrement) is always dropped and a copy sent to the CPU for forwarding to the CONTROLLER. Similarly, a packet that exceeds the MTU is dropped and a copy sent to the CONTROLLER. Required.

Other instruction types, specifically Apply Actions, are not supported.

Table 27: Unicast Routing Flow Table Actions

The group entry includes the decrement TTL and MTU check actions, so these need not be explicitly specified in the action set. The Routing Flow Table counters are listed in Table 28.

Unicast Routing Flow Table expiry provisions are shown in Table 29.

Field

Bits

Maskable

Optional

Description

ETH_TYPE

N o

Must be 0x0800. Required prerequisite.

VLAN_VID

N o

VLAN id

VRF

N o

Yes

VRF.

IPV4_SRC

Y e s

Yes

Cannot be bit masked, but can be omitted.

IPV4_DST

Y e s

Must be an IPv4 multicast group address.

Field

Bits

Maskable

Optional

Description

ETH_TYPE

Must be 0x86dd. Required prerequisite.

VLAN_VID

VLAN id

VRF

Yes

VRF.

IPV6_SRC

128

Yes

Cannot be bit masked, but can be omitted.

IPV6_DST

128

Yes

Must be an IPv6 multicast group address.

4.3.2.6 Multicast Routing Flow Table

The Multicast Routing Flow Table supports routing for IPv4 and IPv6 multicast packets. The Multicast Routing Flow Table is also organized as two mutually exclusive logical sub tables by IP protocol,

and supports the flow entry types listed in Table 30.

4.3.2.6.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry

Match fields for flow entry types are described in the following tables.

Table 31. Multicast Routing Flow Table IPv4 Match Fields

Table 32. Multicast Routing Flow Table IPv6 Match Fields

Default next table on miss is the ACL Policy Flow Table.

Name

Argument

Description

Write Actions

Action set

Only the actions in Table 34 can be specified.

GotoTable

Table

Must be the Policy ACL Flow Table. In the event that there is no group entry referenced and no next table specified, the packet will be dropped.

Name

Argument

Description

Group

Group ID

Must be a DNOS-OF L3 Multicast group entry with the forwarding VLAN ID as a name component.

Decrement TTL and do MTU check

Table 33: Multicast Routing Flow Table Instructions

Other instruction types, specifically Apply Actions, are not supported.

Table 34: Multicast Routing Flow Table Actions

Note: The group entry includes the decrement TTL and MTU check actions.

Type

Table

Prerequisite

Description

IPv4 VLAN

Table 38

Ethertype != 0x86dd IN_PORT is a physical port.

Matches packers by VLAN ID except for IPv6. VLAN ID is optional but must be nonzero if supplied.

IPv6 VLAN

Table 39

Ethertype = 0x86dd

Matches only IPv6 packets by VLAN ID. VLAN ID is optional but must be nonzero if supplied.

Field

Bits

Maskable

Optional

Description or Prerequisite

IN_PORT

Yes

Physical or logical ingress port.

ETH_SRC

Yes

Ethernet source MAC

ETH_DST

Yes

Ethernet destination MAC

ETH_TYPE

Yes

Any value except 0x86dd. Explicit prerequisite must be 0x800 if IP fields are to be matched.

VLAN_VID

Yes

VLAN id. Cannot be masked for a VLAN bridging rule that redirects to a different L2 output group. Only applicable to VLAN flow entry types.

VLAN_PCP

Yes

802.1p priority field from VLAN tag. Always has a value, will be zero if packet did not have a VLAN tag.

VLAN_DEI

Yes

802.1p drop eligibility indicator field from VLAN tag. Always has a value, will be zero if packet did not have a VLAN tag.

VRF

Yes

VRF.

IPV4_SRC

Yes

Matches SIP if Ethertype = 0x0800

ARP_SPA

Yes

Matches ARP source protocol address if Ethertype = 0x0806

IPV4_DST

Yes

Matches DIP if Ethertype = 0x0800

IP_PROTO

Yes

IP protocol field from IP header if Ethertype = 0x0800

4.3.2.7 Policy ACL Flow Table

The Policy ACL Flow Table supports wide, multi-field matching. Most fields can be wildcard matched, and explicit priority must be included in all flow entry modification. This is the preferred table for matching BPDU and ARP packets. It is also the only table where QoS actions are available.

The Policy ACL Flow Table is organized as mutually exclusive logical sub tables. Flow entries in the IPv6 logical tables match only IPv6 packets by VLAN ID. The non-IPv6 logical table matches any packet except for IPv6 packets by VLAN ID. By OpenFlow single-entry match semantics, since the Policy ACL Flow Table is considered a single table, a packet can match, at most, one rule in the entire table.

Note: The Ethertype prerequisite must be explicitly provided and cannot be masked. The default on table miss is to do nothing. The packet will be forwarded using the output or group in the

action set, if any. If the action set does not have a group or output action the packet is dropped. The Policy ACL Flow Table supports the flow entry types listed in Table 37.

Table 37: Policy ACL Flow Table Entry Types

4.3.2.7.1 Match Criteria, Instructions, Actions/Action List/Action Set, Counters, Flow Expiry

The available match fields for Policy ACL Flow Table flow entry types are as described in the following tables.

Table 38: Policy ACL Flow Table IPv4 Match Fields

IP_DSCP

Yes

Bits 0 through 5 of the IP ToS Field as defined in RFC 2474 if Ethertype = 0x0800

IP_ECN

Yes

Bits 6 through 7 of the IP ToS Field as defined in RFC 3168 if Ethertype = 0x0800

TCP_SRC

Yes

If Ethertype = 0x0800 and IP_PROTO = 6

UDP_SRC

Yes

f Ethertype = 0x0800 and IP_PROTO = 17

SCTP_SRC

Yes

If Ethertype = 0x0800 and IP_PROTO = 132

ICMPV4_TYPE

Yes

If Ethertype = 0x0800 and IP_PROTO = 1

TCP_DST

Yes

If Ethertype = 0x0800 and IP_PROTO = 6

UDP_DST

Yes

if Ethertype = 0x0800 and IP_PROTO = 17

SCTP_DST

Yes

If Ethertype = 0x0800 and IP_PROTO = 132

ICMPv4_CODE

Yes

If Ethertype = 0x0800 and IP_PROTO = 1

Field

Bits

Maskable

Optional

Description

IN_PORT

Yes

Physical or logical ingress port.

ETH_SRC

Yes

Ethernet source MAC

ETH_DST

Yes

Ethernet destination MAC

ETH_TYPE

Yes

Must be 0x86dd

VLAN_VID

Yes

VLAN id. Cannot be masked for a VLAN bridging rule that redirects to a different L2 output group. Only applicable to VLAN flow entry types.

\VLAN_PCP

Yes

802.1p priority field from VLAN tag. Always has a value, will be zero if packet did not have a VLAN tag.

VLAN_DEI

Yes

802.1p drop eligibility indicator field from VLAN tag. Always has a value, will be zero if packet did not have a VLAN tag.

VRF

Yes

VRF

IPV6_SRC

128

Yes

Matches IPv6 SIP

IPV6_DST

128

Yes

Matches IPv6 DIP

IP_PROTO

Yes

Matches IPv6 Next header

IPV6_FLABEL

Yes

Matches IPv6 flow label

IP_DSCP

Yes

Bits 0 through 5 of the IP ToS Field as defined in RFC 2474 if Ethertype = 0x86dd

IP_ECN

Yes

Bits 6 through 7 of the IP ToS Field as defined in RFC 3168 if Ethertype = 0x86dd

TCP_SRC

Yes

If Ethertype = 0x86dd and IP_PROTO = 6

UDP_SRC

Yes

If Ethertype = 0x86dd and IP_PROTO = 17

SCTP_SRC

Yes

If Ethertype = 0x86dd and IP_PROTO = 132

ICMPV6_TYPE

Yes

If Ethertype = 0x86dd and IP_PROTO = 58

TCP_DST

Yes

If Ethertype = 0x86dd 00 and IP_PROTO = 6

Table 39: Policy ACL Flow Table IPv6 Match Fields.

UDP_DST

Yes

If Ethertype = 0x86dd and IP_PROTO = 17

SCTP_DST

Yes

If Ethertype = 0x86dd and IP_PROTO = 132

ICMPv6_CODE

Yes

If Ethertype = 0x86dd and IP_PROTO = 58

Name

Argument

Description

Apply Actions

Action list

Optional. Only the actions in Table 41 can be specified.

Clear Actions

Used to clear the action set for dropping the packet. Cannot be combined with write actions.

Write Actions

Action set

Only the actions in Table 42 or Table 43 can be specified, depending on rule type.

Name

Argument

Description

SetField

Traffic Class

Name

Argument

Description

Group

Sets output group entry for processing the packet after this table. Group must exist, be consistent with the type of rule and packet;, and can be any of: L2 Interface, L2 Rewrite, L2 Multicast, L3 Unicast, L3 Multicast, or L3 ECMP; must respect VLAN id naming conventions. In particular, if the output is an L2 Rewrite group that does not set the VLAN id, the L2 Interface group it references must be consistent with the VLAN id in the matched flow entry.

SetQueue

Queue-id

Determines queue to be used when packet is finally forwarded. Zero indicates the default queue. Cannot be used together with Set Traffic Class in the action list.

Notes:

 IPv6 Neighbor Discovery field matching is not supported in this version of DNOS-OF.  Not all IPv6 match fields are supported on all platforms.

 DNOS-OF permits bit masking L4 source and destination ports, as well as ICMP code. The OpenFlow does

not require these to be maskable.

The only instruction is write actions. Since there is no next table, there can be no Goto-Table or Write Metadata instructions.

Table 40: Policy ACL Flow Table Instruction Set

The packet is dropped if there is no group action that specifies output ports, since there is no next table. Note: Apply-actions to CONTROLLER would be used in order to output the packet to the CONTROLLER reserved port, rather than an output action in the write-actions action set.

The Policy ACL Flow Table supports the actions listed in Table 41.

Table 41: Policy ACL Flow Table Action List Actions

The Policy ACL Flow Table action set supports the actions listed in Table 70 for VLAN match rule types, and the actions in Table 71 for tunnel match rule types.

Table 42: Policy ACL Flow Table VLAN Flow Entry Action Set

+ 119 hidden pages