1OVS-TEST(8)                      Open vSwitch                      OVS-TEST(8)
2
3
4

NAME

6       ovs-test  -  Check Linux drivers for performance, vlan and L3 tunneling
7       problems
8

SYNOPSIS

10       ovs-test -s port
11
12       ovs-test -c server1 server2 [-b targetbandwidth] [-i testinterval] [-d]
13              [-l vlantag] [-t tunnelmodes]
14

DESCRIPTION

16       The ovs-test program may be used to check for problems  sending  802.1Q
17       or GRE traffic that Open vSwitch may uncover. These problems, for exam‐
18       ple, can occur when Open vSwitch is used to send 802.1Q traffic through
19       physical  interfaces  running  certain  drivers of certain Linux kernel
20       versions.  To run a test, configure IP addresses on server1 and server2
21       for interfaces you intended to test. These interfaces could also be al‐
22       ready configured OVS bridges that have a physical interface attached to
23       them. Then, on one of the nodes, run ovs-test in server mode and on the
24       other node run it in client mode. The client will connect  to  ovs-test
25       server  and  schedule  tests  between both of them. The ovs-test client
26       will perform UDP and TCP tests.
27
28       UDP tests can report packet loss and  achieved  bandwidth  for  various
29       datagram sizes. By default target bandwidth for UDP tests is 1Mbit/s.
30
31       TCP  tests  report  only  achieved  bandwidth, because kernel TCP stack
32       takes care of flow control and packet loss. TCP tests are essential  to
33       detect potential TSO related issues.
34
35       To  determine  whether  Open  vSwitch is encountering any problems, the
36       user must compare packet loss and achieved bandwidth in a  setup  where
37       traffic  is  being  directly sent and in one where it is not. If in the
38       802.1Q or L3 tunneled tests both ovs-test processes are unable to  com‐
39       municate  or  the  achieved  bandwidth is much lower compared to direct
40       setup, then, most likely, Open vSwitch has encountered  a  pre-existing
41       kernel or driver bug.
42
43       Some examples of the types of problems that may be encountered are:
44
45       • When NICs use VLAN stripping on receive they must pass a pointer to a
46         vlan_group when reporting the stripped tag to the networking core. If
47         no  vlan_group  is  in  use then some drivers just drop the extracted
48         tag.  Drivers are supposed to only enable stripping if  a  vlan_group
49         is registered but not all of them do that.
50
51       • On receive, some drivers handle priority tagged packets specially and
52         don’t pass the tag onto the network stack at  all,  so  Open  vSwitch
53         never has a chance to see it.
54
55       • Some drivers size their receive buffers based on whether a vlan_group
56         is enabled, meaning that a maximum size packet with a VLAN  tag  will
57         not fit if no vlan_group is configured.
58
59       • On  transmit, some drivers expect that VLAN acceleration will be used
60         if it is available, which can only be done if a vlan_group is config‐
61         ured.  In  these  cases,  the driver may fail to parse the packet and
62         correctly setup checksum offloading or TSO.
63
64       Client Mode
65              An ovs-test client will connect to two ovs-test servers and will
66              ask  them to exchange test traffic. It is also possible to spawn
67              an ovs-test server automatically from the client.
68
69       Server Mode
70              To conduct tests, two ovs-test servers must be  running  on  two
71              different  hosts  where  the client can connect. The actual test
72              traffic is exchanged only between both ovs-test servers.  It  is
73              recommended  that  both  servers  have their IP addresses in the
74              same subnet, otherwise one would have to make sure that  routing
75              is set up correctly.
76

OPTIONS

78       -s <port>, --server <port>
79              Run  in server mode and wait for the client to establish XML RPC
80              Control Connection on this TCP port. It is recommended  to  have
81              ethtool(8) installed on the server so that it could retrieve in‐
82              formation about the NIC driver.
83
84       -c <server1> <server2>, --client <server1> <server2>
85              Run in client  mode  and  schedule  tests  between  server1  and
86              server2,  where  each server must be given in the following for‐
87              mat:
88
89                 OuterIP[:OuterPort],InnerIP[/Mask][:InnerPort].
90
91              The OuterIP must be already assigned to the  physical  interface
92              which is going to be tested. This is the IP address where client
93              will  try  to  establish  XML  RPC  connection.  If  OuterIP  is
94              127.0.0.1  then client will automatically spawn a local instance
95              of ovs-test server.  OuterPort is TCP port where server is  lis‐
96              tening  for  incoming  XML/RPC  control  connections to schedule
97              tests (by default it is 15531). The ovs-test will  automatically
98              assign  InnerIP[/Mask] to the interfaces that will be created on
99              the  fly  for  testing  purposes.  It  is  important  that   In‐
100              nerIP[/Mask]  does  not  interfere  with already existing IP ad‐
101              dresses on both ovs-test servers and client. InnerPort  is  port
102              which  will  be  used  by server to listen for test traffic that
103              will be encapsulated (by default it is 15532).
104
105       -b <targetbandwidth>, --bandwidth <targetbandwidth>
106              Target bandwidth for UDP  tests.  The  targetbandwidth  must  be
107              given  in  bits per second. It is possible to use postfix M or K
108              to alter the target bandwidth magnitude.
109
110       -i <testinterval>, --interval <testinterval>
111              How long each test should run. By default 5 seconds.
112
113       -h, --help
114              Prints a brief help message to the console.
115
116       -V, --version
117              Prints version information to the console.
118
119       The following test modes are supported by ovs-test. It is  possible  to
120       combine multiple of them in a single ovs-test invocation.
121
122       -d, --direct
123              Perform direct tests between both OuterIP addresses. These tests
124              could be used as a reference to compare 802.1Q or  L3  tunneling
125              test results.
126
127       -l <vlantag>, --vlan-tag <vlantag>
128              Perform 802.1Q tests between both servers. These tests will cre‐
129              ate a temporary OVS bridge, if  necessary,  and  attach  a  VLAN
130              tagged port to it for testing purposes.
131
132       -t <tunnelmodes>, --tunnel-modes <tunnelmodes>
133              Perform  L3 tunneling tests. The given argument is a comma sepa‐
134              rated string that specifies all the L3 tunnel modes that  should
135              be  tested  (e.g.  gre). The L3 tunnels are terminated on inter‐
136              face that has the OuterIP address assigned.
137

EXAMPLES

139       On host 1.2.3.4 start ovs-test in server mode:
140
141          ovs-test -s 15531
142
143       On host 1.2.3.5 start ovs-test in client mode and do direct,  VLAN  and
144       GRE tests between both nodes:
145
146          ovs-test -c 127.0.0.1,1.1.1.1/30 1.2.3.4,1.1.1.2/30 -d -l 123 -t
147          gre
148

SEE ALSO

150       ovs-vswitchd(8), ovs-ofctl(8), ovs-vsctl(8), ovs-vlan-test, ethtool(8),
151       uname(1)
152

AUTHOR

154       The Open vSwitch Development Community
155
157       2016-2022, The Open vSwitch Development Community
158
159
160
161
1622.17                             Jul 22, 2022                      OVS-TEST(8)
Impressum