There are several command-line options for Open vSwitch as it has become a very popular software-based switch for projects such as OpenStack networking and OpenFlow. There are three popular command-line tools for Open vSwitch administration:

1. ovs-vsctl: This configures Open vSwitch parameters such as ports, adding or deleting bridges, and VLAN tagging
2. ovs-dpctl: This configures the data path of Open vSwitch, such as showing the currently installed flows
3. ovs-ofctl: This combines the functions of ovs-vsctl as well as
   
   ovs-dpctl but is meant for OpenFlow switches, thus the of in the name

Let's continue to use the Layer 2 switch example as before and look at some examples of the command-line tools. First up, let's look at ovs-vsctl and ovs-dpctl for configuring and querying Open vSwitch:

$ ovs-vsctl -V
ovs-vsctl (Open vSwitch) 2.3.90
Compiled Jan 8 2015 11:52:49
DB Schema 7.11.1

$ sudo ovs-vsctl show
873c293e-912d-4067-82ad-d1116d2ad39f
    Bridge "s1"
        Controller "ptcp:6634"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "s1"
            Interface "s1"
                type: internal
 ...

You can also query a specific switch for more information:

ubuntu@sdnhubvm:~[12:43]$ sudo ovs-vsctl list-br
 s1

ubuntu@sdnhubvm:~[12:43]$ sudo ovs-vsctl list-ports s1
 s1-eth1
 s1-eth2
 s1-eth3

ubuntu@sdnhubvm:~[12:43]$ sudo ovs-vsctl list interface
 _uuid : 399a3edc-8f93-4984-a646-b54cb35cdc4c
 admin_state : up
 bfd : {}
 bfd_status : {}
 cfm_fault : []
 cfm_fault_status : []
 ...

ubuntu@sdnhubvm:~[12:44]$ sudo ovs-dpctl dump-flows
 flow-dump from pmd on cpu core: 32767
 recirc_id(0),in_port(2),eth(dst=00:00:00:00:00:02),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:1
 recirc_id(0),in_port(1),eth(dst=00:00:00:00:00:01),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:98, used:2.316s, actions:2

By default, OVS supports OpenFlow 1.0 and 1.3. One of the useful things you can use ovs-vsctl to do, for example, is to force Open vSwitch to support OpenFlow 1.3 only (we will look at ovs-ofctl in a bit; here we are just using it to verify the OpenFlow version):

 $ sudo ovs-ofctl show s1
 OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000001
 $ sudo ovs-vsctl set bridge s1 protocols=OpenFlow13
 $ sudo ovs-ofctl show s1
 2017-03-30T21:55:20Z|00001|vconn|WARN|unix:/var/run/openvswitch/s1.mgmt: version negotiation failed (we support version 0x01, peer supports version 0x04)

As an alternative, you can also use the ovs-ofctl command-line tools for OpenFlow switches:

$ sudo ovs-ofctl show s1
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000001
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src 
...

$ sudo ovs-ofctl dump-flows s1
 NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=790.374s, table=0, n_packets=4, n_bytes=280, idle_age=785, priority=1,in_port=2,dl_dst=00:00:00:00:00:01 actions=output:1
 cookie=0x0, duration=790.372s, table=0, n_packets=3, n_bytes=238, idle_age=785, priority=1,in_port=1,dl_dst=00:00:00:00:00:02 actions=output:2
 cookie=0x0, duration=1037.897s, table=0, n_packets=3, n_bytes=182, idle_age=790, priority=0 actions=CONTROLLER:65535

As you can see from the output, the flows are unidirectional. Even though the communication happens bidirectionally (h1 to h2 and from h2 back to h1), the flows are installed individually. There is one flow from h1 to h2, and another flow from h2 to h1; together, they form a bidirectional communication. As network engineers, who sometimes take for granted that a forward path from a source to destination does not necessarily guarantee a return path in the case of OpenFlow or any other network application, bidirectional communication needs to be kept in mind.

Two other points to note about the flow output are as follows:

• dpid represents the identification of the switch. If we have multiple switches, they will be differentiated by dpid.
• Also note the mac address of the hosts. Because we use the --mac option, host 1 has mac address 00:00:00:00:00:01 and host 2 has mac address of 00:00:00:00:00:02, which makes it very easy to identify the hosts at the layer 2 level:

 OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000001
 recirc_id(0),in_port(2),eth(dst=00:00:00:00:00:02),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:1
 recirc_id(0),in_port(1),eth(dst=00:00:00:00:00:01),eth_type(0x0800),ipv4(frag=no), packets:1, bytes:98, used:2.316s, actions:2

The command-line tools are very useful when you need to configure the switch manually for both switch parameters as well as datapath, say, adding or deleting a flow manually. The analogy I would like to make is they are similar to out-of-band management of a physical switch. They are helpful when you need to either isolate the controller or the switch for troubleshooting. They are also useful when you are writing your own network application, as we will do later in this chapter, to verify that the controller is instructing the switch to install flows as expected.

We have seen the process of launching a typical Mininet network with a Layer 2 learning switch as well as command-line tools to verify switch operations. Now let's take a look at launching different applications via ryu-manager.