utilities/ovs-test.8.in

   1 .de IQ
   2 .  br
   3 .  ns
   4 .  IP "\\$1"
   5 ..
   6 .TH ovs\-test 1 "October 2011" "Open vSwitch" "Open vSwitch Manual"
   7 .
   8 .SH NAME
   9 \fBovs\-test\fR \- check Linux drivers for performance and vlan problems
  10 .
  11 .SH SYNOPSIS
  12 \fBovs\-test\fR \fB\-s\fR \fIport\fR
  13 .PP
  14 \fBovs\-test\fR \fB\-c\fR \fIserver1\fR
  15 \fIserver2\fR [\fB\-b\fR \fIbandwidth\fR]
  16 .so lib/common-syn.man
  17 .
  18 .SH DESCRIPTION
  19 The \fBovs\-test\fR program may be used to check for problems sending
  20 802.1Q traffic that Open vSwitch may uncover. These problems can
  21 occur when Open vSwitch is used to send 802.1Q traffic through physical
  22 interfaces running certain drivers of certain Linux kernel versions. To run a
  23 test, configure Open vSwitch to tag traffic originating from \fIserver1\fR and
  24 forward it to the \fIserver2\fR. On both servers run \fBovs\-test\fR
  25 in server mode. Then, on any other host, run the \fBovs\-test\fR in client
  26 mode. The client will connect to both \fBovs\-test\fR servers and schedule
  27 tests between them. \fBovs\-test\fR will perform UDP and TCP tests.
  28 .PP
  29 UDP tests can report packet loss and achieved bandwidth, because UDP flow
  30 control is done inside \fBovs\-test\fR. It is also possible to specify target
  31 bandwidth for UDP. By default it is 1Mbit/s.
  32 .PP
  33 TCP tests report only achieved bandwidth, because kernel TCP stack
  34 takes care of flow control and packet loss. TCP tests are essential to detect
  35 potential TSO related VLAN issues.
  36 .PP
  37 To determine whether Open vSwitch is encountering any 802.1Q related problems,
  38 the user must compare packet loss and achieved bandwidth in a setup where
  39 traffic is being tagged against one where it is not. If in the tagged setup
  40 both servers are unable to communicate or the achieved bandwidth is lower,
  41 then, most likely, Open vSwitch has encountered a pre-existing kernel or
  42 driver bug.
  43 .PP
  44 Some examples of the types of problems that may be encountered are:
  45 .so utilities/ovs-vlan-bugs.man
  46 .
  47 .SS "Client Mode"
  48 An \fBovs\-test\fR client will connect to two \fBovs\-test\fR servers and
  49 will ask them to exchange traffic.
  50 .
  51 .SS "Server Mode"
  52 To conduct tests, two \fBovs\-test\fR servers must be running on two different
  53 hosts where client can connect. The actual test traffic is exchanged only
  54 between both \fBovs\-test\fR server test IP addresses. It is recommended that
  55 both servers have their test IP addresses in the same subnet, otherwise one
  56 will need to change routing so that the test traffic actually goes through the
  57 interface that he originally intended to test.
  58 .
  59 .SH OPTIONS
  60 .
  61 .IP "\fB\-s \fIport\fR"
  62 .IQ "\fB\-\-server\fR \fIport\fR"
  63 Run in server mode and wait for a client to establish XML RPC Control
  64 Connection on TCP \fIport\fR. It is recommended to have ethtool installed on
  65 the server so that it could retrieve information about NIC driver.
  66 .
  67 .IP "\fB\-c \fIserver1\fR \fIserver2\fR"
  68 .IQ "\fB\-\-client \fIserver1\fR \fIserver2\fR"
  69 Run in client mode and schedule tests between \fIserver1\fR and \fIserver2\fR,
  70 where each \fIserver\fR must be given in following format -
  71 ControlIP[:ControlPort][,TestIP[:TestPort]]. If TestIP is omitted then
  72 ovs-test server will use the ControlIP for testing purposes. ControlPort is
  73 TCP port where server will listen for incoming XML/RPC control
  74 connections to schedule tests (by default it is 15531). TestPort
  75 is port which will be used by server to listen for test traffic
  76 (by default it is 15532).
  77 .
  78 .IP "\fB\-b \fIbandwidth\fR"
  79 .IQ "\fB\-\-bandwidth\fR \fIbandwidth\fR"
  80 Target bandwidth for UDP tests. The \fIbandwidth\fR must be given in bits per
  81 second. It is possible to use postfix M or K to alter the target bandwidth
  82 magnitude.
  83 .
  84 .so lib/common.man
  85 .SH EXAMPLES
  86 .PP
  87 Set up a bridge which forwards traffic originating from \fB1.2.3.4\fR out
  88 \fBeth1\fR with VLAN tag 10.
  89 .IP
  90 .B ovs\-vsctl \-\- add\-br vlan\-br \(rs
  91 .IP
  92 .B \-\- add\-port vlan\-br eth1 \(rs
  93 .IP
  94 .B \-\- add\-port vlan\-br vlan\-br\-tag tag=10 \(rs
  95 .IP
  96 .B \-\- set Interface vlan\-br\-tag type=internal
  97 .IP
  98 .B ifconfig vlan\-br\-tag up 1.2.3.4
  99 .
 100 .PP
 101 On two different hosts start \fBovs\-test\fR in server mode and tell them to
 102 listen on port 15531 for incoming client control connections:
 103 .IP
 104 .B 1.2.3.4: ovs\-test \-s 15531
 105 .IP
 106 .B 1.2.3.5: ovs\-test \-s 15531
 107 .
 108 .PP
 109 On any other host start \fBovs\-test\fR in client mode and ask it to connect
 110 to those two servers - one at 1.2.3.4 and another at 1.2.3.5 (by default
 111 client will use TCP port 15531 to establish control channel).
 112 .IP
 113 .B ovs\-test -c 1.2.3.4 1.2.3.5
 114 .
 115 .SH SEE ALSO
 116 .
 117 .BR ovs\-vswitchd (8),
 118 .BR ovs\-ofctl (8),
 119 .BR ovs\-vsctl (8),
 120 .BR ovs\-vlan\-test (8),
 121 .BR ethtool (8),
 122 .BR uname (1)