1ovs-test(1) Open vSwitch Manual ovs-test(1)
2
6 ovs-test - check Linux drivers for performance, vlan and L3 tunneling
7 problems
8
10 ovs-test -s port
11 ovs-test -c server1 server2 [-b targetbandwidth] [-i testinterval] [-d]
13 [-l vlantag] [-t tunnelmodes]
14 Common options:
16 [-h | --help] [-V | --version]
17
20 The ovs-test program may be used to check for problems sending 802.1Q
21 or GRE traffic that Open vSwitch may uncover. These problems, for exam‐
22 ple, can occur when Open vSwitch is used to send 802.1Q traffic through
23 physical interfaces running certain drivers of certain Linux kernel
24 versions. To run a test, configure IP addresses on server1 and server2
25 for interfaces you intended to test. These interfaces could also be
26 already configured OVS bridges that have a physical interface attached
27 to them. Then, on one of the nodes, run ovs-test in server mode and on
28 the other node run it in client mode. The client will connect to
29 ovs-test server and schedule tests between both of them. The ovs-test
30 client will perform UDP and TCP tests.
31 UDP tests can report packet loss and achieved bandwidth for various
33 datagram sizes. By default target bandwidth for UDP tests is 1Mbit/s.
34 TCP tests report only achieved bandwidth, because kernel TCP stack
36 takes care of flow control and packet loss. TCP tests are essential to
37 detect potential TSO related issues.
38 To determine whether Open vSwitch is encountering any problems, the
40 user must compare packet loss and achieved bandwidth in a setup where
41 traffic is being directly sent and in one where it is not. If in the
42 802.1Q or L3 tunneled tests both ovs-test processes are unable to com‐
43 municate or the achieved bandwidth is much lower compared to direct
44 setup, then, most likely, Open vSwitch has encountered a pre-existing
45 kernel or driver bug.
46 Some examples of the types of problems that may be encountered are:
48 · When NICs use VLAN stripping on receive they must pass a pointer
50 to a vlan_group when reporting the stripped tag to the network‐
51 ing core. If no vlan_group is in use then some drivers just
52 drop the extracted tag. Drivers are supposed to only enable
53 stripping if a vlan_group is registered but not all of them do
54 that.
55 · On receive, some drivers handle priority tagged packets spe‐
57 cially and don't pass the tag onto the network stack at all, so
58 Open vSwitch never has a chance to see it.
59 · Some drivers size their receive buffers based on whether a
61 vlan_group is enabled, meaning that a maximum size packet with a
62 VLAN tag will not fit if no vlan_group is configured.
63 · On transmit, some drivers expect that VLAN acceleration will be
65 used if it is available, which can only be done if a vlan_group
66 is configured. In these cases, the driver may fail to parse the
67 packet and correctly setup checksum offloading or TSO.
68 Client Mode
70 An ovs-test client will connect to two ovs-test servers and will ask
71 them to exchange test traffic. It is also possible to spawn an ovs-test
72 server automatically from the client.
73 Server Mode
75 To conduct tests, two ovs-test servers must be running on two different
76 hosts where the client can connect. The actual test traffic is
77 exchanged only between both ovs-test servers. It is recommended that
78 both servers have their IP addresses in the same subnet, otherwise one
79 would have to make sure that routing is set up correctly.
80
82 -s port
83 --server port
84 Run in server mode and wait for the client to establish XML RPC
85 Control Connection on this TCP port. It is recommended to have
86 ethtool(8) installed on the server so that it could retrieve
87 information about the NIC driver.
88 -c server1 server2
90 --client server1 server2
91 Run in client mode and schedule tests between server1 and
92 server2, where each server must be given in the following format
93 - OuterIP[:OuterPort],InnerIP[/Mask][:InnerPort]. The OuterIP
94 must be already assigned to the physical interface which is
95 going to be tested. This is the IP address where client will
96 try to establish XML RPC connection. If OuterIP is 127.0.0.1
97 then client will automatically spawn a local instance of
98 ovs-test server. OuterPort is TCP port where server is listening
99 for incoming XML/RPC control connections to schedule tests (by
100 default it is 15531). The ovs-test will automatically assign
101 InnerIP[/Mask] to the interfaces that will be created on the fly
102 for testing purposes. It is important that InnerIP[/Mask] does
103 not interfere with already existing IP addresses on both
104 ovs-test servers and client. InnerPort is port which will be
105 used by server to listen for test traffic that will be encapsu‐
106 lated (by default it is 15532).
107 -b targetbandwidth
109 --bandwidth targetbandwidth
110 Target bandwidth for UDP tests. The targetbandwidth must be
111 given in bits per second. It is possible to use postfix M or K
112 to alter the target bandwidth magnitude.
113 -i testinterval
115 --interval testinterval
116 How long each test should run. By default 5 seconds.
117 -h
119 --help Prints a brief help message to the console.
120 -V
122 --version
123 Prints version information to the console.
124
126 The following test modes are supported by ovs-test. It is possible to
127 combine multiple of them in a single ovs-test invocation.
128 -d
130 --direct
131 Perform direct tests between both OuterIP addresses. These tests
132 could be used as a reference to compare 802.1Q or L3 tunneling
133 test results.
134 -l vlantag
136 --vlan-tag vlantag
137 Perform 802.1Q tests between both servers. These tests will cre‐
138 ate a temporary OVS bridge, if necessary, and attach a VLAN
139 tagged port to it for testing purposes.
140 -t tunnelmodes
142 --tunnel-modes tunnelmodes
143 Perform L3 tunneling tests. The given argument is a comma sepa‐
144 rated string that specifies all the L3 tunnel modes that should
145 be tested (e.g. gre). The L3 tunnels are terminated on interface
146 that has the OuterIP address assigned.
147
149 On host 1.2.3.4 start ovs-test in server mode:
150 ovs-test -s 15531
152 On host 1.2.3.5 start ovs-test in client mode and do direct, VLAN and
154 GRE tests between both nodes:
155 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
157 gre
158
160 ovs-vswitchd(8), ovs-ofctl(8), ovs-vsctl(8), ovs-vlan-test(8), eth‐
161 tool(8), uname(1)
162Open vSwitch 2.0.0 ovs-test(1)