Autotest .at files often have lines with samples of expected output from
various programs, which fairly often includes leading tabs, so this warning
causes false positives there.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Reviewed-by: Aaron Conole <aconole@redhat.com>
This change the testsuite macro to release the resources
configured by ovs-vswitchd when exiting as it used to be.
Fixes: 0f28164be02ac ("netdev-linux: make tap devices persistent")
Fixes: fe13ccdca6a22 ("vswitchd: Add --cleanup option to the 'appctl
exit' command")
Reported-by: Eric Garver <e@erig.me>
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Joe Stringer <joe@ovn.org>
Clang 4.0 complains:
../tests/test-hash.c:160:16: error: taking address of packed member 'b' of
class or structure 'offset_ovs_u128' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
in0 = &in0_data.b;
Set the bit in the aligned u128 first then copy the contents into the
offset u128 so that we don't have to take the address of the non-aligned
u128 and pass it to set_bit128.
For the 256byte_hash, fix it up so that it's actually testing the 256B
hash inside a 32-bit offset u128 as well.
Suggested-by: Ben Pfaff <blp@ovn.org>
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Some of the abbreviations at the head of this document, like LN and PN,
turn out to not be very useful, so expand them for clarity.
Some of the statements in this document are more about planning the design
than the current design. Remove these for clarity.
Port_Binding rows used to all be about physical locations, except for
patch ports, but there are more kinds of rows now. Elaborate for clarity.
Expand on the purpose of the Datapath_Binding table.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Russell Bryant <russell@ovn.org>
This patch makes ovn-northd copy all string-string pairs in
external_ids column of the Logical_Switch_Port table in Northbound
database to the equivalent column of the Port_Binding table in
Southbound database.
OpenStack Neutron will add some useful data to NB database that can be
later read by networking-ovn-metadata-agent without the need of
maintaining a connection to NB database. This data would include
the CIDR's of a port or the project and device ID's which are needed
when talking to Nova to request metadata.
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
Signed-off-by: Russell Bryant <russell@ovn.org>
Add SSL protocol and cipher columns to SSL tables in northbound
and southbound databases. Start nb/sb ovsdb-server with command-
line options to use these columns. Add support to ovn-nbctl
and ovn-sbctl "set-ssl" commands for user-friendly management
of these settings.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The checks to populate ct_orig_tuple in miniflow_extract
include recirc_id being non-zero. Now, ct_orig_tuple
is only populated if the packet has passed through the
connection tracker, which is a prerequisite for having
valid ct_orig_tuple information. This is recognized by
having a non-zero ct_state. This has an added benefit
of saving some processing time.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The function tcp_payload_length is moved to a private
include file to be used by other conntrack files. A
sanity check is added for general use, although
previous usage was safe in that filtering is already
done by the time it is called.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch exports PYTHONCOERCECLOCALE=0 when you have Python3 tests
enabled.
This is needed since testsuite forces LC_ALL=C and Python 3, with PEP 538,
prints the following warning on stderr:
"Python runtime initialized with LC_CTYPE=C (a locale with default ASCII
encoding), which may cause Unicode compatibility problems. Using C.UTF-8,
C.utf8, or UTF-8 (if available) as alternative Unicode-compatible locales is
recommended."
AT_CHECK reports it as an error since stderr is not empty as it should be.
This patch is needed, at least, on Fedora 26 and Rawhide (backported PEP
538 on Python 3.6).
This will also be needed on any distribution with Python 3.7 (PEP 538).
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Include --ssl-protocols and --ssl-ciphers options in run-time
help output.
Sample output with this change:
PKI configuration (required to use SSL):
-p, --private-key=FILE file with private key
-c, --certificate=FILE file with certificate for private key
-C, --ca-cert=FILE file with peer CA certificate
--bootstrap-ca-cert=FILE file with peer CA certificate to read or create
SSL options:
--ssl-protocols=PROTOS list of SSL protocols to enable
--ssl-ciphers=CIPHERS list of SSL ciphers to enable
Output formatting options:
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
It is important to maintain the original state when
the device already exists in the system.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
When using data path type "netdev", bridge port is a tun device
and when OVS restarts, that device and its network configuration
is lost.
This patch enables the tap device to persist instead.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Install a handler to flush routes and release devices when
the program is terminating.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
I has an idea what these were but that idea was somewhat incorrect and
out-of-date. Add a minimal guide to fill in these gaps, along with a
warning about how useless these things generally are now (yay,
vhost-user).
Signed-off-by: Stephen Finucane <stephen@that.guru>
Cc: Ciara Loftus <ciara.loftus@intel.com>
Cc: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Apparently dpdkvhostuser interfaces are inferior to dpdkvhostuserclient.
Explain why.
Signed-off-by: Stephen Finucane <stephen@that.guru>
Cc: Ciara Loftus <ciara.loftus@intel.com>
Cc: Kevin Traynor <ktraynor@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Kevin Traynor <ktraynor@redhat.com>
Mult value (bfd.DetectMult in RFC5880) is hard-coded and equal to 3 in
current openvswitch. As a consequence remote and local mult is the same.
In this commit the mult (Detect Multiplier/bfd.DetectMult/Detect Mult)
can be set on each interface setting the mult=<value> in bfd Column
in Interface table of ovsdb database.
Example:
ovs-vsctl set Interface p1 bfd:mult=4
sets mult=4 on p1 interface
The modification based on RFC5880 June 2010.
The relevant paragraphs are:
4.1. Generic BFD Control Packet Format
6.8.4. Calculating the Detection Time
6.8.7. Transmitting BFD Control Packets
6.8.12. Detect Multiplier Change
The mult value is set to default 3 if it is not set in ovsdb. This
provides backward compatibility to previous openvswitch behaviour.
The RFC5880 says in 6.8.1 that DetectMult shall be a non-zero integer.
In RFC5880 4.1. "Detect Mult" has 8 bit length and is declared
as a 8 bit unsigned integer in bfd.c.
Consequently mult value shall be greater than 0 and less then 256.
In case of incorrect mult value is given in ovsdb the default value (3)
will be set and a message is logged into ovs-vswitchd.log on that.
Local or remote mult value change is also logged into ovs-vswitchd.log.
Since remote and local mult is not the same calculation of detect time
has been changed. Due to RFC5880 6.8.4 Detection Time is calculated using
mult value of the remote system.
Detection time is recalculated due to remote mult change.
The BFD packet transmission jitter is different in case of mult=1
due to RFC5880 6.8.7. The maximum interval of the transmitted bfd packet
is 90% of the transmission interval.
The value of remote mult is printed in the last line of the output of
ovs-appctl bfd/show command with label: Remote Detect Mult.
There is a feature in openvswitch connected with forwarding_if_rx that
is not the part of RFC5880. This feature also uses mult value but it is
not specified if local or remote since it was the
same in original code. The relevant description in code:
/* When 'bfd->forwarding_if_rx' is set, at least one bfd control packet
* is required to be received every 100 * bfd->cfg_min_rx. If bfd
* control packet is not received within this interval, even if data
* packets are received, the bfd->forwarding will still be false. */
Due to lack of specification local mult value is used for calculation of
forwarding_if_rx_detect_time. This detect time is recalculated at mult
change if forwarding_if_rx is true and bfd is in UP state.
A new unit test has been added: "bfd - Edit the Detect Mult values"
The following cases are tested:
- Without setting mult the mult will be the default value (3).
- The setting of the lowest (1) and highest (255) valid mult value
and the detection of remote mult value.
- The setting of out of range mult value (0, 256) in ovsdb results
sets default value in ovs-vswitchd
- Clearing non default mult value from ovsdb results sets default
value in ovs-vswitchd.
Signed-off-by: Gábor Szűcs <gabor.sz.cs@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Two new tests are added and two other tests were
enhanced. The use of tcpdump to verify checksums
is introduced.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Daniele Di Proietto <diproiettod@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch adds orig tuple checking and context
recovery; NAT interactions are factored in.
Orig tuple support exists to better handle policy
changes.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Acked-by: Daniele Di Proietto <diproiettod@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch includes more complete support
for icmp4 and icmp6 related NAT handling.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Acked-by: Daniele Di Proietto <diproiettod@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch introduces NAT support for the userspace datapath.
Most conntrack module changes are in this patch, with the
exception of icmp related handling and recent orig tuple
support.
The per packet scope of lookups for NAT and un_NAT is at
the bucket level rather than global. One hash table is
introduced to support create/delete handling. The create/delete
events may be further optimized, if the need becomes clear.
Some NAT options with limited utility (persistent, random) are
not supported yet, but will be supported in a later patch.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Daniele Di Proietto <diproiettod@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Packet batch sorting is removed for three reasons:
1) The following patches for NAT change the locking
marshalling so batching loses benefit.
2) For real mixtures of flows either in hypervisors
or gateways, the batch sorting won't provide benefit
and will just be a tax.
3) Code clarity.
Signed-off-by: Darrell Ball <dlu998@gmail.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Daniele Di Proietto <diproiettod@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This patch is based on the "datapath: enable vxlangpe creation in compat mode"
from Yi Yang. It introduces an extension option "gpe" to the vxlan port in the
netdev-dpdk datapath. Description of vxlan gpe protocoll was added to header
file lib/packets.h. In the vxlan specific methods the different packet are
introduced and handled.
Added VXLAN GPE tunnel push test.
Signed-off-by: Yi Yang <yi.y.yang at intel.com>
Signed-off-by: Georg Schmuecking <georg.schmuecking@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Add a boolean "layer3" configuration option for tunnel vports.
The layer3 option defaults to false for all ports except LISP.
GRE ports accept both true and false for "layer3".
A tunnel vport configured with layer3=true receives L3 packets.
which are then converted to Ethernet packets by pushing a dummy
Ethernet heder at the ingress of the OpenFlow pipeline. The
Ethernet header of a packet is stripped before sending to a
layer3 tunnel vport.
Presently a single GRE vport cannot carry both L2 and L3 packets.
But it is possible to create two GRE vports representing the same
GRE tunel, one with layer3=false, the other with layer3=true.
L2 packet from the tunnel are received on the first vport, L3
packets on the second. The controller must send packets to the
layer3 GRE vport to tunnel them without their Ethernet header.
Units tests have been added to check the L3 tunnel handling.
LISP tunnels are not yet supported by the netdev userspace datapath.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com>
Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Ports have a new layer3 attribute if they send/receive L3 packets.
The packet_type included in structs dp_packet and flow is considered in
ofproto-dpif. The classical L2 match fields (dl_src, dl_dst, dl_type, and
vlan_tci, vlan_vid, vlan_pcp) now have Ethernet as pre-requisite.
A dummy ethernet header is pushed to L3 packets received from L3 ports
before the the pipeline processing starts. The ethernet header is popped
before sending a packet to a L3 port.
For datapath ports that can receive L2 or L3 packets, the packet_type
becomes part of the flow key for datapath flows and is handled
appropriately in dpif-netdev.
In the 'else' branch in flow_put_on_pmd() function, the additional check
flow_equal(&match.flow, &netdev_flow->flow) was removed, as a) the dpcls
lookup is sufficient to uniquely identify a flow and b) it caused false
negatives because the flow in netdev->flow may not properly masked.
In dpif_netdev_flow_put() we now use the same method for constructing the
netdev_flow_key as the one used when adding the flow to the dplcs to make sure
these always match. The function netdev_flow_key_from_flow() used so far was
not only inefficient but sometimes caused mismatches and subsequent flow
update failures.
The kernel datapath does not support the packet_type match field.
Instead it encodes the packet type implictly by the presence or absence of
the Ethernet attribute in the flow key and mask.
This patch filters the PACKET_TYPE attribute out of netlink flow key and
mask to be sent to the kernel datapath.
Signed-off-by: Lorand Jakab <lojakab@cisco.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Yi Yang <yi.y.yang@intel.com>
Signed-off-by: Jan Scheurich <jan.scheurich@ericsson.com>
Co-authored-by: Zoltan Balogh <zoltan.balogh@ericsson.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Code generated by this program includes constructs like this:
switch (((uint64_t) vendor << 32) | (type << 16) | code)
with variables uint32_t vendor, uint16_t type, uint16_t code. By C rules,
"type << 16" has type "int", which means that it will be sign-extended to
64 bits when ORed with uint64_t. Thus, if 'type' has bit 15 set, then
the overall result will have all of its top 32 bits set, which is not
the desired result.
This commit fixes the problem.
No actual error types used in OVS or OpenFlow have bit 15 set, so this
does not fix a user-visible problem.
Found by Coverity.
Reported-at: https://scan3.coverity.com/reports.htm#v16889/p10449/fileInstanceId=14762955&defectInstanceId=4304798&mergedDefectId=180406
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
If a switch claimed to support an instruction that OVS does not know about,
then print_table_instruction_features() would read past the end of the
array of instruction names. This fixes the problem.
None of the other uses of print_table_instruction_features() appear to have
the same problem.
Found by Coverity.
Reported-at: https://scan3.coverity.com/reports.htm#v16889/p10449/fileInstanceId=14762675&defectInstanceId=4305296&mergedDefectId=179859
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
The code in ofputil_decode_port_mod() was originally meant to mask
the returned 'config' value against 'mask'. That is, only bits that are
marked in 'mask' as to be modified can be set to 1-bits in the returned
'config' value; it doesn't really entirely make sense otherwise. The
actual code to do this was dead, though. This fixes that problem.
In a quick skim of callers, I wasn't able to see an actual user-visible
bug that this fixes.
Found by Coverity.
Reported-at: https://scan3.coverity.com/reports.htm#v16889/p10449/fileInstanceId=14762682&defectInstanceId=4304822&mergedDefectId=180422
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
This function attempts to open a bunch of new handlers. If it fails, it
attempts to close all the handlers that have already been opened.
Unfortunately, the loop to close the opened handlers used the wrong array
index: 'i' instead of 'j'. This fixes the problem.
Found by Coverity.
Reported-at: https://scan3.coverity.com/reports.htm#v16889/p10449/fileInstanceId=14762827&defectInstanceId=4305351&mergedDefectId=180429
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Justin Pettit <jpettit@ovn.org>
When trying to configure a system port as type=internal it could start
an infinite port creation loop. When this happens you will see the
following log messages:
2017-06-01T09:00:17.900Z|02813|dpif|WARN|system@ovs-system: failed to add ve01_1 as port: File exists
2017-06-01T09:00:17.900Z|02814|bridge|WARN|could not add network device ve01_1 to ofproto (File exists)
2017-06-01T09:00:17.907Z|02815|bridge|INFO|bridge bzb: added interface ve01_1 on port 2
2017-06-01T09:00:17.909Z|02816|bridge|INFO|bridge bzb: deleted interface ve01_1 on port 2
2017-06-01T09:00:17.914Z|02817|dpif|WARN|system@ovs-system: failed to add ve01_1 as port: File exists
2017-06-01T09:00:17.914Z|02818|bridge|WARN|could not add network device ve01_1 to ofproto (File exists)
2017-06-01T09:00:17.921Z|02819|bridge|INFO|bridge bzb: added interface ve01_1 on port 3
2017-06-01T09:00:17.923Z|02820|bridge|INFO|bridge bzb: deleted interface ve01_1 on port 3
2017-06-01T09:00:17.929Z|02821|dpif|WARN|system@ovs-system: failed to add ve01_1 as port: File exists
2017-06-01T09:00:17.929Z|02822|bridge|WARN|could not add network device ve01_1 to ofproto (File exists)
2017-06-01T09:00:17.936Z|02823|bridge|INFO|bridge bzb: added interface ve01_1 on port 4
...
...
This is how to replicate it:
ip link add name ve01_1 type veth peer name ve01_2
ovs-vsctl add-br bzb
ovs-vsctl add-port bzb ve01_1
ovs-vsctl set interface ve01_1 type=internal
ip link set dev ve01_1 up
ip link set dev ve01_2 up
When changing the type to internal, the async configuration logic get
triggered and because the type has changed it will delete the
interface and the ofproto port. Next it will call iface_do_create() to
re-create the interface as internal. Because we just deleted the
interface netdev_open() will try to recreate it as internal.
However this will fail with EEXIST as a system interface already
exists withe the name.
Up till here all is fine...
Now some ipv6 route change comes along for the ve01_1 interface, and
the route infrastructure will call netdev_open(). This will create the
interface of type system.
Next the configuration verify process gets triggered due to
if_notifier_changed() being true. We now retry the above, but because
the interface exists (although in the system class) it will use it,
and create the interface successfully.
This triggers another if notification, causing yet another config
update, and because the system != internal reconfiguration happens and
it start from the top...
So the fix as presented below is causing netdev_open() only to return
the existing device for the class type requested (if the type is
specified).
Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
