counters for each port.
- ovs-vsctl:
- New "show" command to print an overview of configuration.
+ - ovs-openflowd has been renamed test-openflowd and moved into the
+ tests directory. Its presence confused too many users. Please
+ use ovs-vswitchd instead.
- Feature removals:
- Dropped support for "tun_id_from_cookie" OpenFlow extension.
(Use the extensible match extensions instead.)
+++ /dev/null
- Using Open vSwitch as a Simple OpenFlow Switch
- ==============================================
-
-Open vSwitch uses OpenFlow as its preferred method of remote flow
-table configuration. This is the simplest method of using it with an
-OpenFlow controller. The ovs-vsctl "set-controller" command can also
-be used in conjunction with ovs-vswitchd to set the controller for one
-or more bridges. We recommend using OpenFlow in this manner and in this
-case you should not run ovs-openflowd. Directions for setting up
-ovs-vswitchd can be found in INSTALL.Linux.
-
-However, it is also possible to use Open vSwitch as a simple OpenFlow
-switch like that provided by the OpenFlow reference implementation
-[1]. The remainder of this file describes how to use it in that
-manner.
-
-What is OpenFlow?
------------------
-
-OpenFlow is a flow-based switch specification designed to enable
-researchers to run experiments in live networks. OpenFlow is based on a
-simple Ethernet flow switch that exposes a standardized interface for
-adding and removing flow entries.
-
-An OpenFlow switch consists of three parts: (1) A "flow table" in
-which each flow entry is associated with an action telling the switch
-how to process the flow, (2) a "secure channel" that connects the switch
-to a remote process (a controller), allowing commands and packets to
-be sent between the controller and the switch, and (3) an OpenFlow
-protocol implementation, providing an open and standard way for a
-controller to talk to the switch.
-
-An OpenFlow switch can thus serve as a simple datapath element that
-forwards packets between ports according to flow actions defined by
-the controller using OpenFlow commands. Example actions are:
-
- - Forward this flow's packets to the given port(s)
- - Drop this flow's packets
- - Encapsulate and forward this flow's packets to the controller.
-
-The OpenFlow switch is defined in detail in the OpenFlow switch
-Specification [2].
-
-Installation Procedure
-----------------------
-
-The procedure below explains how to use the Open vSwitch as a simple
-OpenFlow switch.
-
-1. Build and install the Open vSwitch kernel modules and userspace
- programs as described in INSTALL.Linux.
-
- It is important to run "make install", because some Open vSwitch
- programs expect to find files in locations selected at installation
- time.
-
-2. Load the openvswitch kernel module (which was built in step 1), e.g.:
-
- % insmod datapath/linux-2.6/openvswitch_mod.ko
-
- If your Linux kernel is earlier than 2.6.36, this kernel module
- cannot be loaded if the Linux bridge module is already loaded.
- Thus, you may need to remove any existing bridges and unload the
- bridge module with "rmmod bridge" before you can do this.
-
-3. Create a datapath instance. The command below creates a datapath
- identified as dp0 (see ovs-dpctl(8) for more detailed usage
- information).
-
- # ovs-dpctl add-dp dp0
-
- Creating datapath dp0 creates a new network device, also named dp0.
- This network device, called the datapath's "local port", will be
- bridged to the physical switch ports by ovs-openflowd(8). It is
- optionally used for in-band control as described in step 5.
-
-4. Use ovs-dpctl to attach the datapath to physical interfaces on the
- machine. Say, for example, you want to create a trivial 2-port
- switch using interfaces eth1 and eth2, you would issue the following
- commands:
-
- # ovs-dpctl add-if dp0 eth1
- # ovs-dpctl add-if dp0 eth2
-
- You can verify that the interfaces were successfully added by asking
- ovs-dpctl to print the current status of datapath dp0:
-
- # ovs-dpctl show dp0
-
-5. Arrange so that the switch can reach the controller over the network.
- This can be done in two ways. The switch may be configured for
- out-of-band control, which means it uses a network separate from the
- data traffic that it controls. Alternatively, the switch may be
- configured to contact the controller over one of the network devices
- under its control. In-band control is often more convenient than
- out-of-band, because it is not necessary to maintain two independent
- networks.
-
- - If you are using out-of-band control, at this point make sure
- that the switch machine can reach the controller over the
- network.
-
- - If you are using in-band control, then at this point you must
- configure the dp0 network device created in step 3. This
- device is not yet bridged to any physical network (because
- ovs-openflowd does that, and it is not yet running), so the next
- step depends on whether connectivity is required to configure
- the device's IP address:
-
- * If the switch has a static IP address, you may configure
- its IP address now, e.g.:
-
- # ifconfig dp0 192.168.1.1
-
- * If the switch does not have a static IP address, e.g. its
- IP address is obtained dynamically via DHCP, then proceed
- to the next step. The DHCP client will not be able to
- contact the DHCP server until the secure channel has
- started. The address will be obtained in step 7.
-
-6. Run ovs-openflowd to start the secure channel connecting the datapath to
- a remote controller. If the controller is running on host
- 192.168.1.2 port 6633 (the default port), the ovs-openflowd invocation
- would look like this:
-
- # ovs-openflowd dp0 tcp:192.168.1.2
-
- - If you are using out-of-band control, add --out-of-band to the
- command line.
-
- Using the "tcp:<controller_ip>" argument causes the switch to connect
- in an insecure manner. Please see INSTALL.SSL for a description of
- how to connect securely using SSL.
-
-7. If you are using in-band control, and the switch obtains its IP address
- dynamically, then you may now obtain the switch's IP address, e.g. by
- invoking a DHCP client. The secure channel will only be able to connect
- to the controller after an IP address has been obtained.
-
-8. The secure channel should connect to the controller within a few
- seconds.
-
-References
-----------
-
- [1] OpenFlow Reference Implementation.
- <http://www.openflowswitch.org/wp/downloads/>
-
- [2] OpenFlow Switch Specification.
- <http://openflowswitch.org/documents/openflow-spec-latest.pdf>
named the same as the bridge, as well as for each configured internal
interface.
-Using the Userspace Datapath with ovs-openflowd
------------------------------------------------
-
-To use ovs-openflowd in userspace mode, specify a datapath name that
-begins with "netdev@", and specify --ports with the names of the ports
-that should be included in the datapath as argument. For example:
-
- ovs-openflowd netdev@br0 --ports=eth0,eth1,eth2
-
-ovs-openflowd will create a TAP device as the bridge's local
-interface, named the same as the bridge minus the "netdev@" prefix.
-
Bug Reporting
-------------
DESIGN \
INSTALL.KVM \
INSTALL.Linux \
- INSTALL.OpenFlow \
INSTALL.SSL \
INSTALL.XenServer \
INSTALL.bridge \
noinst_DATA =
noinst_HEADERS =
noinst_LIBRARIES =
+noinst_man_MANS =
noinst_PROGRAMS =
noinst_SCRIPTS =
OVSIDL_BUILT =
name makes the intended use obvious.
ovs-vswitchd is the most sophisticated of ofproto's clients, but
-ofproto can have other clients as well. ovs-openflowd, in the
-utilities directory, is much simpler than ovs-vswitchd. It may be
-easier to initially bring up ovs-openflowd as part of a port.
+ofproto can have other clients as well. test-openflowd, in the
+tests directory, is much simpler than ovs-vswitchd. It may be
+easier to initially bring up test-openflowd as part of a port.
lib/entropy.c assumes that it can obtain high-quality random number
seeds at startup by reading from /dev/urandom. You will need to
* ovsdbmonitor, a GUI tool for remotely viewing OVS databases and
OpenFlow flow tables.
-Open vSwitch also provides an OpenFlow implementation and tools for
-those interested in OpenFlow but not additional Open vSwitch features:
-
- * ovs-openflowd, an alternative to ovs-vswitchd that implements a
- simple OpenFlow switch, without the special features provided by
- ovs-vswitchd.
+Open vSwitch also provides some tools:
* ovs-controller, a simple OpenFlow controller.
/test-list
/test-lockfile
/test-multipath
+/test-openflowd
+/test-openflowd.8
/test-ovsdb
/test-packets
/test-random
valgrind_wrappers = \
tests/valgrind/ovs-appctl \
- tests/valgrind/ovs-openflowd \
tests/valgrind/ovs-vsctl \
tests/valgrind/ovsdb-client \
tests/valgrind/ovsdb-server \
tests/valgrind/test-list \
tests/valgrind/test-lockfile \
tests/valgrind/test-multipath \
+ tests/valgrind/test-openflowd \
tests/valgrind/test-ovsdb \
tests/valgrind/test-packets \
tests/valgrind/test-random \
tests_test_multipath_SOURCES = tests/test-multipath.c
tests_test_multipath_LDADD = lib/libopenvswitch.a
+noinst_PROGRAMS += tests/test-openflowd
+EXTRA_DIST += tests/test-openflowd.8.in
+DISTCLEANFILES += tests/test-openflowd.8
+noinst_man_MANS += tests/ovs-openflowd.8
+tests_test_openflowd_SOURCES = tests/test-openflowd.c
+tests_test_openflowd_LDADD = \
+ ofproto/libofproto.a \
+ lib/libsflow.a \
+ lib/libopenvswitch.a \
+ $(SSL_LIBS)
+
+
noinst_PROGRAMS += tests/test-packets
tests_test_packets_SOURCES = tests/test-packets.c
tests_test_packets_LDADD = lib/libopenvswitch.a
m4_define([OFPROTO_START],
[OVS_RUNDIR=$PWD; export OVS_RUNDIR
OVS_LOGDIR=$PWD; export OVS_LOGDIR
- trap 'kill `cat ovs-openflowd.pid`' 0
- AT_CAPTURE_FILE([ovs-openflowd.log])
+ trap 'kill `cat test-openflowd.pid`' 0
+ AT_CAPTURE_FILE([test-openflowd.log])
AT_CHECK(
- [ovs-openflowd --detach --pidfile --enable-dummy --log-file --fail=closed dummy@br0 none --datapath-id=fedcba9876543210 $1],
+ [test-openflowd --detach --pidfile --enable-dummy --log-file --fail=closed dummy@br0 none --datapath-id=fedcba9876543210 $1],
[0], [], [stderr])
AT_CHECK([[sed < stderr '
/vlog|INFO|opened log file/d
])
m4_define([OFPROTO_STOP],
- [AT_CHECK([ovs-appctl -t ovs-openflowd exit])
+ [AT_CHECK([ovs-appctl -t test-openflowd exit])
trap '' 0])
-.TH ovs\-openflowd 8 "March 2009" "Open vSwitch" "Open vSwitch Manual"
+.TH test\-openflowd 8 "March 2009" "Open vSwitch" "Open vSwitch Manual"
.\" This program's name:
-.ds PN ovs\-openflowd
+.ds PN test\-openflowd
.\" SSL peer program's name:
.ds SN ovs\-controller
.
.SH NAME
-ovs\-openflowd \- OpenFlow switch implementation
+test\-openflowd \- OpenFlow switch implementation
.
.SH SYNOPSIS
-.B ovs\-openflowd
+.B test\-openflowd
[\fIoptions\fR] \fIdatapath\fR \fIcontroller\fR\&...
.
.SH DESCRIPTION
-The \fBovs\-openflowd\fR program implements an OpenFlow switch using a
-flow-based datapath. \fBovs\-openflowd\fR connects to one or more
+The \fBtest\-openflowd\fR program implements an OpenFlow switch using a
+flow-based datapath. \fBtest\-openflowd\fR connects to one or more
OpenFlow controllers over TCP or SSL.
.PP
-For a more powerful alternative to \fBovs\-openflowd\fR, see
+For a more powerful alternative to \fBtest\-openflowd\fR, see
\fBovs\-vswitchd\fR(8). Do not run both daemons at the same time.
.PP
The mandatory \fIdatapath\fR argument argument specifies the local
switch.)
.
.PP
-When multiple controllers are configured, \fBovs\-openflowd\fR
+When multiple controllers are configured, \fBtest\-openflowd\fR
connects to all of them simultaneously. OpenFlow 1.0 does not specify
how multiple controllers coordinate in interacting with a single
switch, so more than one controller should be specified only if the
any of the network devices added to the datapath with \fBovs\-dpctl
add\-if\fR in its communication with the controller.
.IP
-To use \fBovs\-openflowd\fR in a network with out-of-band control, specify
-\fB\-\-out\-of\-band\fR on the \fBovs\-openflowd\fR command line. The control
-network must be configured separately, before or after \fBovs\-openflowd\fR
+To use \fBtest\-openflowd\fR in a network with out-of-band control, specify
+\fB\-\-out\-of\-band\fR on the \fBtest\-openflowd\fR command line. The control
+network must be configured separately, before or after \fBtest\-openflowd\fR
is started.
.
.IP in-band
out-of-band control, because it is not necessary to maintain two
independent networks.
.IP
-In-band control is the default for \fBovs\-openflowd\fR, so no special
+In-band control is the default for \fBtest\-openflowd\fR, so no special
command-line option is required.
Specify the location of the
-controller on the \fBovs\-openflowd\fR command line as the \fIcontroller\fR
+controller on the \fBtest\-openflowd\fR command line as the \fIcontroller\fR
argument. You must also configure the network device for the OpenFlow
-``local port'' to allow \fBovs\-openflowd\fR to connect to that controller.
-The OpenFlow local port is a virtual network port that \fBovs\-openflowd\fR
+``local port'' to allow \fBtest\-openflowd\fR to connect to that controller.
+The OpenFlow local port is a virtual network port that \fBtest\-openflowd\fR
bridges to the physical switch ports. The name of the local port for
a given \fIdatapath\fR may be seen by running \fBovs\-dpctl show
\fIdatapath\fR; the local port is listed as port 0 in \fBshow\fR's
output.
.
.IP
-Before \fBovs\-openflowd\fR starts, the local port network device is not
+Before \fBtest\-openflowd\fR starts, the local port network device is not
bridged to any physical network, so the next step depends on whether
connectivity is required to configure the device's IP address. If the
switch has a static IP address, you may configure its IP address now
with a command such as
.B ifconfig of0 192.168.1.1
-and then invoke \fBovs\-openflowd\fR.
+and then invoke \fBtest\-openflowd\fR.
.IP
On the other hand, if the switch does not have a static IP address,
e.g. it obtains its IP address dynamically via DHCP, the DHCP client
will not be able to contact the DHCP server until the OpenFlow switch
-has started up. Thus, start \fBovs\-openflowd\fR without configuring
+has started up. Thus, start \fBtest\-openflowd\fR without configuring
the local port network device, and start the DHCP client afterward.
.RE
.
switch at all.
.IP
If this option is set to \fBstandalone\fR (the default),
-\fBovs\-openflowd\fR will
+\fBtest\-openflowd\fR will
take over responsibility for setting up flows in the local datapath
when no message has been received from the controller for three times
the inactivity probe interval (see below), or 45 seconds by default.
-In this ``fail open'' mode, \fBovs\-openflowd\fR causes the datapath to act
-like an ordinary MAC-learning switch. \fBovs\-openflowd\fR will continue to
+In this ``fail open'' mode, \fBtest\-openflowd\fR causes the datapath to act
+like an ordinary MAC-learning switch. \fBtest\-openflowd\fR will continue to
retry connection to the controller in the background and, when the
connection succeeds, it discontinues its standalone switching behavior.
.IP
-If this option is set to \fBsecure\fR, then \fBovs\-openflowd\fR will not
+If this option is set to \fBsecure\fR, then \fBtest\-openflowd\fR will not
set up flows on its own when the controller connection fails.
.
.TP
.
.TP
\fB\-\-in\-band\fR, \fB\-\-out\-of\-band\fR
-Configures \fBovs\-openflowd\fR to operate in in-band or out-of-band control
+Configures \fBtest\-openflowd\fR to operate in in-band or out-of-band control
mode (see \fBContacting the Controller\fR above). When neither option
is given, the default is in-band control.
.
.SS "Datapath Options"
.
.IP "\fB\-\-ports=\fIport\fR[\fB,\fIport\fR...]"
-Ordinarily, \fBovs\-openflowd\fR expects the administrator to create
+Ordinarily, \fBtest\-openflowd\fR expects the administrator to create
the specified \fIdatapath\fR and add ports to it externally with a
utility such as \fBovs\-dpctl\fR. However, the userspace switch
-datapath is implemented inside \fBovs\-openflowd\fR itself and does
+datapath is implemented inside \fBtest\-openflowd\fR itself and does
not (currently) have any external interface for \fBovs\-dpctl\fR to
access. As a stopgap measure, this option specifies one or more ports
-to add to the datapath at \fBovs\-openflowd\fR startup time. Multiple
+to add to the datapath at \fBtest\-openflowd\fR startup time. Multiple
ports may be specified as a comma-separated list or by specifying
\fB\-\-ports\fR multiple times.
.IP
.
.SH "RUNTIME MANAGEMENT COMMANDS"
\fBovs\-appctl\fR(8) can send commands to a running
-\fBovs\-openflowd\fR process. The currently supported commands are
+\fBtest\-openflowd\fR process. The currently supported commands are
described below.
-.SS "OVS\-OPENFLOWD COMMANDS"
-These commands are specific to \fBovs\-openflowd\fR.
+.SS "TEST\-OPENFLOWD COMMANDS"
+These commands are specific to \fBtest\-openflowd\fR.
.IP "\fBexit\fR"
-Causes \fBovs\-openflowd\fR to gracefully terminate.
+Causes \fBtest\-openflowd\fR to gracefully terminate.
.so ofproto/ofproto-unixctl.man
.so lib/vlog-unixctl.man
.
struct sset netflow; /* NetFlow targets. */
};
-static unixctl_cb_func ovs_openflowd_exit;
+static unixctl_cb_func test_openflowd_exit;
static void parse_options(int argc, char *argv[], struct ofsettings *);
static void usage(void) NO_RETURN;
exit(EXIT_FAILURE);
}
- unixctl_command_register("exit", ovs_openflowd_exit, &exiting);
+ unixctl_command_register("exit", test_openflowd_exit, &exiting);
VLOG_INFO("Open vSwitch version %s", VERSION BUILDNR);
VLOG_INFO("OpenFlow protocol version 0x%02x", OFP_VERSION);
}
static void
-ovs_openflowd_exit(struct unixctl_conn *conn, const char *args OVS_UNUSED,
+test_openflowd_exit(struct unixctl_conn *conn, const char *args OVS_UNUSED,
void *exiting_)
{
bool *exiting = exiting_;
/ovs-dpctl.8
/ovs-ofctl
/ovs-ofctl.8
-/ovs-openflowd
-/ovs-openflowd.8
/ovs-parse-leaks
/ovs-pcap
/ovs-pcap.1
utilities/ovs-controller \
utilities/ovs-dpctl \
utilities/ovs-ofctl \
- utilities/ovs-openflowd \
utilities/ovs-vsctl
bin_SCRIPTS += utilities/ovs-pki utilities/ovs-vsctl
if HAVE_PYTHON
utilities/ovs-controller.8.in \
utilities/ovs-dpctl.8.in \
utilities/ovs-ofctl.8.in \
- utilities/ovs-openflowd.8.in \
utilities/ovs-parse-leaks.8 \
utilities/ovs-parse-leaks.in \
utilities/ovs-pcap.1.in \
utilities/ovs-controller.8 \
utilities/ovs-dpctl.8 \
utilities/ovs-ofctl.8 \
- utilities/ovs-openflowd.8 \
utilities/ovs-parse-leaks \
utilities/ovs-pcap \
utilities/ovs-pcap.1 \
utilities/ovs-controller.8 \
utilities/ovs-dpctl.8 \
utilities/ovs-ofctl.8 \
- utilities/ovs-openflowd.8 \
utilities/ovs-parse-leaks.8 \
utilities/ovs-pcap.1 \
utilities/ovs-pki.8 \
lib/libopenvswitch.a \
$(SSL_LIBS)
-utilities_ovs_openflowd_SOURCES = utilities/ovs-openflowd.c
-utilities_ovs_openflowd_LDADD = \
- ofproto/libofproto.a \
- lib/libsflow.a \
- lib/libopenvswitch.a \
- $(SSL_LIBS)
-
utilities_ovs_vsctl_SOURCES = utilities/ovs-vsctl.c vswitchd/vswitch-idl.c
utilities_ovs_vsctl_LDADD = lib/libopenvswitch.a $(SSL_LIBS)
.
\fBovs\-appctl\fR can control the following daemons:
.BR ovs\-vswitchd (8),
-.BR ovs\-openflowd (8),
.BR ovs\-controller (8),
.BR ovs\-brcompatd (8).
packets being seen. If \fBpermanent\fR is specified, which is not
recommended, flows will never expire. The default is 60 seconds.
.IP
-This option affects only flows set up by the OpenFlow controller. In
-some configurations, the switch can set up some flows
-on its own. To set the idle time for those flows, pass
-\fB\-\-max\-idle\fR to \fBovs\-openflowd\fR (on the switch).
-.IP
This option has no effect when \fB\-n\fR (or \fB\-\-noflow\fR) is in use
(because the controller does not set up flows in that case).
.
\-\-peer\-ca\-cert=cacert.pem set\-controller ssl:\fIip\fR
.SH "SEE ALSO"
.
-.BR ovs\-openflowd (8),
.BR ovs\-appctl (8),
.BR ovs\-ofctl (8),
.BR ovs\-dpctl (8)
.so lib/vlog.man
.so lib/common.man
.
-.SH EXAMPLES
-.
-A typical \fBovs\-dpctl\fR command sequence for controlling an
-Open vSwitch kernel module:
-.
-.TP
-\fBovs\-dpctl add\-dp dp0\fR
-Creates datapath number 0.
-.
-.TP
-\fBovs\-dpctl add\-if dp0 eth0 eth1\fR
-Adds two network devices to the new datapath.
-.
-.PP
-At this point one would ordinarily start \fBovs\-openflowd\fR(8) on
-\fBdp0\fR, transforming \fBdp0\fR into an OpenFlow switch. Then, when
-the switch and the datapath is no longer needed:
-.
-.TP
-\fBovs\-dpctl del\-if dp0 eth0 eth1\fR
-Removes network devices from the datapath.
-.
-.TP
-\fBovs\-dpctl del\-dp dp0\fR
-Deletes the datapath.
-.
.SH "SEE ALSO"
.
.BR ovs\-appctl (8),
-.BR ovs\-openflowd (8),
.BR ovs\-vswitchd (8)
.
.IP "\fBmonitor \fIswitch\fR [\fImiss-len\fR]"
Connects to \fIswitch\fR and prints to the console all OpenFlow
-messages received. Usually, \fIswitch\fR should specify a connection
-named on \fBovs\-openflowd\fR(8)'s \fB\-l\fR or \fB\-\-listen\fR command line
-option.
+messages received. Usually, \fIswitch\fR should specify the name of a
+bridge in the \fBovs\-vswitchd\fR database.
.IP
If \fImiss-len\fR is provided, \fBovs\-ofctl\fR sends an OpenFlow ``set
configuration'' message at connection setup time that requests
.
.IP \fBlocal\fR
Outputs the packet on the ``local port,'' which corresponds to the
-\fBof\fIn\fR network device (see \fBCONTACTING THE CONTROLLER\fR in
-\fBovs\-openflowd\fR(8) for information on the \fBof\fIn\fR network device).
+network device that has the same name as the bridge.
.
.IP \fBdrop\fR
Discards the packet, so no further processing or forwarding takes place.
.
.SH EXAMPLES
.
-The following examples assume that an OpenFlow switch on the local
-host has been configured to listen for management connections on a
-Unix domain socket named \fB@RUNDIR@/openflow.sock\fR, e.g. by
-specifying \fB\-\-listen=punix:@RUNDIR@/openflow.sock\fR on the
-\fBovs\-openflowd\fR(8) command line.
+The following examples assume that \fBovs\-vswitchd\fR has a bridge
+named \fBbr0\fR configured.
.
.TP
-\fBovs\-ofctl dump\-tables unix:@RUNDIR@/openflow.sock\fR
+\fBovs\-ofctl dump\-tables br0\fR
Prints out the switch's table stats. (This is more interesting after
some traffic has passed through.)
.
.TP
-\fBovs\-ofctl dump\-flows unix:@RUNDIR@/openflow.sock\fR
+\fBovs\-ofctl dump\-flows br0\fR
Prints the flow entries in the switch.
.
.SH "SEE ALSO"
The \fBovs\-pcap\fR program reads the pcap \fIfile\fR named on the
command line and prints each packet's contents as a sequence of hex
digits on a line of its own. This format is suitable for use with the
-\fBofproto/trace\fR command supported by \fBovs\-vswitchd\fR(8) and
-\fBovs-openflowd\fR(8).
+\fBofproto/trace\fR command supported by \fBovs\-vswitchd\fR(8).
.
.SH "OPTIONS"
.so lib/common.man
.SH "SEE ALSO"
.
.BR ovs\-vswitchd (8),
-.BR ovs\-openflowd (8),
.BR ovs\-tcpundump (1),
.BR tcpdump (8),
.BR wireshark (8).
.SH "SEE ALSO"
.BR ovs\-controller (8),
-.BR ovs\-openflowd (8),
.BR ovs\-pki\-cgi (8)
stdin, looking for hexadecimal packet data, and dumps each Ethernet as
a single hexadecimal string on stdout. This format is suitable for
use with the \fBofproto/trace\fR command supported by
-\fBovs\-vswitchd\fR(8) and \fBovs-openflowd\fR(8)
+\fBovs\-vswitchd\fR(8)
via \fBovs\-appctl\fR(8).
.PP
At least two \fB\-x\fR or \fB\-X\fR options must be given, otherwise
.
.BR ovs\-appctl (8),
.BR ovs\-vswitchd (8),
-.BR ovs\-openflowd (8),
.BR ovs\-pcap (1),
.BR tcpdump (8),
.BR wireshark (8).
A single \fBovs\-vswitchd\fR can manage any number of switch instances, up
to the maximum number of supported Open vSwitch datapaths.
.PP
-\fBovs\-vswitchd\fR provides all the features of \fBovs-openflowd\fR,
-and more. Do not run both daemons at the same time.
-.PP
\fBovs\-vswitchd\fR does all the necessary management of Open vSwitch datapaths
itself. Thus, external tools, such \fBovs\-dpctl\fR(8), are not needed for
managing datapaths in conjunction with \fBovs\-vswitchd\fR, and their use
# Get rid of stuff we don't want to make RPM happy.
rm \
$RPM_BUILD_ROOT/usr/bin/ovs-controller \
- $RPM_BUILD_ROOT/usr/bin/ovs-openflowd \
$RPM_BUILD_ROOT/usr/bin/ovs-pki \
$RPM_BUILD_ROOT/usr/share/man/man8/ovs-controller.8 \
- $RPM_BUILD_ROOT/usr/share/man/man8/ovs-openflowd.8 \
$RPM_BUILD_ROOT/usr/share/man/man8/ovs-pki.8
install -d -m 755 $RPM_BUILD_ROOT/var/lib/openvswitch
git://git.onelab.eu / sliver-openvswitch.git / commitdiff