The log should be printed with the member name, not the active member
name, and the active member does not judge whether it is NULL. If null,
OVS will crash with the following backtrace:
(gdb) bt
0 bond_check_admissibility (ofproto/bond.c:877)
1 is_admissible (ofproto/ofproto-dpif-xlate.c:2574)
2 xlate_normal (ofproto/ofproto-dpif-xlate.c:3027)
3 xlate_output_action (ofproto/ofproto-dpif-xlate.c:5284)
4 do_xlate_actions (ofproto/ofproto-dpif-xlate.c:6960)
5 xlate_actions (ofproto/ofproto-dpif-xlate.c:7924)
6 upcall_xlate (ofproto/ofproto-dpif-upcall.c:1237)
7 process_upcall (ofproto/ofproto-dpif-upcall.c:1456)
8 upcall_cb (ofproto/ofproto-dpif-upcall.c:1358)
9 dp_netdev_upcall (lib/dpif-netdev.c:7793)
10 handle_packet_upcall (lib/dpif-netdev.c:8255)
11 fast_path_processing (lib/dpif-netdev.c:8374)
12 dp_netdev_input__ (lib/dpif-netdev.c:8463)
13 dp_netdev_input (lib/dpif-netdev.c:8501)
14 dp_netdev_process_rxq_port (lib/dpif-netdev.c:5337)
15 pmd_thread_main (lib/dpif-netdev.c:6944)
16 ovsthread_wrapper (lib/ovs-thread.c:422)
17 ?? (/lib64/libpthread.so.0)
18 clone (/lib64/libc.so.6)
Fixes: 423416f587 ("lacp: report desync in ovs threads enabling slave")
Signed-off-by: yangchang <yangchang@chinatelecom.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If ovs-tcpdump received HUP or TERM signal, mirror and mirror
interface should be destroyed. This often happens, when
controlling terminal is closed, like ssh session closed, and
other users use kill to terminate it.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Daniel Ding <zhihui.ding@easystack.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Packets that could not be transmitted because the TXQ are full should be
taken into account in the global ovs_tx_failure_drops as it was the case
before commit 29b94e12d5 ("netdev-dpdk: Refactor the DPDK transmit
path.").
netdev_dpdk_eth_tx_burst() returns the number of packets that were *not*
transmitted. Add that number to stats.tx_failure_drops and only include
the packets that were dropped in previous steps afterwards.
Fixes: 29b94e12d5 ("netdev-dpdk: Refactor the DPDK transmit path.")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Robin Jarry <rjarry@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Add tc action flags when adding police action to offload meter table.
There is a restriction that the flag of skip_sw/skip_hw should be same for
filter rule and the independent created tc actions the rule uses. In this
case, if we configure the tc-policy as skip_hw, filter rule will be created
with skip_hw flag and the police action according to meter table will have
no action flag, then flower rule will fail to add to tc kernel system.
To fix this issue, we will add tc action flag when adding police action to
offload a meter table, so it will allow meter table to work in tc software
datapath.
Fixes: 5c039ddc64 ("netdev-linux: Add functions to manipulate tc police action")
Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
This reverts commit dd9881ed55 ('tc: Fix stats dump when
using same meter table')
This patch doesn't solve the tc flow stats update issue and
will lead to failure of system-offloads-traffic testsuite, it
only counts packets surviving after the tc filter, rather than
hitting the filter
A following patch will come up to solve this flow stats update
issue
Signed-off-by: Tianyu Yuan <tianyu.yuan@corigine.com>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
OVN is setting ct drop rule with a ct clear action.
OVS datapath behavior is if there is no forward action
the default is drop.
TC behavior is to continue with next match.
Fix to match tc to ovs behavior by setting last action
attribute as drop instead of pipe.
Also update lastused when parsing ct action.
example rule
recirc_id(0x1),in_port(2),ct_state(+trk),eth(),eth_type(0x0800),ipv4(frag=no),
packets:82, bytes:8036, used:2.108s, actions:ct_clear
Reviewed-by: Maor Dickman <maord@nvidia.com>
Signed-off-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
The stats(byte_count) is got via function call
ofputil_decode_flow_stats_reply() and for OpenFlow15 it will also call
oxs_pull_entry__(). Currently we found on Windows the byte_count
counter is incorrect. It will get the byte_count on OpenFlow15
handling via ntohll(get_unaligned_be64(payload))
Quote the comments below from Ilya Maximets (thanks for the given
soluton and explanation):
static inline uint64_t get_unaligned_u64__(const uint64_t *p_)
...
return ntohll(((uint64_t) p[0] << 56)
| ((uint64_t) p[1] << 48)
| ((uint64_t) p[2] << 40)
| ((uint64_t) p[3] << 32)
| (p[4] << 24)
| (p[5] << 16)
| (p[6] << 8)
| p[7]);
And indeed the expression above has an issue with data types.
The problem is the (p[4] << 24) part. The p[4] itself has a type
'uint8_t' which is unsigned 8bit value. It is not enough to hold
the result of a left shift, so compiler automatically promotes it
to the 'int' by default. But it is *signed* 32bit value.
In your original report p[4] was equal to 0x81. After the left
shift it became 0x81000000. Looks correct, but the type is 'int'.
The next operation that we do is '|' with the previous shifted
bytes that were explicitly converted to uint64_t before the left
shift. So we have uint64_t | int. In this case compiler needs
to extend the 'int' to 'unit64_t' before performing the operation.
And since the 'int' is signed and the sign bit happens to be set
in the 0x81000000, the sign extension is performed in order to
preserve the value. The result is 0xffffffff81000000. And that
is breaking everything else.
From the new test below, it is incorrect for the n_bytes counter via
OpenFlow15 on CMD: ovs-ofctl dump-flows.
With the patch, get_unaligned_u64__() will return correct value to
caller on Windows.
In the output (Got via original CMD without fix) below n_bytes
2177130813 will be incorrectly changed to 18446744071591715133 when
processing OpenFlow15 which is equal to 0xFFFFFFFF81C4613D and here
the p[4] on Windows is 0x81.
With the fix, new compiled ovs-ofctl1025.exe could dump the correct
n_bytes counter Via OpenFlow15.
ovs-ofctl.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=18446744071591715133,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=18446744071591715133,
ovs-ofctl.exe -O OpenFlow10 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
ovs-ofctl.exe dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
With the fix, new compiled ovs-ofctl1025.exe could dump the correct
n_bytes counter Via OpenFlow15.
ovs-ofctl1025.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
Fixes: afa3a93165 ("Add header for access to potentially unaligned data.")
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This patch removes ct_dpif_format_flags() in favor of the existing
format_flags_masked().
This has the extra bonus of showing keys with empty values as "key=0",
instead of showing "key=".
E.g., the following:
NEW tcp,orig=([...]),reply=([...]),id=1800618864,
status=CONFIRMED|SRC_NAT_DONE|DST_NAT_DONE,timeout=120,
protoinfo=(state_orig=SYN_SENT,state_reply=SYN_SENT,wscale_orig=7,
wscale_reply=0,flags_orig=WINDOW_SCALE|SACK_PERM,flags_reply=)
becomes:
NEW tcp,orig=([...]),reply=([...]),id=1800618864,
status=CONFIRMED|SRC_NAT_DONE|DST_NAT_DONE,timeout=120,
protoinfo=(state_orig=SYN_SENT,state_reply=SYN_SENT,wscale_orig=7,
wscale_reply=0,flags_orig=WINDOW_SCALE|SACK_PERM,flags_reply=0)
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Current macros are unable to filter whole seconds, e.g. 'duration:6s'.
This is causing random test failures, most frequently in CirrusCI:
./dpif-netdev.at:370: ovs-ofctl -O OpenFlow13 meter-stats br0 | strip_timers
--- -
+++ /tmp/cirrus-ci-build/tests/testsuite.dir/at-groups/990/stdout
@@ -1,5 +1,5 @@
OFPST_METER reply (OF1.3) (xid=0x2):
-meter:1 flow_count:1 packet_in_count:10 byte_in_count:600 duration:0.0s bands:
+meter:1 flow_count:1 packet_in_count:10 byte_in_count:600 duration:6s bands:
Fix sed matches to correctly handle that scenario.
Repeating the [0-9\.] twice because it is hard to write a shorter
portable version with sed.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
OVN can (and indeed does) set in_port to OFPP_NONE during
the pipeline evaluation. If a sample action follows, it
will be incorrectly skipped.
Per-flow sampling version of:
f0a9000ca ofproto: Fix ipfix not always sampling on egress.
Signed-off-by: Adrian Moreno <amorenoz@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Cited commit introduced a flag in dpif-netdev level, to optimize
performance and avoid hw_miss_packet_recover() for devices with no such
support.
However, there is a race condition between traffic processing and
assigning a 'flow_api' object to the netdev. In such case, EOPNOTSUPP is
returned by netdev_hw_miss_packet_recover() in netdev-offload.c layer
because 'flow_api' is not yet initialized. As a result, the flag is
falsely disabled, and subsequent packets won't be recovered, though they
should.
In order to fix it, move the flag to be in netdev-offload layer, to
avoid that race.
Fixes: 6e50c16518 ("dpif-netdev: Avoid hw_miss_packet_recover() for devices with no support.")
Signed-off-by: Eli Britstein <elibr@nvidia.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Bucket update in the cmap lib is protected by a counter. But hash setting
is possible to be moved before counter update. This patch fix this issue.
Reviewed-by: Ola Liljedahl <Ola.Liljedahl@arm.com>
Reviewed-by: Gavin Hu <Gavin.Hu@arm.com>
Signed-off-by: Yanqin Wei <Yanqin.Wei@arm.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Compaction thread supposed to not change anything in the database
it is working on, since the same data can be accessed by the main
thread at the same time. However, while converting database rows
to JSON objects, strings in the datum will be cloned using
json_clone(), which is a shallow copy, and that will change the
reference counter for the JSON string object. If both the main
thread and the compaction thread will clone/destroy the same object
at the same time we may end up with a broken reference counter
leading to a memory leak or use-after free.
Adding a new argument to the database to JSON conversion to prevent
use of shallow copies from the compaction thread. This way all
the database operations will be truly read-only avoiding the race.
'ovsdb_atom_to_json' and 'ovsdb_datum_to_json' are more widely used,
so creating separate variant for these functions instead of adding
a new argument, to avoid changing a lot of existing code.
Other solution might be to use atomic reference counters, but that
will require API/ABI break, because counter is exposed in public
headers. Also, we can not easily expose atomic functions, so we'll
need to un-inline reference counting with the associated performance
cost.
Fixes: 3cd2cbd684 ("ovsdb: Prepare snapshot JSON in a separate thread.")
Reported-at: https://bugzilla.redhat.com/2133431
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Currently the ovs-tcpdump utility creates a tap port to capture the
frames of a bond port.
If a user want to capture the packets from the bond port which member
interface's mtu is more than 1500. By default the utility creates a
tap port which mtu is 1500, regardless the member interface's mtu config.
So that user can't get the bond port frames which mtu is lager than 1500.
This patch fix this issue by checking the member interface's mtu and
set maximal mtu value to the tap port.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Lin Huang <linhuang@ruijie.com.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When OVS fails to find an OpenFlow port for a packet received
from the upcall it just prints the warning like this:
|INFO|received packet on unassociated datapath port N
However, during the flow translation more information is available
as if the recirculation id wasn't found or it was a packet from
unknown tunnel port. Printing that information might be useful
to understand the origin of the problem.
Port translation functions already support extended error strings,
we just need to pass a variable where to store them.
With the change the output may be:
|INFO|received packet on unassociated datapath port N
(no OpenFlow port for datapath port N)
or
|INFO|received packet on unassociated datapath port N
(no OpenFlow tunnel port for this packet)
or
|INFO|received packet on unassociated datapath port N
(no recirculation data for recirc_id M)
Unfortunately, there is no good way to trigger this code from
current unit tests.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When reference counting for json objects was introduced the
old json_clone() function became json_deep_clone(), but it
still calls shallow json_clone() while cloning objects and
arrays not really producing a deep copy.
Fixing that by making other functions to perform a deep copy
as well. There are no users for this functionality inside
OVS right now, but OVS exports this functionality externally.
'ovstest test-json' extended to test both versions of a clone
on provided inputs.
Fixes: 9854d473ad ("json: Use reference counting in JSON objects")
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
In OpenSSL 3.0 some functions were deprecated and replaced.
This commit adds some #ifdef to build without warning on both
OpenSSL 1.x and OpenSSL 3.x.
For OpenSSL 3.x, the default built-in DH parameters are used (as
suggested by SSL_CTX_set_dh_auto manpage).
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Since OpenSSL upstream commit 1696b8909bbe
("Remove -C from dhparam,dsaparam,ecparam") "openssl dhparam" doesn't
support -C anymore.
This commit changes generate-dhparams-c to generate dhparams.c by parsing
"openssl dhparam -in "$1" -text -noout" output directly.
The generated file won't be used on OpenSSL >= 3.0, but it's still
needed to be generated if OVS is built on OpenSSL < 3.0.
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When segmentation fault occurred in ovn-northd, monitor will try to
restart the ovn-northd daemon process every 10s.
Assume the following scenarios: There is a segmentation fault and
the ovn-northd daemon process does not restart properly every time.
New fds are created each time the ovn-northd daemon process is
restarted by the monitor process, but old fds(fd[0]) owned by
the monitor process was not closed properly. One pipe leak for
each restart of the ovn-northd daemon process. After a long time
file descriptors were exhausted.
Fixes: e2ed6fbeb1 ("fatal-signal: Catch SIGSEGV and print backtrace.")
Signed-off-by: Fengqi Li <lifengqi@inspur.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
The "tcp vconn - refuse connection" test may fail due to a Connection
Refused error. The network stack returns ECONNREFUSED on a reset
connection in SYN_SENT state and EPIPE or ECONNRESET in all other
cases.
2022-09-19T17:45:48Z|00001|socket_util|INFO|0:127.0.0.1: listening on
port 34189
2022-09-19T17:45:48Z|00002|poll_loop|DBG|wakeup due to [POLLOUT][
POLLERR][POLLHUP] on fd 4 (127.0.0.1:47140<->) at ../lib/stream-fd.
c:153
test-vconn: unexpected vconn_connect() return value 111 (Connection
refused)
../../tests/vconn.at:21: exit code was 1, expected 0
530. vconn.at:21: 530. tcp vconn - refuse connection (vconn.at:21):
FAILED (vconn.at:21)
This was observed from a CI system, and isn't a common case.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Same as arpa/inet.h, the netinet/ip6.h on FreeBSD requires
netinet/in.h to be included first. So, adding a similar guard.
Also fixing one instance where this is not respected at the moment.
We do have FreeBSD CI these days, but it is still nice to have
a more clear error message.
Fixes: b2befd5bb2 ("sparse: Add guards to prevent FreeBSD-incompatible #include order.")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Update OVS CLI and relevant documentation to use DPDK 21.11.2.
DPDK 21.11.2 contains fixes for the CVEs listed below:
CVE-2022-28199 [1]
CVE-2022-2132 [2]
A bug was introduced in DPDK 21.11.1 by the commit
01e3dee29c02 ("vhost: fix unsafe vring addresses modifications").
This bug can cause a deadlock when vIOMMU is enabled and NUMA
reallocation of the virtqueues happen.
A fix [3] has been posted and pushed to the DPDK 21.11 branch.
If a user wishes to avoid the issue then it is recommended to use
DPDK 21.11.0 until the release of DPDK 21.11.3.
It should be noted that DPDK 21.11.0 does not benefit from the
numerous bug and CVE fixes addressed since its release.
If a user wishes to benefit from these fixes it is recommended to
use DPDK 21.11.2.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28199
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2132
[3] https://patches.dpdk.org/project/dpdk/patch/20220725203206.427083-2-david.marchand@redhat.com/
Signed-off-by: Michael Phelan <michael.phelan@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Part of the uuidset implementation is taken from the OVN codebase where
it was added via commit 0e77b3bcbfe2 ("ovn-northd-ddlog: New
implementation of ovn-northd based on ddlog.").
We now extend that, adding a few helpers and tests.
Co-authored-by: Leonid Ryzhyk <lryzhyk@vmware.com>
Signed-off-by: Leonid Ryzhyk <lryzhyk@vmware.com>
Co-authored-by: Justin Pettit <jpettit@ovn.org>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
Co-authored-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Reviewed-by: Ales Musil <amusil@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
'as' command of arm version may don't support option '--64', this
patch is to move the avx512 test into x86 branch to avoid this.
Fixes: 352b6c7116 ("dpif-lookup: add avx512 gather implementation.")
Tested-by: Harry van Haaren <harry.van.haaren@intel.com>
Signed-off-by: Cheng Li <lic121@chinatelecom.cn>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Considering two DB rows, 'a' from table A and 'b' from table B (with
column 'ref_a' a reference to table A):
a = {A._uuid=<U1>}
b = {B._uuid=<U2>, B.ref_a=<U1>}
Assuming both records are inserted in the IDL client's in-memory view
of the database, if row 'b' is also deleted in the same run, it should
generate the following tracked changes:
- for table A:
- inserted records: a = {A._uuid=<U1>}
- for table B:
- inserted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
- deleted records: b = {B._uuid=<U2>, B.ref_a=<U1>}
Before this patch, inserted and deleted records in table B
would (in some cases [0]) be b = {B._uuid=<U2>, B.ref_a=[]}.
Having B.ref_a=[] would violate the integrity of the database from
client perspective.
test-ovsdb has also been updated to show that one row can be
both inserted and deleted within one IDL run.
[0] In ovn-controller the fact that the reference is NULL caused a
crash in the following case, when both commands were handled by
ovn-controller within the same loop:
$ ovn-nbctl ls-add sw0 -- lsp-add sw0 sw0-port1 -- \
lsp-set-addresses sw0-port1 "50:54:00:00:00:01 192.168.0.2"
$ ovn-nbctl lsp-del sw0-port1
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2126450
Fixes: 91e1ff5dde ("ovsdb-idl: Don't reparse orphaned rows.")
Signed-off-by: Xavier Simonart <xsimonar@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When icmp error code send back to sender, currently ovs ct can't create
conntrack for the error code properly, this patch mainly fix the bug.
icmp error code test case:
1) packet too big.
2) network unreachable
3) parameter problem
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch implemented meter action, currently, meter only support drop
method and only support one band. The overall implementation is, when a
packet comes in, it will first lookup meter according to the meter id,
then get the band->rates and delta time since last access the same meter
from the meter struct. Add the multiply result(band->rates * delta_time)
to bucket, finally bucket minus the packet size, if the result larger
than zero, allow the packet go through, otherwise deny the packet go
through.
Test case:
1. Setting the size meter size 3M, then the bandwidth was limit
around 3M;
ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,kbps,\
band=type=drop,rate=3000
ovs-ofctl add-flow br-test "table=0,priority=1,ip \
actions=meter:2,normal" -O OpenFlow13
2. Setting the meter size 8M, then the bandwidth was limit
around 8M;
ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,\
kbps,band=type=drop,rate=8000
ovs-ofctl add-flow br-test "table=0,priority=1,ip\
actions=meter:2,normal" -O OpenFlow13
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Implementation on Windows:
IPv6 conntrack ip fragment feature use a link list to store ip
fragment. When ipv6 fragment module receives a fragment packet,
it will store length of the fragment, until to the received length
equal to the packet length before fragmented, it will reassemble
fragment packet to a complete packet and send the complete packet
to conntrack module. After conntrack processed the packet, fragment
module will divide the complete packet into small fragment and send
it to destination. Currently, ipv6 was implemented in a indenpent
module, for the reason it can reduce the risk of introduce bug to
ipv4 fragmenb module.
Testing Topology:
On the Windows VM runs on the ESXi host, two hyper-v ports attached
to the ovs bridge; one hyper-v port worked as client and the
other port worked as server.
Testing Case:
1.UdpV6
a) UdpV6 fragment with multiple ipv6 extension fields.
b) UdpV6 fragment in normal scenario.
c) UdpV6 fragment in nat scenario.
2.IcmpV6
a) IcmpV6 fragment in normal scenario.
b) IcmpV6 fragment in nat scenario.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch mainly support alg field in ct action when process
ftp/tftp traffic. Tftp with alg mainly parse the tftp packet
(IPv4/IPv6), extract connect info from the tftp packet and
create the related connection. For ftp, previous version has
supported process of ftp traffic. However, previous version
regard traffic from or to port 21 as ftp traffic, this is
incorrect in some scenario. This version adds alg field in ct for
ftp traffic, we could use ct(alg=ftp) to process any ftp traffic
from/to any port.
IPv4/IPv6.
Test cases:
1) ftp ipv4/ipv6 use alg field in the normal and nat scenario.
2) tftp ipv4/ipv6 use alg field in the normal and nat scenario.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
In the recent upstream OVS Geneve IPV6 tunnel coding job, it is only supportting the case when the uplink offload
(UDP v6 offload parameter setting on the network adapter configuration) is disabled.
For Geneve IPV6 header setting, it needs set Transmit.IpHeaderChecksum in NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO
to be 0. Elsewise we could observe the found issue on the report page.
After this patch, even the uplink UDP v6 offload is enabled(On WindowsServer 2019) by default the IPV6 Geneve tunnel
could send/receive packets without issues now. I have tested four kinds of network adapter drivers( E1000e ,vmxnet3 and
physical network adapter "Intel(R) Ethernet 10G X710 rNDC " and "Mellanox ConnectX-5 Adapter”. On the default offload
setting for the network adapter(Windows server2019) the IPV6 Geneve tunnel could be setup.
This patch needs to be applied to master and branch-3.0.
Test topo,
Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server.
Windows VM(Windows server2019), vif0( 6000::2/40.1.1.10) vif1(5000:ed4d::2) ------
Ubuntu VM Eth2(5000:ed4d::9), name space ns1 with interface ns1_link(6000::9/40.1.1.2)
WinVM: ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=geneve options:key=flow options:csum=true
options:local_ip="5000:ed4d::2" options:remote_ip="5000:ed4d::9" options:tos=inherit
Ubuntu VM:ovs-vsctl add-port br-int dst_tunnel -- set interface dst_tunnel type=geneve options:local_ip="5000:ed4d::1"
options:remote_ip="5000:ed4d::2"
Reported-at: https://github.com/openvswitch/ovs-issues/issues/260
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Fixes idl.Row's __str__ method to only print if the column exists on
the object. The Row object passed to the 'updates' argument of
Idl.notify only contains a subset of columns. Printing that argument
causes an AttributeError.
Fixes: 6a1c98461b ("Add a __str__ method to idl.Row")
Submitted-at: https://github.com/openvswitch/ovs/pull/392
Acked-by: Terry Wilson <twilson@redhat.com>
Signed-off-by: Christopher Aubut <christopher@aubut.me>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If the PACKET_OUT from controller ends up with sending packet to
a bond interface, the main thread will take locks in the following
order:
handle_openflow
--> take ofproto_mutex
handle_packet_out
packet_xlate
output_normal
bond_update_post_recirc_rules
--> take rwlock in bond.c
If at the same time revalidator thread is processing other packet
with the output to the same bond:
xlate_actions
output_normal
bond_update_post_recirc_rules
--> take rwlock in bond.c
update_recirc_rules
ofproto_dpif_add_internal_flow
ofproto_flow_mod
--> take ofproto_mutex
So, it is possible for these 2 threads to lock each other by
taking one lock and waiting for another thread to release the
second lock.
It is also possible for the main thread to lock itself up by trying
to acquire ofproto_mutex for the second time, if it will actually
proceed with update_recirc_rules() after taking the bond rwlock.
The problem appears to be that bond_update_post_recirc_rules()
is called during the flow translation even if side effects are
prohibited, which is the case for openflow PACKET_OUT handling.
Skipping actual flow updates during the flow translation if
side effects are disabled to avoid the deadlock.
Since flows are not installed now when actions translated for
very first packet, installing initial flows in bond_reconfigure().
This will cover the case of allocating a new recirc_id.
Also checking if we need to update flows in bond_run() to cover
link state changes.
Regression test is added to catch the double lock case.
Reported-at: https://github.com/openvswitch/ovs-issues/issues/259
Reported-by: Daniel Ding <zhihui.ding@easystack.cn>
Fixes: adcf00ba35 ("ofproto/bond: Implement bond megaflow using recirculation")
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
New commands 'revalidator/pause' and 'revalidator/resume'.
Not documented, since these should not be used in production
environments.
Will be used for unit tests in the next commit.
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
GCC 12.2.1 on Fedora 36 generates the following false-positive
warning that is treated as error with -Werror:
tests/test-list.c: In function 'test_list_construction':
tests/test-list.c:110:9: error: 'values' may be used uninitialized
110 | check_list(&list, values, n);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
For some reason it fails to recognize that array will not
be used if 'n' equals zero.
Fix that by just initializing arrays in full before using,
since it's just a test code.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Most of commands in ovs-ofctl and ovs-appctl can display port names
instead of port numbers by using --names option. This change adds
similar functionality to ofproto/trace.
For backward compatibility, the default behavior is the same as
before.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
GNU grep 3.8 started complaining about use of obsolete egrep/fgrep:
egrep: warning: egrep is obsolescent; using grep -E
This breaks tests on such systems. All the instances was cleaned up
from the testsuite, but the checkpatch check is needed to catch issues
in new patches.
Acked-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
When we apply meter police on both directions of TCP traffic, the
dumped stats is shown same (as shown below). This issue is introduced
by modifying the stats update strategy.
...,in_port(6),eth(),eth_type(0x0800),ipv4(frag=no), packets:1488557,
bytes:2089059644, used:0.040s, actions:meter(0),9
...,in_port(9),eth(),eth_type(0x0800),ipv4(frag=no), packets:1488557,
bytes:2089059644, used:0.040s, actions:meter(0),6
In previous patch, after parsing police action, the flower stats will
be updated by dumped meter table stats, which will result in the issue
above.
Thus, the stats of meter table should not be used when dumping flow
stats. Ignore the stats update when police.index belongs to meter.
Fixes: a9b8cdde69 ("tc: Add support parsing tc police action")
Signed-off-by: Tianyu Yuan <tianyu.yuan@corigine.com>
Reviewed-by: Baowen Zheng <baowen.zheng@corigine.com>
Signed-off-by: Simon Horman <simon.horman@corigine.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
13.1 got released in May and now we have problems updating
some packages in 13.0 and CI is failing.
Update to 13.1 to unblock the CI.
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
