This makes it easy to create a bunch of records that are all related to
each other in a single ovs-vsctl invocation. It adds an example to the
ovs-vsctl manpage.
When the "create" command is used, post_create() calls
ovsdb_idl_txn_get_insert_uuid(), which asserts that the transaction
completed successfully. This makes it clear that postprocess functions
should only run when the transaction completes successfully. (Currently
post_create() is the only postprocess function.)
Until now, log messages about OpenFlow connections have named the target
of the connection, e.g. "tcp:1.2.3.4:5555", but they have not named the
datapath. Most often, every datapath has the same target, so this can
make it difficult to tell which connection is going wrong. Usually, that
isn't important, because all connections with the same target will have the
same problems, but it's probably better to be more informative.
This commit changes the log messages to include the datapath name, so that
"tcp:1.2.3.4:5555" becomes, e.g., "xenbr0<->tcp:1.2.3.4:5555".
Requested-by: Keith Amidon <keith@nicira.com>
The 'name' argument to these functions is actively unhelpful, because none
of the callers provided a better name than the one provided by
vconn_get_name(). So drop it.
The most recent revision of the netdev library added may_create
and may_open flags to explicitly state the intent of the caller as
to whether the device should already be in use. This was simply
a sanity check for users of the netdev library and the configuration.
At this point the netdev library and its users are well behaved and
should no longer need to be checked. Additional checks have also
been added for incorrect configuration that mean the netdev library
is no longer the primary line of defense.
These flags themselves create problems because it is not always
easy for a library to know what the state of devices should be.
This is particularly a problem for ovs-openflowd, which expects
ports to be added by ovs-dpctl. Fixing this either requires that
the checks are so permissive to be useless or ugly hacks to get
around them. Since they are no longer needed, just remove the
checks.
This commit restores the previous behavior of ovs-openflowd to
not require that ports be specified on the command line or
cleaned up after use.
Bug #2652
CC: Natasha Gude <natasha@nicira.com>
CC: Jean Tourrilhes <jt@hpl.hp.com>
CC: 蒲彦 <yan.p.bjtu@gmail.com>
This makes "ovs-ofctl snoop" and anything else that connects to the
switch's "snoop" socket typically more useful in the presence of multiple
controllers, since the "master" connection is the one with the most
interesting traffic.
Suggested-by: Justin Pettit <jpettit@nicira.com>
The "snoop" command does roughly the same thing as "monitor", but it is
easier to use in the common case where one just wants to look at the
OpenFlow controller connection for a bridge. Instead of, for example,
ovs-ofctl monitor unix:/var/run/openvswitch/br0.snoop
one merely types
ovs-ofctl snoop br0
Add the "emer-reset" command, which is used to clear the configuration of
items likely to have been configured by the manager. This will leave
the core networking configuration as it was.
With this commit, Open vSwitch permits a bridge to have any number of
OpenFlow controllers. When multiple controllers are configured, Open
vSwitch connects to all of them simultaneously. Details of configuration
are in the vswitch schema documentation.
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 controllers are themselves designed to coordinate
with each other.
An upcoming commit will provide a simple means for coordination between
multiple controllers.
Feature #2495.
Many ofproto settings are controller-related. Upcoming commits will add
to ofproto the ability to support multiple controllers, so it is important
to be able to refer to controller settings as a group. Hence, this commit
bundles them into a new "struct ofproto_controller".
Add a tun_id field which contains the ID of the encapsulating tunnel
on which a packet was received (0 if not received on a tunnel). Also
add an action which allows the tunnel ID to be set for outgoing
packets. At this point there aren't any tunnel implementations so
these fields don't have any effect.
The matching is exposed to OpenFlow by overloading the high 32 bits
of the cookie as the tunnel ID. ovs-ofctl is capable of turning
on this special behavior using a new "tun-cookie" command but this
command is intentially undocumented to avoid it being used without
a full understanding of the consequences.
If "action" is the first word in a flow specification, then we were writing
one byte before the beginning of the string. So overwrite the 'a' in
"action" instead; we know it's really there.
Reported-by: Ghanem Bahri <bahri.ghanem@gmail.com>
If dpif_flow_get() returns an error then we'd better not try to print
the flow (especially not the actions since check_rw_odp_flow() clears
the first action to 0xcc).
Normally ovs-vsctl is run locally, with a Unix domain socket as target, but
it can be useful over SSL as well from a remote host, so this commit
enables that use.
Clean-up a few items related to flow cookies:
- Allow setting the flow cookie as a hex or decimal string
- Consistently print the cookie in hex
- Document the ability to set the flow cookie in ovs-ofctl.
This commit cleans up the locations of a number of files and directories
used. These include:
- Config file lives in /etc/openvswitch/conf.db
- Logs go into /var/log/openvswitch
- ovsdb-server socket is /var/run/openvswitch/db.sock
- Schema goes into /usr/share/openvswitch/vswitch.ovsschema
- PID files go in /var/run/openvswitch
For XenServer, these additional changes are made:
- Cores go in /var/xen/openvswitch
- OVS binaries run in /var/xen/openvswitch
In addition, it attempts to cleanup the XenServer packaging. This
includes referring to the project as "openvswitch" as opposed to the
somewhat presumptuous "vswitch".
Note: Changes to the Debian packaging will be forthcoming.
In nroff manpages, a blank line adds vertical white space. When this is
followed by another command that also starts a new paragraph, the result
is a vertical skip twice as big as the normal inter-paragraph gap. The
solution is to use a line that contains just "." for white space within
the manpage, instead of a blank line. The resulting manpages look better.
ovs-vswitchd used a slightly different way to set the manufacturer,
hardware revision, software revision, serial number, and datapath
description than ovs-openflowd. This standardizes on the ovs-vswitch
style and describes how to use them in the man page.
OpenFlow 1.0 adds "port_no" field to the Port Stat request messages to
allow stats for individual ports to be queried. Port stats for all ports
can still be requested by specifying OFPP_NONE as the port number.
NOTE: OVS at this point is not wire-compatible with OpenFlow 1.0 until
the final commit in this OpenFlow 1.0 set.
OpenFlow 1.0 adds support for matching on IP ToS/DSCP bits.
NOTE: OVS at this point is not wire-compatible with OpenFlow 1.0 until
the final commit in this OpenFlow 1.0 set.
In OpenFlow 1.0, flows have been extended to include an opaque
identifier, referred to as a cookie. The cookie is specified by the
controller when the flow is installed; the cookie will be returned as
part of each flow stats and flow removed message.
NOTE: OVS at this point is not wire-compatible with OpenFlow 1.0 until
the final commit in this Openflow 1.0 set.
In OpenFlow 1.0, a "dp_desc" character array was added to the ofp_desc_stats
structure that allows a human readable description of the datapath to be
provided.
NOTE: OVS at this point is not wire-compatible with OpenFlow 1.0 until
the final commit in this OpenFlow 1.0 set.
