ovs-test(1)							Open vSwitch Manual						       ovs-test(1)

NAME

       ovs-test - check Linux drivers for performance and vlan problems

SYNOPSIS

       ovs-test -s port

       ovs-test -c server1 server2 [-b bandwidth]

       Common options:
	      [-h | --help] [-V | --version]

DESCRIPTION

       The  ovs-test program may be used to check for problems sending 802.1Q traffic that Open vSwitch may uncover. These problems can occur when
       Open vSwitch is used to send 802.1Q traffic through physical interfaces running certain drivers of certain Linux kernel versions. To run  a
       test,  configure Open vSwitch to tag traffic originating from server1 and forward it to the server2. On both servers run ovs-test in server
       mode. Then, on any other host, run the ovs-test in client mode. The client will connect to both ovs-test servers and schedule tests between
       them. ovs-test will perform UDP and TCP tests.

       UDP  tests  can report packet loss and achieved bandwidth, because UDP flow control is done inside ovs-test. It is also possible to specify
       target bandwidth for UDP. By default it is 1Mbit/s.

       TCP tests report only achieved bandwidth, because kernel TCP stack takes care of flow control and packet loss. TCP tests are  essential	to
       detect potential TSO related VLAN issues.

       To  determine whether Open vSwitch is encountering any 802.1Q related problems, the user must compare packet loss and achieved bandwidth in
       a setup where traffic is being tagged against one where it is not. If in the tagged setup both servers are unable  to  communicate  or  the
       achieved bandwidth is lower, then, most likely, Open vSwitch has encountered a pre-existing kernel or driver bug.

       Some examples of the types of problems that may be encountered are:

       o      When  NICs  use VLAN stripping on receive they must pass a pointer to a vlan_group when reporting the stripped tag to the networking
	      core.  If no vlan_group is in use then some drivers just drop the extracted tag.	Drivers are supposed to only enable stripping if a
	      vlan_group is registered but not all of them do that.

       o      On  receive,  some  drivers  handle  priority tagged packets specially and don't pass the tag onto the network stack at all, so Open
	      vSwitch never has a chance to see it.

       o      Some drivers size their receive buffers based on whether a vlan_group is enabled, meaning that a maximum size packet with a VLAN tag
	      will not fit if no vlan_group is configured.

       o      On  transmit,  some drivers expect that VLAN acceleration will be used if it is available, which can only be done if a vlan_group is
	      configured.  In these cases, the driver may fail to parse the packet and correctly setup checksum offloading or TSO.

   Client Mode
       An ovs-test client will connect to two ovs-test servers and will ask them to exchange traffic.

   Server Mode
       To conduct tests, two ovs-test servers must be running on two different hosts  where  client  can  connect.  The  actual  test  traffic	is
       exchanged only between both ovs-test server test IP addresses. It is recommended that both servers have their test IP addresses in the same
       subnet, otherwise one will need to change routing so that the test traffic actually goes through the interface that he originally  intended
       to test.

OPTIONS

       -s, --server port
	      Run  in  server  mode  and  wait for a client to establish XML RPC Control Connection on TCP port. It is recommended to have ethtool
	      installed on the server so that it could retrieve information about NIC driver.

       -c, --client server1 server2
	      Run in client mode and schedule tests between server1 and server2, where each server must  be  given  in	following  format  -  Con-
	      trolIP[:ControlPort][,TestIP[:TestPort]].  If  TestIP  is  omitted then ovs-test server will use the ControlIP for testing purposes.
	      ControlPort is TCP port where server will listen for incoming XML/RPC control connections  to  schedule  tests  (by  default  it	is
	      15531). TestPort is port which will be used by server to listen for test traffic (by default it is 15532).

       -b, --bandwidth bandwidth
	      Target  bandwidth  for  UDP tests. The bandwidth must be given in bits per second. It is possible to use postfix M or K to alter the
	      target bandwidth magnitude.

       -h, --help
	      Prints a brief help message to the console.

       -V, --version
	      Prints version information to the console.

EXAMPLES

       Set up a bridge which forwards traffic originating from 1.2.3.4 out eth1 with VLAN tag 10.

	      ovs-vsctl -- add-br vlan-br 

	      -- add-port vlan-br eth1 

	      -- add-port vlan-br vlan-br-tag tag=10 

	      -- set Interface vlan-br-tag type=internal

	      ifconfig vlan-br-tag up 1.2.3.4

       On two different hosts start ovs-test in server mode and tell them to listen on port 15531 for incoming client control connections:

	      1.2.3.4: ovs-test -s 15531

	      1.2.3.5: ovs-test -s 15531

       On any other host start ovs-test in client mode and ask it to connect to those two servers - one at 1.2.3.4  and  another  at  1.2.3.5  (by
       default client will use TCP port 15531 to establish control channel).

	      ovs-test -c 1.2.3.4 1.2.3.5

       SEE ALSO
	      ovs-vswitchd(8), ovs-ofctl(8), ovs-vsctl(8), ovs-vlan-test(8), ethtool(8), uname(1)

Open vSwitch							   October 2011 						       ovs-test(1)