|
HTML rendering created 2024-06-26 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|
|
NAME | SYNOPSIS | DESCRIPTION | OPTIONS | EXAMPLES | SEE ALSO | AUTHOR | COPYRIGHT | COLOPHON |
|
|
|
OVS-TEST(8) Open vSwitch OVS-TEST(8)
ovs-test - Check Linux drivers for performance, vlan and L3
tunneling problems
ovs-test -s port
ovs-test -c server1 server2 [-b targetbandwidth] [-i
testinterval] [-d]
[-l vlantag] [-t tunnelmodes]
The ovs-test program may be used to check for problems sending
802.1Q or GRE traffic that Open vSwitch may uncover. These
problems, for example, 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 IP addresses on server1 and server2 for interfaces you
intended to test. These interfaces could also be already
configured OVS bridges that have a physical interface attached to
them. Then, on one of the nodes, run ovs-test in server mode and
on the other node run it in client mode. The client will connect
to ovs-test server and schedule tests between both of them. The
ovs-test client will perform UDP and TCP tests.
UDP tests can report packet loss and achieved bandwidth for
various datagram sizes. By default target bandwidth for UDP tests
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 issues.
To determine whether Open vSwitch is encountering any problems,
the user must compare packet loss and achieved bandwidth in a
setup where traffic is being directly sent and in one where it is
not. If in the 802.1Q or L3 tunneled tests both ovs-test
processes are unable to communicate or the achieved bandwidth is
much lower compared to direct setup, 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:
• 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.
• 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.
• 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.
• 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 test traffic. It is also
possible to spawn an ovs-test server automatically from
the client.
Server Mode
To conduct tests, two ovs-test servers must be running on
two different hosts where the client can connect. The
actual test traffic is exchanged only between both
ovs-test servers. It is recommended that both servers have
their IP addresses in the same subnet, otherwise one would
have to make sure that routing is set up correctly.
-s <port>, --server <port>
Run in server mode and wait for the client to establish
XML RPC Control Connection on this TCP port. It is
recommended to have ethtool(8) installed on the server so
that it could retrieve information about the NIC driver.
-c <server1> <server2>, --client <server1> <server2>
Run in client mode and schedule tests between server1 and
server2, where each server must be given in the following
format:
OuterIP[:OuterPort],InnerIP[/Mask][:InnerPort].
The OuterIP must be already assigned to the physical
interface which is going to be tested. This is the IP
address where client will try to establish XML RPC
connection. If OuterIP is 127.0.0.1 then client will
automatically spawn a local instance of ovs-test server.
OuterPort is TCP port where server is listening for
incoming XML/RPC control connections to schedule tests (by
default it is 15531). The ovs-test will automatically
assign InnerIP[/Mask] to the interfaces that will be
created on the fly for testing purposes. It is important
that InnerIP[/Mask] does not interfere with already
existing IP addresses on both ovs-test servers and client.
InnerPort is port which will be used by server to listen
for test traffic that will be encapsulated (by default it
is 15532).
-b <targetbandwidth>, --bandwidth <targetbandwidth>
Target bandwidth for UDP tests. The targetbandwidth must
be given in bits per second. It is possible to use postfix
M or K to alter the target bandwidth magnitude.
-i <testinterval>, --interval <testinterval>
How long each test should run. By default 5 seconds.
-h, --help
Prints a brief help message to the console.
-V, --version
Prints version information to the console.
The following test modes are supported by ovs-test. It is
possible to combine multiple of them in a single ovs-test
invocation.
-d, --direct
Perform direct tests between both OuterIP addresses. These
tests could be used as a reference to compare 802.1Q or L3
tunneling test results.
-l <vlantag>, --vlan-tag <vlantag>
Perform 802.1Q tests between both servers. These tests
will create a temporary OVS bridge, if necessary, and
attach a VLAN tagged port to it for testing purposes.
-t <tunnelmodes>, --tunnel-modes <tunnelmodes>
Perform L3 tunneling tests. The given argument is a comma
sepa‐ rated string that specifies all the L3 tunnel modes
that should be tested (e.g. gre). The L3 tunnels are
terminated on interface that has the OuterIP address
assigned.
On host 1.2.3.4 start ovs-test in server mode:
ovs-test -s 15531
On host 1.2.3.5 start ovs-test in client mode and do direct, VLAN
and GRE tests between both nodes:
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
gre
ovs-vswitchd(8), ovs-ofctl(8), ovs-vsctl(8), ovs-vlan-test,
ethtool(8), uname(1)
The Open vSwitch Development Community
2016-2024, The Open vSwitch Development Community
This page is part of the Open vSwitch (a distributed virtual
multilayer switch) project. Information about the project can be
found at ⟨http://openvswitch.org/⟩. If you have a bug report for
this manual page, send it to [email protected]. This page was
obtained from the project's upstream Git repository
⟨https://github.com/openvswitch/ovs.git⟩ on 2024-06-14. (At that
time, the date of the most recent commit that was found in the
repository was 2024-06-07.) If you discover any rendering
problems in this HTML version of the page, or you believe there
is a better or more up-to-date source for the page, or you have
corrections or improvements to the information in this COLOPHON
(which is not part of the original manual page), send a mail to
[email protected]
3.3.90 Jun 13, 2024 OVS-TEST(8)
Pages that refer to this page: ovs-l3ping(8)
|
HTML rendering created 2024-06-26 by Michael Kerrisk, author of The Linux Programming Interface. For details of in-depth Linux/UNIX system programming training courses that I teach, look here. Hosting by jambit GmbH. |
|