|
|
IP Bandwidth Watchdog 0.8.1 (Default branch)
06-18-2008
ipband is a pcap-based traffic monitor. It tallies per-subnet traffic and bandwidth usage and starts detailed logging if the specified threshold for a specific subnet is exceeded. This utility could be handy in a limited bandwidth WAN environment (frame relay, ISDN, etc.) to pinpoint offending traffic sources if certain links become saturated to the point where legitimate packets start getting dropped. License: GNU General Public License (GPL) Changes:|
|
ovs-test(1) Open vSwitch Manual ovs-test(1) NAME
ovs-test - check Linux drivers for performance and vlan problems SYNOPSIS
ovs-test -s port ovs-test -c server1 server2 [-b bandwidth] Common options: [-h | --help] [-V | --version] DESCRIPTION
The ovs-test program may be used to check for problems sending 802.1Q traffic that Open vSwitch may uncover. These problems 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 Open vSwitch to tag traffic originating from server1 and forward it to the server2. On both servers run ovs-test in server mode. Then, on any other host, run the ovs-test in client mode. The client will connect to both ovs-test servers and schedule tests between them. ovs-test will perform UDP and TCP tests. UDP tests can report packet loss and achieved bandwidth, because UDP flow control is done inside ovs-test. It is also possible to specify target bandwidth for UDP. By default it 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 VLAN issues. To determine whether Open vSwitch is encountering any 802.1Q related problems, the user must compare packet loss and achieved bandwidth in a setup where traffic is being tagged against one where it is not. If in the tagged setup both servers are unable to communicate or the achieved bandwidth is lower, 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: o 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. o 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. o 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. o 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 traffic. Server Mode To conduct tests, two ovs-test servers must be running on two different hosts where client can connect. The actual test traffic is exchanged only between both ovs-test server test IP addresses. It is recommended that both servers have their test IP addresses in the same subnet, otherwise one will need to change routing so that the test traffic actually goes through the interface that he originally intended to test. OPTIONS
-s, --server port Run in server mode and wait for a client to establish XML RPC Control Connection on TCP port. It is recommended to have ethtool installed on the server so that it could retrieve information about NIC driver. -c, --client server1 server2 Run in client mode and schedule tests between server1 and server2, where each server must be given in following format - Con- trolIP[:ControlPort][,TestIP[:TestPort]]. If TestIP is omitted then ovs-test server will use the ControlIP for testing purposes. ControlPort is TCP port where server will listen for incoming XML/RPC control connections to schedule tests (by default it is 15531). TestPort is port which will be used by server to listen for test traffic (by default it is 15532). -b, --bandwidth bandwidth Target bandwidth for UDP tests. The bandwidth must be given in bits per second. It is possible to use postfix M or K to alter the target bandwidth magnitude. -h, --help Prints a brief help message to the console. -V, --version Prints version information to the console. EXAMPLES
Set up a bridge which forwards traffic originating from 1.2.3.4 out eth1 with VLAN tag 10. ovs-vsctl -- add-br vlan-br -- add-port vlan-br eth1 -- add-port vlan-br vlan-br-tag tag=10 -- set Interface vlan-br-tag type=internal ifconfig vlan-br-tag up 1.2.3.4 On two different hosts start ovs-test in server mode and tell them to listen on port 15531 for incoming client control connections: 1.2.3.4: ovs-test -s 15531 1.2.3.5: ovs-test -s 15531 On any other host start ovs-test in client mode and ask it to connect to those two servers - one at 1.2.3.4 and another at 1.2.3.5 (by default client will use TCP port 15531 to establish control channel). ovs-test -c 1.2.3.4 1.2.3.5 SEE ALSO ovs-vswitchd(8), ovs-ofctl(8), ovs-vsctl(8), ovs-vlan-test(8), ethtool(8), uname(1) Open vSwitch October 2011 ovs-test(1)