Dell Networking Operating System for OpenFlow on N-Series (DNOS-OF) User Guide v1.0f Dell Networking Engineering (Campus) August 2015 ©2015 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.
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.
Table of contents 1 2 3 4 Executive summary – DNOS-OF ............................................................................................................................................ 7 1.1 DNOS-OF Overview ....................................................................................................................................................... 7 1.2 About This Document .............................................................................................................
.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 .........
4.4.8.2 Naming Convention .......................................................................................................................... 41 4.4.8.1 Counters .............................................................................................................................................. 41 4.4.9 DNOS-OF L3 ECMP Group Entries ............................................................................................................................ 41 4.4.9.1 Naming Convention ..
5.7.3 backup-config ............................................................................................................................................................... 59 A Appendix - DNOS-OF CLI Command Reference ............................................................................................................. 60 A.1 B C D Commands .....................................................................................................................................................
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 Networkinging N-Series hardware that enables OpenFlow 1.3.4 support as a pure OpenFlow switch.
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. The CLI reference is 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.0: - 3024 3024P 3048 3048P The current plan is for support of all N-Series hardware in following releases. 2.
3 Product Features – SDN/OpenFlow and DNOS-OF 3.1 Overview – What is SDN? The physical separation of the network control plane from the forwarding plane where a control plane controls several devices. Software-Defined Networking (SDN) is a networking architecture that is dynamic, manageable, and adaptable, making it useful for high-bandwidth dynamic applications.
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.
4 Product Details 4.1 Details 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.
4.2 DNOS-OF Product Details 4.2.1 Design The network OS portion of DNOS-OF consists of modified Debian Linux kernel for the main underlying core of the platform operating environment, along with an additional kernel framework consisting of the Debian Linux user and kernel mode interface BDE drivers provided by the switch SDK. There are also user mode drivers for all of the target hardware, which together make up the Board Support Package (BSP).
4.2.2 Module Architecture While the primary application architecture, build system and OS infrastructure were designed and built in house at Dell, the product uses several open source and vendor packages, all tied together with Dell proprietary glue code, as shown below: 4.2.3 Kernel The DNOS-OF software architecture consists of a standard kernel.
4.2.7 OF-DPA SDK The OpenFlow Data Plane Abstraction SDK, translates general OpenFlow protocol commands received and processed by the OpenFlow agent on an abstract or virtual switch into specific rules and tables as implemented on a Broadcom SOC product in order to establish flows on the hardware. Here is a high level diagram of what is provided by OF-DPA.
4.3 OpenFlow 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 are shown in Figure 2. 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.
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.
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.
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.
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.
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.
The Termination MAC Flow Table can have the instructions shown in Table 14. Name Goto-Table Apply Actions Argumen t Description TUnicast MAC rules with multicast IPV4_DST or IPV6-DST should specify athe Multicast Routing Flow Table, otherwise they can only specify the bUnicast Routing Flow Table. Multicast MAC rules can only specify the lMulticast Routing Flow Table. The packet is dropped if the rule matches eand there is no Goto-Table instruction. AOptional.
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.
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 Type Unicast VLAN Bridging Multicast VLAN Bridging DLF VLAN Bridging Argument Group ID Description Must be a DNOS_OF L2 Interface group entry for the forwarding VLAN. Group ID Must be a DNOS_OF L2 Multicast group entry for the forwarding VLAN.
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.
Name Group Decrement TTL and do MTU check Argument Group ID - Description Must be a DNOS-OF L3 Unicast Group Entry. 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. The group entry includes the decrement TTL and MTU check actions, so these need not be explicitly specified in the action set.
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.
GotoTable 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. Other instruction types, specifically Apply Actions, are not supported. Table 34: Mutlicast Routing Flow Table Actions Name Group Table Argument Group ID Description Must be a DNOS-OF L3 Multicast group entry with the forwarding VLAN ID as a name component. Decrement MTU check is a vendor extension.
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.
IP_ECN 2 No Yes TCP_SRC UDP_SRC SCTP_SRC ICMPV4_TYPE TCP_DST UDP_DST SCTP_DST ICMPv4_CODE 16 16 16 8 16 16 16 8 No No No No No No No No Yes Yes Yes Yes Yes Yes Yes Yes Bits 6 through 7 of the IP ToS Field as defined in RFC 3168 if Ethertype = 0x0800 If Ethertype = 0x0800 and IP_PROTO = 6 f Ethertype = 0x0800 and IP_PROTO = 17 If Ethertype = 0x0800 and IP_PROTO = 132 If Ethertype = 0x0800 and IP_PROTO = 1 If Ethertype = 0x0800 and IP_PROTO = 6 if Ethertype = 0x0800 and IP_PROTO = 17 If Ethertype = 0x
SCTP_DST 16 No es ICMPv6_CODE 8 No es If Ethertype = 0x86dd and IP_PROTO = 132 If Ethertype = 0x86dd and IP_PROTO = 58 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.
The Policy ACL Flow Table counters are listed in Table 43. These are applicable to VLAN flow entries. Policy ACL Flow Table expiry provisions are shown in Table 44. Each flow entry can have its own time-out values.
4.4 Group Table Most forwarding actions are embodied in group table entries. DNOS-OF supports a defined set of group table entry types, effectively partitioning the group table into logical sub tables. Each group entry has an identifier, type, counters, and one or more action buckets. OpenFlow has a single monolithic group table, but DNOS-OF differentiates among types of group entries. For this purpose, DNOSOF encodes the group entry type in a group entry identifier field.
4.4.1 DNOS-OF flow tables DNOS-OF flow tables accommodate specific types of flow entries with associated semantic rules, including constraints such as which match fields are available, which instructions and actions are supported, how priorities can be assigned to flow entries, which next table(s) flow entries can go to, and so forth. The flow tables conform to the OpenFlow 1.3.4 specification.
4.4.2.1 Naming Convention Table 46 details the DNOS-OF L2 Interface group entry identifier subfields that encode combinations of egress port and VLAN ID. 4.4.2.2 Action Buckets The single action bucket specifies the output port, and whether or not the packet is egressed tagged. Although the pop action is a NOP if the packet has no VLAN tag, packets should always have a VLAN tag when the actions in the output group table are applied.
4.4.3 DNOS-OF L2 Rewrite Group Entries DNOS-OF L2 Rewrite group entries are of indirect type and have a single action bucket. They are used when it is desired to modify Ethernet header fields for bridged packets. Use of an DNOS-OF L2 Rewrite group entry is optional, and can only be a Policy ACL Flow Table action. DNOS-OF L2 Rewrite actions are optional with the exception of group. This permits an DNOS-OF L2 Rewrite group entry to selectively modify the source MAC, destination MAC, and/or VLAN ID.
4.4.4 DNOS-OF L3 Unicast Group Entries DNOS-OF L3 Unicast group entries are used to supply the routing next hop and output interface for packet forwarding. To properly route a packet from either the Routing Flow Table or the Policy ACL Flow Table, the forwarding flow entry must reference a DNOS-OF L3 Unicast Group entry. DNOS-OF L3 Unicast automatically includes the ALLOW-IN_PORT vendor extension property to allow packets to be sent out IN_PORT.
4.4.4.3 Counters The DNOS-OF L3 Unicast group entry counters are as shown in Table 54. 4.4.5 DNOS-OF L2 Multicast Group Entries DNOS-OF L2 multicast group entries are of OpenFlow ALL type. There can be multiple action buckets, each referencing an output port by chaining to a DNOS-OF L2 Interface Group entry. Note: By OpenFlow default, a packet cannot be forwarded back to the IN_PORT from which it came in. An action bucket that specifies the particular packet’s ingress port is not evaluated.
4.4.5.3 Counters The L2 Multicast group entry counters are as shown in Table 57. 4.4.6 DNOS-OF L2 Flood Group Entries The OF-DPA L2 Flood Group entries are used by VLAN Flow Table wildcard (destination location forwarding, or DLF) rules. Like OF-DPA L2 Multicast group entry types they are of OpenFlow ALL type. The action buckets each encode an output port. Each OF-DPA L2 Flood Group entry bucket forwards a replica to an output port, except for packet IN_PORT.
4.4.6.3 Counters The DNOS-OF L2 Multicast group entry counters are as shown in Table 60. 4.4.7 DNOS-OF L3 Interface Group Entries DNOS-OF L3 interface group entries are of indirect type and have a single action bucket. They are used to supply outgoing routing interface properties for multicast forwarding. For unicast forwarding, use of DNOSOF L3 Unicast group entries is recommended. DNOS-OF L3 Interface uses the ALLOW-IN-PORT vendor extension that permits packets to be sent out IN_PORT.
4.4.7.2 Action Buckets The single action bucket specifies the MAC_SRC, VLAN_VID, TTL decrement action, and an output group for forwarding the packet. All actions are required. Table 62: DNOS-OF L3 Interface Group Entry Bucket Actions Field Group Argument Group entry Set Field Set Field MAC_SRC Description Must chain to a L2 Interface group entry. This group entry can output the packet to IN_PORT. The VLAN id component of the chained group entry’s name must match the Set Field value for VLAN id.
4.4.8.1 Naming Convention The naming convention for DNOS-OF L3 Multicast Group entries is shown in Table 64. 4.4.8.2 Naming Convention The action buckets contain the values shown in Table 65. Table 65: DNOS-OF L3 Multicast Bucket Actions Field Group 4.4.8.1 Argument Group-id Description Can chain to one of: L3 Interface; L2 Interface. Chained group entry names must conform to the VLAN id requirements above. Counters The DNOS-OF L3 Multicast group entry counters are as shown in Table 66. 4.4.
4.4.9.1 Naming Convention The naming convention for DNOS-OF L3 ECMP Group entries is as shown in Table 67. Table 67: DNOS-OF L3 ECMP Group Entry Naming Convention 4.4.9.2 Field Id Bits [27:0] Type [31:28] Description Used to differentiate OF-DPA L3 ECMP group entries. 7 (OF-DPA L3 ECMP) Action Buckets The action buckets contain the single value listed in Table 68. Table 68. DNOS-OF L3 ECMP Group Entry Bucket Actions Field Group 4.4.9.
4.4.12 Ports This section lists the DNOS-OF supported properties for physical and reserved ports. 4.4.12.1 Physical Ports DNOS-OF supports physical ports that are available on specific target platforms. Ports are identified using a 32-bit ifNum value. The most significant two bytes indicate the type of port. Only physical ports are supported in DNOS-OF. Physical ports are front panel ports on the abstract switch. DNOS-OF supports the physical port features listed in Table 73.
4.4.12.2 Counters DNOS-OF supports the port counters listed in Table 75.
4.4.12.3 Reserved Ports DNOS-OF supports the reserved ports listed in Table 76. Table 76. DNOS-OF Reserved Ports Name ALL Required Yes IN_PORT Yes CONTROLLER Yes TABLE Yes ANY Yes LOCAL No NORMAL FLOOD No No Description Required but not supported in DNOS-OF. Used to send packets to the ingress port to override OpenFlow default behavior. DNOS-OF uses group ALLOW-IN_PORT property instead. Not to be confused with the IN_PORT match field. The OpenFlow controller.
4.4.13 Vendor Extension Features In many cases the vendor extension features only affect the OpenFlow abstract switch and can be accommodated by the existing OpenFlow 1.3.4 protocol. In others, an OpenFlow 1.3.4 agent and compatible controller can be extended using the OpenFlow Experimental facility to add new protocol elements as needed. DNOS-OF provides vendor extensions for source MAC learning, and L3 forwarding IN_PORT control. 4.4.13.
5 Installation, Configuration, Deployment Since the target delivery mechanism is the web download, the only thing needed other than the actual N series switch is the DNOS .STK firmware image file. This section shows how it is downloaded, configured and started. This firmware image file is identical to the standard N Series firmware image file format and is loaded and enabled the same way. The user can switch back and forth between the standard N-Series image .STK file and the DNOS-OF .
5.2 Install DNOS-OF To install from a TFTP server, copy the DNOS-OF image to the download directory of your TFTP server, then from the terminal or serial console of the switch use the “copy” command as shown below. This example puts the firmware into the backup partition on the switch: ZBA123_console> copy tftp:///DNOS-OF-xx.yy.zz.bb.
You can also see the management configuration information that is stored in the switch configuration and shown in the running configuration: "Management Interface": { "dhcp": false, "ip address": "172.25.11.94/27", "ip gateway": "172.25.11.254" }, "SSH Service": { "enabled": false }, "Telnet Service": { "enabled": true } 5.
5.5 Verifying the Switch to Controller Communications Once the firmware is installed, the management access is configured, and the controller access is configured, you can verify the status of the controller connection.
The controller communications channel goes through the OpenFlow connection handshake protocol (shown below) and should end up at HANDSHAKE_COMPLETE/CONNECTED with communications established. Next you need to verify that the switch shows up on the controller as an OpenFlow node. For the Ryu controller, in order to verify that the controller sees the switch and to obtain the unique datapath ID, you can use the controller’s REST API. To start Ryu with the REST API enabled, use the Ryu ofctl_rest.
The datapath ID of the switch is shown above as 160088049758712. This datapath ID uniquely identifies this switch node within the OpenFlow network and is used for all other OpenFlow ccommunications with the switch. Any REST capable interface will be able to access this, but for the following examples we use the Postman REST application. An example of accessing the switch stats and datapath ID using the Postman REST API application is also show below.
If you can read the switch node ID from the controller then you have established communications with the controller and can begin programming it for flows. For a continued example of setting up a simple end to end traffic L2 bridging flow, see Appendix B. 5.6 Logging Due to the requirement not to impact any of the existing N series firmware, the DNOS-OF switch maintains only a minimal set of in-memory trace logs that are accessible by engineering and support for internal program debugging.
5.6.1 View Logging Configuration 5.6.1.1 show logging Shows the current state of system logging. There are 8 levels and 4 different components that can be each be enabled or disabled independently for logging. The levels are 0-7 and the components are API, Mapping, OpenFlow Database, and Datapath. These can be seen in the output of the show logging command.
5.6.2.2 set logging level Sets the level that log messages are generated for during runtime. This only changes the values during this run of the system. To make this persistent in the running configuration use the set default logging level command. See the example below: FJ6K0Z1_console> set logging level set logging level command: valid levels are 0-7 5.6.
5.7.1 startup-config The initial switch configuration is stored in flash, in a file called startup-config.
5.7.2 running-config The switch configuration that it is currently running with is also stored in flash, in a file called running-config. If any changes are made to the switch configuration from the time it starts up it will be contained in this file. This running information can be saved as the default starup configuration by using the write command. The configuration parameters in the running config and are accessed through the various CLI commands.
5.7.3 backup-config The switch configuration can be saved off and also stored in flash, in a file called backup-config. This can be done using the “copy” command as shown below, and displayed using the show backup-config command.
A Appendix - DNOS-OF CLI Command Reference The following list of CLI commands below represent the those available in the latest DNOS-OF firmware. At any time, to get help on the DNOS-OF firmware from the command line interface, you can use the help command, as shown below: JFTP0Z1_console# help Special keys: DEL, BS Ctrl-A Ctrl-E Ctrl-F Ctrl-B Ctrl-D Ctrl-U, X Ctrl-K Ctrl-W Ctrl-P Ctrl-R Ctrl-N Ctrl-Z Tab ? .... .... .... .... .... .... .... .... .... .... .... .... .... .... ....
A.1 Commands boot top level command Examples JFTP0Z1_console# boot boot possible subcommands: system select system partition to boot boot system Use the boot system command to specify the system image that the switch loads at bootup. Syntax boot system boot system User Guidelines Use the show bootvar or show version commands to find out which images are in the active and backup partitions.
clear openflow statistics Use the clear openflow statistics command to clear all openflow data structures Examples JFTP0Z1_console# clear openflow clear openflow possible subcommands: statistics clear openflow statistics counters JFTP0Z1_console# clear openflow statistics Clearing all OpenFlow statistics Clearing OpenFlow flow statistics for all flow tables Clearing OpenFlow port statistics Clearing all openflow statistics Clearing queue statistics for all ports Clearing OpenFlow statistics for
crypto top level command Example: JFTP0Z1_console# crypto crypto possible subcommands: key system crypto key management JFTP0Z1_console# crypto key crypto key possible subcommands: generate generate ssh server encrytion keys zeroize remove the ssh server encryption crypto key generate Use the crypto key generate command to generate server encryption keys Examples JFTP0Z1_console> crypto key generate crypto key zeroize Use the crypto key zeroize command to remove the keys.
debug ip Use the debug ip command to show the subcommands available under debug ip. Examples JFTP0Z1_console# debug ip debug ip possible subcommands: ping traceroute check accessibility of a network node check routed path of a network node debug ip ping Use the debug ip ping command to check the accessibility of a network node via the management port.
dir top level command Use the dir command to list files in the file system.
reload set show system unmount write shutdown and restart the system configure system settings show system information change system settings unmount usb device save configuration to local storage mount top level command Displays the available subcommands for the mount command. Examples JFTP0Z1_console> mount mount possible subcommands: usb mount usb drive mount usb Use the mount usb command to mount the usb file system.
no ip gateway This command removes the default gateway from the management port. Examples FJ6K0Z1_console> no ip gateway no ip gateway Remove the default gateway from the management port. no ip ssh server This command disables the SSH server on the management port. Examples FJ6K0Z1_console> no ip ssh no ip ssh possible subcommands: server disable the ssh server on the management port no ip syslog service This command removes remote syslog service settings.
set top level command Displays the available subcommands for the set command. Examples FJ6K0Z1_console> set set possible subcommands: default ip logging openflow password set set set set set system default logging settings system ip settings system logging settings system openflow settings password for remote ssessions set clock Sets the system date and time.Use the set default logging components command to change the default logging components that are enabled when the system starts.
set default logging level Use the set default logging level command to change the default logging level that the switch uses when the system starts. Examples FJ6K0Z1_console> set default logging level set default logging level Set the default logging level. This is the persistent log level that the switch initializes to by default when it starts up.
set ip ssh server Use to enable the ssh server on the management port and store that state to the switch configuration. Examples FJ6K0Z1_console> set ip ssh ? set ip ssh possible subcommands: server enable the ssh server on the management port set ip syslog service Use to enable the syslog service on the management port and store that state to the switch configuration.
set logging level Use this API to set the runtime logging level for the switch until rebooted. Use the “set default logging …” command to store the setting into the system flash running-donfiguration Examples FJ6K0Z1_console> set logging level set logging level Set the logging level. Values above 3 should probably not be turned on for serial port backed IO like screen consoles/maintenance ports.
set openflow controller Use the set openflow controller command to point the DNOS-OF switch to where the controller it is supposed to connect to resides. Examples FJ6K0Z1_console> set openflow controller 172.25.11.93 6633 08-07 22:00:22.036504 ofconnectionmanager: INFO: cxn 172.25.11.93:6633: DISCONNECTED 08-07 22:00:22.078219 ofconnectionmanager: INFO: cxn 172.25.11.
show backup-config command Shows the data stored in the backup configuration Examples FJ6K0Z1_console> show backup-config { "Default Logging": { "components": { "API": true, "Mapping": true, "OFDB": true, "datapath": true }, "level": 1 }, "Management Interface": { "dhcp": true, "ip address": "", "ip gateway": "" }, "OpenFlow Controller": { "connection max retries": 0, "connection retry interval": 2000, "enabled": true, "ip address": "198.18.3.
show clock command Shows the current time and date on the system. Examples FJ6K0Z1_console> show clock Sat Aug 15 01:53:33 2015 show crypto key command Prints the SSH server encryption key. Note that the “crypto key generate” command allows this key to be created, while the “crypto key zeroize” command clears it.
show interfaces configuration command Shows the interfaces configuration information. Examples FJ6K0Z1_console> show interfaces show interfaces possible subcommands: configuration show interfaces configuration information status show interfaces status information switchport show operational status of an interface FJ6K0Z1_console> show interfaces configuration ? show interfaces configuration Show configuration information for all available interfaces.
show interfaces status command Shows the interfaces status information. Examples FJ6K0Z1_console> show interfaces status Show interfaces status Show status information for all available interfaces.
show openflow top level command Displays the show commands available for OpenFlow Examples FJ6K0Z1_console> show openflow Incomplete command! possible subcommands: config show flows show statistics show tables show openlow configuration openflow flows openflow statistics openflow table information show openflow config command Shows information about the openflow configuration and processes, as well as information about the OpenFlow controller interfaces active in DNOS-OF.
show openflow tables command Shows information about the openflow tables available, supported in DNOS-OF.
show openflow flows command Shows information about the entire contents of the openflow flow database.
show openflow statistics command Shows what openflow statistics are available from DNOS-OF given certain qualifier arguments. See below.
Port:2, Port:2, Port:2, Port:2, . .
show power inline command Show power inline settings and usage from the PoE controller. Examples FJ6K0Z1_console> show power inline Port Watts PoE Status ---- ----- ---------1 0.0 off (detecting) 2 0.0 off (detecting) 3 0.0 off (detecting) 4 0.0 off (detecting) 5 0.0 off (detecting) 6 0.0 off (detecting) 7 0.0 off (detecting) 8 0.0 off (detecting) 9 0.0 off (detecting) 10 0.0 off (detecting) 11 0.0 off (detecting) 12 0.0 off (detecting) 13 0.0 off (detecting) 14 0.0 off (detecting) 15 0.
10 11 13 14 16 19 138 140 148 169 170 196 246 250 257 645 883 888 893 898 903 908 918 923 948 972 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 root root root root root root root root root root root root root root root root root root root root root root root root root root SW SW< SW< SW< SW< SW SW SW< SW SW< SW< SW SW SW< SW< SW< SW SW SW SW SW SW SW< SW SW SW< 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0%
show running-config command Shows the data stored currenty in the running configuration Examples FJ6K0Z1_console> show running-config { "Default Logging": { "components": { "API": true, "Mapping": true, "OFDB": true, "datapath": true }, "level": 1 }, "Management Interface": { "dhcp": true, "ip address": "", "ip gateway": "" }, "OpenFlow Controller": { "connection max retries": 0, "connection retry interval": 2000, "enabled": true, "ip address": "198.18.3.
show startup-config command Shows the data stored for the configuration that the switch will use when it boots up next time. Examples FJ6K0Z1_console> show startup-config { "Default Logging": { "components": { "API": true, "Mapping": true, "OFDB": true, "datapath": true }, "level": 1 }, "Management Interface": { "dhcp": true, "ip address": "", "ip gateway": "" }, "OpenFlow Controller": { "connection max retries": 0, "connection retry interval": 2000, "enabled": true, "ip address": "198.18.3.
show statistics possible subcommands: switchport show statistics for the switch FJ6K0Z1_console> show statistics switchport 1 Total Packets Received (Octets)..........0 Packets Received Without Error...........0 Unicast Packets Received.................0 Multicast Packets Received...............0 Broadcast Packets Received...............0 Receive Packets Discarded................0 Octets Trasmitted........................0 Packets Trasmitted Without Error.........0 Unicast Packets Trasmitted...
show tech-support command Lists out information showing the state of the system. This is a very comprehensive dump of everything listed here under the “show’ commands along with internal debugging information and other information about the system. Examples FJ6K0Z1_console> show tech-support . . . show version command Displays the versions of firmware on the switch. Examples FJ6K0Z1_console> show version Machine Description...............
system clock command Allows the user to configure current system time and date. Examples FJ6K0Z1_console> system clock Incomplete command! possible subcommands: date time set the system date set the system time system locate command Starts a beacon timer running for the specified number of seconds to allow the ystem to be located in the racks. Examples FJ6K0Z1_console> system locate system locate
B Appendix – Setting up flows with the DNOS-OF SDN Agent, Ryu SDN Controller, and Ryu REST API The following shows annotated console extracts of installing the Ryu 3.23 controller, setting up the Ryu REST API JSON parser, connecting the DNOS-OF switch agent to the Ryu controller, setting up sone test flows, and shows some other useful utility commands available through the Ryu controller. This example is shown running on a Debian Linux machine but also runs fine on Ubuntu and CentOS. 1. Ryu 3.23.
PROVIDES EventOFPMeterConfigStatsReply TO {'RestStatsApi': set(['main'])} PROVIDES EventOFPPortStatsReply TO {'RestStatsApi': set(['main'])} PROVIDES EventOFPAggregateStatsReply TO {'RestStatsApi': set(['main'])} PROVIDES EventOFPQueueStatsReply TO {'RestStatsApi': set(['main'])} PROVIDES EventOFPStatsReply TO {'RestStatsApi': set(['main'])} PROVIDES EventOFPDescStatsReply TO {'RestStatsApi': set(['main'])} PROVIDES EventOFPMeterStatsReply TO {'RestStatsApi': set(['main'])} PROVIDES EventOFPGroupStatsReply
07-13 21:38:59.312255 of-switch: MSG: src/of-switch/OF_SDNController.cpp:Connect:Initializing controller 172.25.11.93:6633 07-13 21:38:59.312482 ofconnectionmanager: INFO: Added remote connection: 172.25.11.93:6633 07-13 21:39:00.336444 ofconnectionmanager: INFO: cxn 172.25.11.93:6633: DISCONNECTED->CONNECTING 07-13 21:39:00.453541 ofconnectionmanager: INFO: cxn 172.25.11.93:6633: CONNECTING>HANDSHAKE_COMPLETE And something like the following on the Ryu console: (20961) wsgi starting up on http://0.0.0.
{ "dpid": 133571005559288, "cookie": 1, "cookie_mask": 1, "table_id": 10, "idle_timeout": 30, "hard_timeout": 30, "priority": 1, "flags": 1, "_name" : "vlan10", "cmd" : "add", "mask" : "0", "port" : "any", "group" : "any", "match": { "in_port" : "10", "vlan_vid" : "2" }, "instructions": [ { "goto": { "table_id":"20" } } ] } 1) To fetch the switch description we can use the below cURL command on controller console.
Here group_delete.
C Appendix - Example of setting up a basic Ethernet L2 Bridging topology for end to end traffic The following section illustrates how to establish an end to end traffic flow using basic Ethernet Layer 2 bridging. The Ryu controller, a web browser and the REST API web utility Postman are used in these examples, but any OpenFlow 1.3.4 compliant controller and REST API tool can be used. Note: that Ryu 3.
C.2 Step 1 - Set up a VLAN flow The script below shows the JSON code that is used to create the first flow, in the VLAN table (table 10 in the SOC).
Finally the body of the flow request is filled in with our REST flow add request, as shown below: To send the flow add request to the switch via the controller, hit the Send button. You should see a couple of things at this point. On the switch console, if the flow is successfully added, you will see something like the following: FJ6K0Z1_console> 08-10 19:39:56.799895 indigo_ofdpa_driver: MSG: src/indigo/ofdpadriver/ind_ofdpa_fwd.c:indigo_fwd_flow_create:flow ID=10 08-10 19:39:56.
To verify the flow that was indeed added to the switch, the show openflow flows command can be used as shown below: FJ6K0Z1_console> show openflow flows Showing openflow flow entries for all tables Ingress Port Table (0) Flow Entries ---------------------------------Number of entries reported = 0 Maximum number of entries for this table = 2000 Number of entries actually found = 0 VLAN Table (10) Flow Entries -------------------------------------Number of entries reported = 0 Maximum number of entries for th
Maximum number of entries for this table = 32767 Number of entries actually found = 0 ACL Policy Table (60) Flow Entries ---------------------------------Number of entries reported = 0 Maximum number of entries for this table = 7680 Number of entries actually found = 0 What this flow does in he switch, is to say that anything coming into port 2 on VLAN 10 should be forwarded on via the GOTO TABLE statement to the Termination MAC table, table ID 20, C.
D Appendix - additional resources Dell.com/spport Dell is focused on meeting your needs with proven services and support. DellTechCenter.com is an IT Community where you can connect with Dell Customers and Dell employees for the purpose of sharing knowledge, best practices, and information about Dell products and installations. Referenced and/or recommended DNOS-OF, SDN, OpenFlow and OF-DPA publications: ONF site: https://www.opennetworking.org/ Broadcom OFDPA site: https://github.
