When slowpath meter is configured, add meter action when translate
sample action.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Allow action upcall meters, i.e. slowpath and controller meters,
to be added and displayed.
Keep track of datapath meter ID of those action upcall meters in
ofproto to aid action translation. Later patches will make use of them.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Add 'meter_ids', an id-pool object to manage datapath meter id, i.e.
provider_meter_id.
Currently, only userspace datapath supports meter, and it implements
the provider_meter_id management. Moving this function to 'backer'
allows other datapath implementation to share the same logic.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Currently, meters are stored in a fixed pointer array. It is not
very efficient since the controller, at least in theory, can
pick any meter id (up to the limits to uint32_t), not necessarily
within the lower end of a region, or in close range to each other.
In particular, OFPM_SLOWPATH and OFPM_CONTROLLER meters are specified
at the high region.
Switching to using hmap. Ofproto layer does not restrict
the number of meters that controller can add, nor does it care
about the value of meter_id. Datapth limits the number of meters
ofproto layer can support at run time.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
Specify the event mask with CT commit including bits for CT features
exposed at the OVS interface (mark and label changes in addition to
basic creation and destruction of conntrack entries).
Without this any listener of conntrack update events will typically
(depending on system configuration) receive events for each L4 (e.g.,
TCP) state machine change, which can multiply the number of events
received per connection.
By including the new, related, and destroy events any listener of new
conntrack events gets notified of new related and non-related
connections, and any listener of destroy events will get notified of
deleted (typically timed out) conntrack entries.
By including the flags for mark and labels, any listener of conntrack
update events gets notified whenever the connmark or conntrack labels
are changed from the values reported within the new events.
VMware-BZ: #1837218
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Normally ICMP responses are in the reply direction of a conntrack
entry. This test exercises an ICMP response to the original direction
of the conntrack entry.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Upstream commit:
commit cf5d70918877c6a6655dc1e92e2ebb661ce904fd
Author: Jarno Rajahalme <jarno@ovn.org>
Date: Fri Apr 14 14:26:38 2017 -0700
openvswitch: Delete conntrack entry clashing with an expectation.
Conntrack helpers do not check for a potentially clashing conntrack
entry when creating a new expectation. Also, nf_conntrack_in() will
check expectations (via init_conntrack()) only if a conntrack entry
can not be found. The expectation for a packet which also matches an
existing conntrack entry will not be removed by conntrack, and is
currently handled inconsistently by OVS, as OVS expects the
expectation to be removed when the connection tracking entry matching
that expectation is confirmed.
It should be noted that normally an IP stack would not allow reuse of
a 5-tuple of an old (possibly lingering) connection for a new data
connection, so this is somewhat unlikely corner case. However, it is
possible that a misbehaving source could cause conntrack entries be
created that could then interfere with new related connections.
Fix this in the OVS module by deleting the clashing conntrack entry
after an expectation has been matched. This causes the following
nf_conntrack_in() call also find the expectation and remove it when
creating the new conntrack entry, as well as the forthcoming reply
direction packets to match the new related connection instead of the
old clashing conntrack entry.
Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
Reported-by: Yang Song <yangsong@vmware.com>
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Upstream commit 5a8145f7b222 ("netfilter: labels: don't emit ct event
if labels were not changed"), released in Linux 4.7, changed
nf_connlabels_replace() to trigger conntrack event for a label change
only when the labels actually changed. Without this change an update
event is triggered even if the labels already have the values they are
being set to.
There is no way we can detect this functional change from Linux
headers, so provide replacements that work the same for older Linux
releases regardless if a distribution provides backports or not.
VMware-BZ: #1837218
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
Upstream commit:
commit 120645513f55a4ac5543120d9e79925d30a0156f
Author: Jarno Rajahalme <jarno@ovn.org>
Date: Fri Apr 21 16:48:06 2017 -0700
openvswitch: Add eventmask support to CT action.
Add a new optional conntrack action attribute OVS_CT_ATTR_EVENTMASK,
which can be used in conjunction with the commit flag
(OVS_CT_ATTR_COMMIT) to set the mask of bits specifying which
conntrack events (IPCT_*) should be delivered via the Netfilter
netlink multicast groups. Default behavior depends on the system
configuration, but typically a lot of events are delivered. This can be
very chatty for the NFNLGRP_CONNTRACK_UPDATE group, even if only some
types of events are of interest.
Netfilter core init_conntrack() adds the event cache extension, so we
only need to set the ctmask value. However, if the system is
configured without support for events, the setting will be skipped due
to extension not being found.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
Acked-by: Joe Stringer <joe@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Joe Stringer <joe@ovn.org>
There are a few cases where more introspection into ukey transitions
would be relevant for logging or assertion. Track the SOURCE_LOCATOR and
thread id when states are transitioned and use these for logging.
Suggested-by: Jarno Rajahalme <jarno@ovn.org>
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
There is a case where a flow is dumped from the kernel after the ukey is
already transitioned into an EVICTING/EVICTED/DELETED state, and the
revalidator thread attempts to shift that into UKEY_OPERATIONAL because
it was able to dump the flow from the datapath. This resulted in
triggering the assert in transition_ukey(). Detect this condition and
skip handling the flow (as it's already on its way out).
Users report:
> Program terminated with signal SIGABRT, Aborted.
> raise () from /lib/x86_64-linux-gnu/libc.so.6
> raise () from /lib/x86_64-linux-gnu/libc.so.6
> abort () from /lib/x86_64-linux-gnu/libc.so.6
> ovs_abort_valist
> vlog_abort_valist
> vlog_abort
> ovs_assert_failure
> transition_ukey (ukey=<optimized out>, dst=<optimized out>)
> at ofproto/ofproto-dpif-upcall.c:1674
> revalidate (revalidator=0x1cb36c8) at ofproto/ofproto-dpif-upcall.c:2324
> udpif_revalidator (arg=0x1cb36c8) at ofproto/ofproto-dpif-upcall.c:901
> ovsthread_wrapper (aux_=<optimized out>) at lib/ovs-thread.c:348
> start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
> clone () from /lib/x86_64-linux-gnu/libc.so.6
VMware-BZ: #1857694
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Commit b89d25e569 made the "router" DHCPv4 option optional instead of
mandatory. This did not actually change the schema, but there's no good
way for a client of the northbound database to know if this change is
present without bumping the schema version. This is needed for a client to
work with versions before and after this change.
Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1670666
Fixes: b89d25e569 ("ovn: Modify the DHCPv4 router option to optional")
Signed-off-by: Russell Bryant <russell@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
These references have moved since the MAINTAINERS file was introduced.
Update them.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Commit 618a5b45ae ("rhel: Avoid logrotate error if /var/run/openvswitch
does not exist") updated the RHEL logrotate configuration. This commit
makes similar changes for Debian, by synchronizing with the RHEL version.
In particular:
- Indent to match logrotate.conf(5) examples.
- Use "sharedscripts" flag, because the postrotate script only needs to
run once regardless of the number of rotations.
- Drop "delaycompress", because the postrotate script does make daemons
reopen their log files.
- Ignore errors calling vlog/reopen.
Also make similar changes to the xenserver logrotate script. I confirmed
via Twitter that the xenserver packaging still has users.
CC: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Gurucharan Shetty <guru@ovn.org>
The memory leak was triggered each time on
creating a netflow and subsequently deleting it.
Signed-off-by: Sha Zhang <zhangsha.zhang@huawei.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Using dpdk-socket-mem to allocate memory for some NUMA nodes
but leaving blank for subsequent ones is equivalent of assigning
0 MB memory to those subsequent nodes. Document this behavior.
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch adds support of OFPR_PACKET_OUT as the packet-in reason.
This packet-in reason is a required feature for OF1.4+, and it indicates
that the associated packet-in message to the controller is triggered when
the switch is processing a packet-out message. This reason code is enabled
by default when OF1.4+ is used.
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Starting from OpenFlow 1.4+, OFPR_ACTION is split into four more descriptive
reasons, OFPR_APPLY_ACTION, OFPR_ACTION_SET, OFPR_GROUP, and OFPR_PACKET_OUT.
OVS maintains the new reason code internally, and it currently supports the
first three reason code. If the version of an established OpenFlow connection
is less than 1.4, OVS converts the internal reason code back to OFPR_ACTION to
be backward compatible. However, the internal packet-in reason code mask is
not properly maintained for the older OpenFlow version that may emit the
packet-in messages wth the new reason code. It is because OVS does not enable
the new reason code internally in the reason code mask for older OpenFlow
version. This commit tries to address the aforementioned issue.
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Otherwise, through the "make rpm-fedora" build fedora package will be error:
error: Installed (but unpackaged) file(s) found:
/usr/bin/ovn-detrace
/usr/share/man/man1/ovn-detrace.1.gz
Signed-off-by: Guoshuai Li <ligs@dtdream.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
When bridges destroyed, which stp enabled, you can
still get stp info via the command 'ovs-appctl stp/show'.
And the rstp is also in the same case. We should unref
them. The rstp/stp ports have been unregistered via
'ofproto_port_unregister' function when ports destroyed.
We will unref rstp/stp struct in the 'destruct' of
ofproto-dpif provider.
Signed-off-by: nickcooper-zhangtonghao <nic@opencloud.tech>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
When uuid starts with 0s, lflow-list will fail if leading 0s are
not included in command argument. This leads to unexpected results
considering that leading 0s are usually not shown up in cookies
of OpenFlow outputs of tools such as ovs-ofctl dump-flows
and ovs-appctl ofproto/trace. E.g.
lflow uuid: 0c16ceb4-0409-484b-8297-a6e7f264ac2d
$ ovn-nbctl lflow-list 0c16ceb4 # works fine
$ ovn-nbctl lflow-list c16ceb4 # doesn't work
This patch fixes the problem.
Signed-off-by: Han Zhou <zhouhan@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Open vSwitch datapath recirculates packets for tunneling, i.e. the
incoming packets are encapsulated at first pass. Further actions are
applied on encapsulated packets on the second pass after
recirculating. The proposed patch compute and append the post tunnel
actions at the time of translation itself instead of recirculating at
datapath. These actions are solely depends on tunnel attributes so
there is no need of datapath recirculation. By avoiding the
recirculation at datapath, the patch offers up to 30% performance
improvement for VXLAN tunneling in our testing. The action execution
logic is using the new CLONE action to define the packet cloning when
the actions are combined. The length in the CLONE action specifies
the size of nested action set.
It also fixing the testsuite failures that are introduced by nested
CLONE action in tunneling.
Signed-off-by: Sugesh Chandran <sugesh.chandran@intel.com>
Signed-off-by: Zoltán Balogh <zoltan.balogh@ericsson.com>
Co-authored-by: Zoltán Balogh <zoltan.balogh@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This may help to suppress warnings from know-it-all compilers, and it helps
to make the code clearer too.
Reported-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Eric Garver <e@erig.me>
A python script to decode ofproto/trace output to add ovn lflow
information inline. It expands lflow further to ACLs when relevant.
$ ovs-appctl ofproto/trace ... | ovn-decode
Signed-off-by: Han Zhou <zhouhan@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
It will be helpful for trouble-shooting if we can link a logical flow
back to the ACL that generated it. This patch is to add a stage-hint as
an external-id in lflow. The hint contains stage specific information.
Now only lflows in ACL stages have hint, which is the ACL uuid, though
the same mechanism can be used to add hint for other stages later.
Signed-off-by: Han Zhou <zhouhan@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Sphinx 1.3 renamed the 'default' theme to 'classic' and configured the
'alabaster' theme as the new default. To prevent breaking existing
builds, the 'default' name was reserved as an alias for 'classic' [1].
However, initially this raised a warning [1] with a message to use
'classic' instead. This warning was removed in 1.3.2 [2], but it will
result in errors (due to the use of the '-W' flag) for Sphinx 1.3.0 and
1.3.1 users.
Mitigate the issue by not setting a theme if the 'ovs_sphinx_theme'
package is absent. This will result in Sphinx using its default theme,
be that 'classic' (Sphinx < 1.3) or 'alabaster'.
[1] https://github.com/sphinx-doc/sphinx/commit/68021b0bd
[2] https://github.com/sphinx-doc/sphinx/commit/034c4e942
Signed-off-by: Stephen Finucane <stephen@that.guru>
Cc: Matthew Thode <mthode@mthode.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This file has enough going on as-is without keeping all this commented
out noise around.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Ben Pfaff <blp@ovn.org>
We don't care about building LaTeX documentation, so there's no need to
keep this build cruft around.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Let's start with a simple one that lets us focus on setting up most of
the required "infrastructure" for building man pages using Sphinx.
This changes the 'check-htmldocs' target to 'check-docs' as its now
responsible for building man page docs too.
Other than that, hurrah for (mostly) legible syntaxes.
[1] http://www.tldp.org/HOWTO/Man-Page/q2.html
Signed-off-by: Stephen Finucane <stephen@that.guru>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Currently interface additions are logged but not deletions. This
makes system debugging, such as confirming OVSDB transaction are
timely replicated harder than necessary.
Signed-off-by: Andy Zhou <azhou@ovn.org>
Acked-by: Jarno Rajahalme <jarno@ovn.org>
On Google cloud, a VM gets a /32 IP address. When OVN
is deployed on such VMs, the OVN gateway router's IP
address becomes a /32 IP address. This commit allows
such a configuration.
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
There are cases where the default gateway of a interface is in
a different subnet than its IP address. Linux allows such
configuration. For e.g, one could set the IP address of
a Linux interface as 172.16.1.2/32 and then give it a default
gateway of 172.16.1.1. This can be done for e.g. by running the
following commands.
ifconfig eth0 172.16.1.2 netmask 255.255.255.255 broadcast 172.16.1.2
route add 172.16.1.1 dev eth0
route add default gw 172.16.1.1
The above configuration is what google cloud uses for its VMs.
In OVN static routes, we currently have the ability to specify the
router port via which the packet needs to be pushed out to reach a
next hop. But when support for IPv6 was added, we only allowed
nexthops to be in the same subnet as one of the router's IP addresses.
This commit relaxes that restriction. When a outport is specified in
static routes and when a nexthop is in a different subnet than any
of the router IP addresses, we will assume that it is reachable from
the first IP address of the router. Since this is a corner case,
we just go with the first IP address. If it turns out that there
are more cases, we can let users choose the IP address via which
the destination is reachable.
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
The idea is to use OFPPS_LIVE bit to propagate link aliveness state
towards the controller also when sending port status. The
ofport->may_enable flag could be used for this purpose, thus any
change in LIVE bit is propagated towards conrtoller in
OFPT_PORT_STATUS message. OFPPS_LIVE bit is set only when links is
not down not administratively, neither operationally as recommended
in OF papers. I added 9 new unit tests to verify link state changes
when monitored with cfm, bfd or lacp for OF 1.3, OF 1.4 and OF 1.5.
I updated related unit tests according to the changes of
ofproto-dpif.
Signed-off-by: László Sürü <laszlo.suru at ericsson.com>
Co-authored-by: Zoltán Balogh <zoltan.balogh at ericsson.com>
Signed-off-by: Zoltán Balogh <zoltan.balogh at ericsson.com>
Co-authored-by: Jan Scheurich <jan.scheurich at ericsson.com>
Signed-off-by: Jan Scheurich <jan.scheurich at ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
