Make sure we take the return values into consideration so we can
break early in case of failures. This makes the ovs-ctl helper more
accurate in reporting the real status of its managing processes.
Signed-off-by: Markos Chandras <mchandras@suse.de>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Aaron Conole <aconole@redhat.com>
Make sure we communicate failures to the caller when start_daemon fails
to start a process as the caller may not be able to proceed after this.
Signed-off-by: Markos Chandras <mchandras@suse.de>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Aaron Conole <aconole@redhat.com>
OVS GRE IPsec tunnel support has multiple issues, Therefore
it was deprecated in OVS 2.6.
Following patch removes support for GRE IPsec and allows external
IPsec tunnel management for any type of tunnel not just GRE.
e.g. user can encrypt Geneve or VxLan traffic.
It can be done by using openflow pipeline to set skb-mark
and using IPsec keying daemons to implement IPsec tunnels.
This packet can be matched for the skb-mark to encrypt
selective tunnel traffic.
VMware-BZ: 1710701
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Acked-by: Ansis Atteka <aatteka@ovn.org>
ovs-lib creates several directories directly from the script, but
doesn't make any attempt to ensure that the correct SELinux context is
applied to these directories. As a result, the created directories end
up with type var_run_t rather than openvswitch_var_run_t.
During reboot using a tmpfs for /var/run, startup scripts will invoke
ovs-lib to create these directories with the wrong context. If SELinux
is enabled, OVS will fail to start as it cannot write to this directory.
Fix the issue by sprinkling "restorecon" in each of the places where
directories are created. In practice, many of these should otherwise be
handled by packaging scripts but if they exist then we should ensure the
correct SELinux context is set.
On systems where 'restorecon' is unavailable, this should be a no-op.
VMware-BZ: #1732672
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ansis Atteka <aatteka@ovn.org>
When using tunnel TLVs (at the moment, this means Geneve options), a
controller must first map the class and type onto an appropriate OXM
field so that it can be used in OVS flow operations. This table is
managed using OpenFlow extensions.
The original code that added support for TLVs made the mapping table
global as a simplification. However, this is not really logically
correct as the OpenFlow management commands are operating on a per-bridge
basis. This removes the original limitation to make the table per-bridge.
One nice result of this change is that it is generally clearer whether
the tunnel metadata is in datapath or OpenFlow format. Rather than
allowing ad-hoc format changes and trying to handle both formats in the
tunnel metadata functions, the format is more clearly separated by function.
Datapaths (both kernel and userspace) use datapath format and it is not
changed during the upcall process. At the beginning of action translation,
tunnel metadata is converted to OpenFlow format and flows and wildcards
are translated back at the end of the process.
As an additional benefit, this change improves performance in some flow
setup situations by keeping the tunnel metadata in the original packet
format in more cases. This helps when copies need to be made as the amount
of data touched is only what is present in the packet rather than the
maximum amount of metadata supported.
Co-authored-by: Madhu Challa <challa@noironetworks.com>
Signed-off-by: Madhu Challa <challa@noironetworks.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Add a new select group selection method "dp_hash", which uses minimal
number of bits from the datapath calculated packet hash to inform the
select group bucket selection. This makes the datapath flows more
generic resulting in less upcalls to userspace, but adds recirculation
prior to group selection.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Only allow fields when "selection_method=hash". Only allow
selection_method_param when a non-nil selection_method is given.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
The script accidentally hardcoded the bridge name as 'br-int',
a leftover from testing.
Reported-by: Huanle Han <hanxueluo@gmail.com>
Signed-off-by: Jesse Gross <jesse@kernel.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Add support for OFPT_PACKET_OUT messages in bundles.
While ovs-ofctl already has a packet-out command, we did not have a
string parser for it, as the parsing was done directly from command
line arguments.
This patch adds the string parser for packet-out messages, adds
support for it into the 'ovs-ofctl packet-out' command, and adds a new
ofctl/packet-out ovs-appctl command that can be used when ovs-ofctl is
used as a flow monitor. The old 'ovs-ofctl packet-out syntax is
deprecated' and will be removed in a later OVS release.
The new packet-out parser is further supported with the ovs-ofctl
bundle command, which allows bundles to mix flow mods, group mods and
packet-out messages. Also the packet-outs in bundles are only
executed if the whole bundle is successful. A failing packet-out
translation may also make the whole bundle to fail.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
On Windows we require service_start to be called to parse and setup
requirements for '--detach' argument.
Affected binaries: ovn-trace, ovsdb-client, ovs-testcontroller.
Subsequent patches will be sent to adapt the tests with the new features.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Scripts that integrate OVS with a distribution often save and
restore flows across disruptive events, such as an upgrade. The
ovs-save utility generates a script to assist with this.
When flows include tunnel metadata, we also need to restore the
TLV mappings before the flows are re-added. Otherwise, the instance
of OVS receiving the new flows won't know the meaning of these
fields and will ignore them.
Signed-off-by: Jesse Gross <jesse@kernel.org>
When flow fields are sorted before dumping in ovs-ofctl, each
significant field is extracted for sorting. However, in the case of
tunnel metadata a mapping table is necessary to know where each
field begins and ends. This information is current stripped off before
fetching the field data and returned field is simply zeroed. This
makes sorting based on tunnel metadata non-deterministic.
We have the tunnel allocation stored in match metadata with each
flow, so we can simply extract the data from there rather than
trying to build and populate a global mapping table.
Signed-off-by: Jesse Gross <jesse@kernel.org>
Acked-by: Ben Pfaff <blp@ovn.org>
When flows are read by ovs-ofctl (either from a switch or a file),
tunnel metadata space is dynamically allocated since there isn't a
preset table. This works well for single flows but doesn't handle
groups of flows that must be compared to each other. In this case,
each flow will have its own independent allocation making comparisons
meaningless.
Even worse is that when these matches are later serialized (either
for display or in NXM format), the metadata allocation has been
stripped off of the matches. The serialization code then attempts to
use the global table, which is also not available, leading to a
dereference of a NULL pointer.
Solving this problem requires building an overall metadata table.
Since we don't know the maximum size of a field (particularly for
flows read from a file), it's necessary to do this in two passes.
The first pass records the maximum size for each field as well as
stores the received matches. The second pass creates a metadata
table based on the sizes, adjusts the match layout based on the new
allocation, and then replays the stored matches for comparison.
Later serialization will used the generated table to output the
flows.
Signed-off-by: Jesse Gross <jesse@kernel.org>
Acked-by: Ben Pfaff <blp@ovn.org>
It is useful to know the contents of interfaces file
for debugging in debian based systems.
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
This commit removes the 'dpdkvhostcuse' port type from the userspace
datapath. vhost-cuse ports are quickly becoming obsolete as the
vhost-user port type begins to support a greater feature-set thanks to
the addition of things like vhost-user multiqueue and potential
upcoming features like vhost-user client-mode and vhost-user reconnect.
The feature is also expected to be removed from DPDK soon.
One potential drawback of the removal of this support is that a
userspace vHost port type is not available in OVS for use with older
versions of QEMU (pre v2.2). Considering v2.2 is nearly two years old
this should however be a low impact change.
Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Ilya Maximets <i.maximets@samsung.com>
ovs-dpctl and ovs-ofctl lack a read-only option to prevent
running of commands that perform read-write operations. Add
it and the necessary scaffolding to each.
Signed-off-by: Ryan Moats <rmoats@us.ibm.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Added a few examples and clarifications to the man page to explain points I
had difficulty figuring out without reading code/tests.
Signed-off-by: Ori Shoshan <ori.shoshan@guardicore.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Remove duplicated delete attempts and error messages during distcheck
clean procedure.
The problem is that during clean up procedure of distcheck:
rmdir: failed to remove ‘/openvswitch-2.5.90/_inst/share/openvswitch/bugtool-plugins/’: Directory not empty
rmdir: failed to remove ‘/openvswitch-2.5.90/_inst/share/openvswitch/bugtool-plugins/ovn/network-status ’: No such file or directory
The first entry is caused by xml file which is kept flat in the directory
structure (not in the subdirectory as it is for other plugins), and rmdir
"tries" to remove folder which keeps all plugins files and folders. That is
why additional check if directory is not empty is added, to prevent that.
The second entry is cause by some other commit when ovs plugin has been added:
stem=`echo "$$plugin" | sed 's,ovn/,,'`; \
So in that sense directory path has been modified during removal of xml
file, but it hasn't been updated during directory removal.
I didn't want to really change this logic, as I'm not sure if there
something else can be stored in this directory, but it was very tempting to
remove everything just by:
rm -rf "$(DESTDIR)$(bugtoolpluginsdir)/*"
Signed-off-by: Michal Weglicki <michalx.weglicki@intel.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
While going through a FIPS certification process we discovered that
ovs-bugtool uses MD5 to identify the contents of files. FIPS doesn't allow
use of the obsolete and broken MD5 algorithm, so this commit switches to
SHA-256.
In a way, this is a silly requirement. ovs-bugtool only uses MD5 to
identify file content, mostly to ensure that the contents of the bug report
have not been corrupted. MD5 is perfectly adequate for that purpose; in
fact a 16-bit CRC would probably be adequate. On the other hand, there is
basically no cost and no disadvantage to switching to SHA-256, so why not
do it? That's why I think that this is a reasonable change.
VMware-BZ: #1708786
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Use ds_get_line() instead of hand rolling it. Rearrange the logic
to removes some duplication.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: William Tu <u9012063@gmail.com>
On systemd-era hosts, OS name and version are available in sanitized
format from /etc/os-release(5) without resorting to calling (and thus
requiring) lsb_release. Support populating system-type and system-version
from /etc/os-release, prefer it over lsb_release, but permit overriding
via the OVS-specific system-type.conf and system-version.conf.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1350550
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
While running the ovn-scale-test [1] port-binding tests [2], I notice a
continual stream of messages such as this:
2016-08-04 13:05:28.705 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-] bind lport_0996bf_cikzNO to sandbox-172.16.200.24 on ovn-farm-node-uat-dal09-compute-325
2016-08-04 13:05:28.712 547 INFO paramiko.transport [-] Connected (version 2.0, client OpenSSH_6.6.1p1)
2016-08-04 13:05:28.805 547 INFO paramiko.transport [-] Authentication (publickey) successful!
2016-08-04T13:05:28Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04 13:05:29.042 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-] bind lport_0996bf_tvovcK to sandbox-172.16.200.24 on ovn-farm-node-uat-dal09-compute-325
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04 13:05:29.285 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-] bind lport_0996bf_HwG7AK to sandbox-172.16.200.24 on ovn-farm-node-uat-dal09-compute-325
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04 13:05:29.505 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-] bind lport_0996bf_Lqbv92 to sandbox-172.16.200.24 on ovn-farm-node-uat-dal09-compute-325
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04 13:05:29.724 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-] bind lport_0996bf_6f8uQW to sandbox-172.16.200.24 on ovn-farm-node-uat-dal09-compute-325
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No such file or directory)
2016-08-04 13:05:29.944 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-] bind lport_0996bf_nKl2XF to sandbox-172.16.200.24 on ovn-farm-node-uat-dal09-compute-325
Tracing these down, this is due to the check in vsctl_parent_process_info(),
which is verifying if the parent process can be opened. Since ovn-scale-test
runs sandboxes in containers, and these are run as root, there is no /proc/0
in the container. Thus, the check fails, and the error message is printed out.
It's unclear what value this log message provides, so removing it clears up
this problem and is probably the best option.
For the init process with pid of zero, this patch returns "init",
instead of trying to read from /proc/0/cmdline, which does not exist.
[1] https://github.com/openvswitch/ovn-scale-test
[2] https://github.com/openvswitch/ovn-scale-test/blob/master/rally_ovs/plugins/ovs/scenarios/ovn.py#L255
Signed-off-by: Kyle Mestery <mestery@mestery.com>
Acked-by: Andy Zhou <azhou@ovn.org>
It's slow to add --wait to every ovn-nbctl command; only the last command
needs it. But it's sometimes inconvenient to add it to the last command
if it's in a loop, etc. This makes it possible to separately wait for
the OVN southbound or hypervisors to catch up to the northbound.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Allow adding group mods in OpenFlow bundles. Group mods are executed
atomically with any flow mods in the same bundle. Mods are executed
in order, so that groups appearing in flow actions need to be inserted
in to the bundle before the dependent flow mods.
ovs-ofctl is enhanced to allow the '--bundle' option with group mod
commands. add-groups file format is enhanced to allow each line to be
preceded by one of the keywords "add", "modify", "delete",
"add_or_mod", "insert_bucket", or "remove_bucket".
ovs-ofctl also has a new "bundle" command that reads a file in which
each line contains one flow mod or group mod, and then executes them
all as a single atomic bundle transaction.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Use ofputil_uninit_group_mod() instead of
ofputil_bucket_list_destroy(). Currently these have the same effect,
but this will change in a following patch.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Change mf_are_prereqs_ok() take a flow_wildcards pointer, so that the
wildcards can be set at the same time as the prerequisiteis are
checked. This makes it easier to write more obviously correct code.
Remove the functions mf_mask_field_and_prereqs() and
mf_mask_field_and_prereqs__(), and make the callers first check the
prerequisites, while supplying 'wc' to mf_are_prereqs_ok(), and if
successful, mask the bits of the field that were read or set using
mf_mask_field_masked().
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
It is possible that a bundle add message fails, but the following
commit succeeds, since the message was not added to the bundle. Make
ovs-ofctl fail also in these cases.
Also, the commit should not be sent if any of the bundled messages
failed. To make sure all the errors are received before the commit is
sent, a barrier is required before sending the commit message.
Finally, make vconn collect bundle errors into a list instead of
calling a callback. This makes bundle error management simpler.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Separate rule versioning to lib/versions.h to make it easier to use
versioning for other data types.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
This commit allows the ovs-ctl command to spawn daemons without the
internal process monitor. This is useful when integrating with,
ex. systemd, which provides its own monitoring facilities.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Reviewed-by: Markos Chandras <mchandras@suse.de>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: Flavio Fernandes <flavio@flaviof.com>
Acked-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Until now, there has been no reliable for the CMS (or ovn-nbctl, or
anything else) to detect when changes made to the northbound configuration
have been passed through to the southbound database or to the hypervisors.
This commit adds this feature to the system, by adding sequence numbers
to the northbound and southbound databases and adding code in ovn-nbctl,
ovn-northd, and ovn-controller to keep those sequence numbers up-to-date.
The biggest user-visible change from this commit is new a new option
--wait to ovn-nbctl. With --wait=sb, ovn-nbctl now waits for ovn-northd
to update the southbound database; with --wait=hv, it waits for the
changes to make their way to Open vSwitch on every hypervisor.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Russell Bryant <russell@ovn.org>
Without this fix, the remainder of the paragraph appears in bold, which was
not intended.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Commit 9b5422a98f81("ovs-lib: Try to call exit before killing.")
introduced a problem where internal interfaces are destroyed and
recreated, losing their IP address.
Commit 9aad5a5a96ba("ovs-vswitchd: Preserve datapath ports across
graceful shutdown.") fixed the problem by changing ovs-vswitchd
to preserve the ports on `ovs-appctl exit`. Unfortunately, this fix is
not enough during upgrade from <= 2.5.0, where an old ovs-vswitchd is
running (without the fix) and a new ovs-lib script is performing the
restart.
The problem seem to affect both RHEL and ubuntu.
This commit fixes the upgrade by looking at the running daemon
version and avoid using `ovs-appctl exit` if it's < 2.5.90.
Suggested-by: Gurucharan Shetty <guru@ovn.org>
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
To easily allow both in- and out-of-tree building of the Python
wrapper for the OVS JSON parser (e.g. w/ pip), move json.h to
include/openvswitch. This also requires moving lib/{hmap,shash}.h.
Both hmap.h and shash.h were #include-ing "util.h" even though the
headers themselves did not use anything from there, but rather from
include/openvswitch/util.h. Fixing that required including util.h
in several C files mostly due to OVS_NOT_REACHED and things like
xmalloc.
Signed-off-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The upcoming OpenSSL 1.1.0 release disables use of SHA-1, which breaks the
OVS unit tests, which use SHA-1. We last tried to switch to SHA-512 in
2014 with commit 9ff33ca75e ("ovs-pki: Use SHA-512 instead of MD5 as
message digest."), but we had to downgrade to SHA-1 in commit 4a1f961068
("ovs-pki: Use SHA-1 instead of SHA-512 as message digest.") because
XenServer did not support SHA-512. It has been a few years, so let's try
again.
CC: 828478@bugs.debian.org
Reported-at: https://bugs.debian.org/828478
Reported-by: Kurt Roeckx <kurt@roeckx.be>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
From time to time it confuses users that "group" actions disappear when
using OpenFlow 1.0.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Fix python2-specific code in ovs-bugtool:
* python2 long() is the same as python2 int() and python3 int(). Convert
the long() to int().
* raw_input() was renamed to input(). Use python-six's input() on python2.
* Drop lambda tuple unpacking, we can go back to regular lambda syntax.
* file() can be replaced with open().
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Since the 'commit' flag is required to set the mark and/or labels, the
set values are always available for following lookups.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
The --ovs-vswitchd-wrapper=WRAPPER line is referenced twice so drop it.
Signed-off-by: Markos Chandras <mchandras@suse.de>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch adds support for a new Group Mod command OFPGC_ADD_OR_MOD to
OVS for all OpenFlow versions that support groups (OF11 and higher).
The new ADD_OR_MOD creates a group that does not yet exist (like ADD)
and modifies an existing group (like MODIFY).
Rational: In OpenFlow 1.x the Group Mod commands OFPGC_ADD and
OFPGC_MODIFY have strict semantics: ADD fails if the group exists,
while MODIFY fails if the group does not exist. This requires a
controller to exactly know the state of the switch when programming a
group in order not run the risk of getting an OFP Error message in
response. This is hard to achieve and maintain at all times in view of
possible switch and controller restarts or other connection losses
between switch and controller.
Due to the un-acknowledged nature of the Group Mod message programming
groups safely and efficiently at the same time is virtually impossible
as the controller has to either query the existence of the group prior
to each Group Mod message or to insert a Barrier Request/Reply after
every group to be sure that no Error can be received at a later stage
and require a complicated roll-back of any dependent actions taken
between the failed Group Mod and the Error.
In the ovs-ofctl command line the ADD_OR_MOD command is made available
through the new option --may-create in the mod-group command:
$ ovs-ofctl -Oopenflow13 del-groups br-int group_id=100
$ ovs-ofctl -Oopenflow13 mod-group br-int
group_id=100,type=indirect,bucket=actions=2 OFPT_ERROR (OF1.3)
(xid=0x2): OFPGMFC_UNKNOWN_GROUP OFPT_GROUP_MOD (OF1.3) (xid=0x2):
MOD group_id=100,type=indirect,bucket=actions=output:2
$ ovs-ofctl -Oopenflow13 --may-create mod-group br-int
group_id=100,type=indirect,bucket=actions=2
$ ovs-ofctl -Oopenflow13 dump-groups br-int
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
group_id=100,type=indirect,bucket=actions=output:2
$ ovs-ofctl -Oopenflow13 --may-create mod-group br-int
group_id=100,type=indirect,bucket=actions=3
$ ovs-ofctl -Oopenflow13 dump-groups br-int
OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
group_id=100,type=indirect,bucket=actions=output:3
Signed-off-by: Jan Scheurich <jan.scheurich at web.de>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Some options (such as -c X), when passed to tcpdump will cause it to
halt. When this occurs, ovs-tcpdump will not recognize that such
an event has happened, and will spew newlines across the screen
running forever. To fix this, ovs-tcpdump can poll and then raise a
KeyboardInterrupt event.
Now, when the underlying dump-cmd (such as tcpdump, tshark, etc.)
actually signals exit, ovs-tcpdump follows the SIGINT path, telling the
database to clean up. Exit is signalled by either returning, 'killing',
or closing the output descriptor.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The original implementation of ovs-tcpdump conflated interfaces and
ports needlessly. This commit changes ovs-tcpdump to only consider the
port name when looking up the corresponding bridge.
Reported-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
Tested-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Currently Open vSwitch is unable to create or connect to Unix Domain
Sockets outside designated 'run' directory, because of fear of potential
remote exploits where a hacked remote OVSDB manager would tell Open vSwitch
to connect to a unix domain socket owned by other daemon on the same
hypervisor.
This patch allows to disable this behavior by changing
/etc/default/openvswitch (Ubuntu) or /etc/sysconfig/openvswitch (RHEL)
file to:
...
OVS_CTL_OPTS=--no-self-confinement
...
Note, that it is better to stick with default behavior, unless:
1. You have Open vSwitch running under SELinux or AppArmor
that would prevent OVS from messing with sockets owned by other
daemons; OR
2. You are sure that relying on OpenFlow handshake is enough to
prevent OVS to adversely interact with those other daemons
running on the same hypervisor; OR
3. You don't have much worries of remote exploits in the first
place, because perhaps OVSDB manager is running on the same host
as OVS.
The initial use-case for this patch is to allow to connect to OpenFlow
controller that has its socket outside OVS run directory. However,
in the future it could be generalized to allow to disable self-confinement
for other things like DPDK vhost-user sockets or anything else
that is specifiable in OVSDB with full path.
Signed-off-by: Ansis Atteka <aatteka@ovn.org>
Acked-by: Jesse Gross <jesse@kernel.org>
VMware-BZ: #1525857
