1OVS-TEST(8) Open vSwitch OVS-TEST(8)
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
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 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 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 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 Some examples of the types of problems that may be encountered are:
44 • 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 • 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 • 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 • 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 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 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
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 -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 OuterIP[:OuterPort],InnerIP[/Mask][:InnerPort].
90 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 -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 -i <testinterval>, --interval <testinterval>
111 How long each test should run. By default 5 seconds.
112 -h, --help
114 Prints a brief help message to the console.
115 -V, --version
117 Prints version information to the console.
118 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 -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 -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 -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
139 On host 1.2.3.4 start ovs-test in server mode:
140 ovs-test -s 15531
142 On host 1.2.3.5 start ovs-test in client mode and do direct, VLAN and
144 GRE tests between both nodes:
145 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
150 ovs-vswitchd(8), ovs-ofctl(8), ovs-vsctl(8), ovs-vlan-test, ethtool(8),
151 uname(1)
152
154 The Open vSwitch Development Community
155
157 2021, The Open vSwitch Development Community
1582.15 Feb 21, 2021 OVS-TEST(8)