By default Open vSwitch tries to configure internal interfaces MTU to
match the bridge minimum, overriding any attempt by the user to
configure it through standard system tools, or the database.
While this works in many simple cases (there are probably many users
that rely on this) it may create problems for more advanced use cases
(like any overlay networks).
This commit allows the user to override the default behavior by
providing an explict MTU in the mtu_request column in the Interface
table.
This means that Open vSwitch will now treat differently database MTU
requests from standard system tools MTU requests (coming from `ip link`
or `ifconfig`), but this seems the best way to remain compatible with
old users while providing a more powerful interface.
Suggested-by: Darrell Ball <dlu998@gmail.com>
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Ben Pfaff <blp@ovn.org>
Tested-by: Joe Stringer <joe@ovn.org>
OVS implementation of buffering packets that are sent to the
controller is not compliant with the OpenFlow specifications after
OpenFlow 1.0, which is possibly true since OpenFlow 1.0 is not really
specifying the packet buffering behavior.
OVS implementation executes the buffered packet against the actions of
the modified or added rule, whereas OpenFlow (since 1.1) specifies
that the packet should be matched against the flow table 0 and
processed accordingly.
Rather than fix this behavior, and potentially break OVS users, the
packet buffering feature is removed altogether. After all, such
packet buffering is an optional OpenFlow feature, and as such any
possible users should continue to work without this feature.
This patch also makes OVS check the received 'buffer_id' values more
rigorously, and fixes some internal users accordingly.
Found by inspection.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
OVS implementation of buffering packets that are sent to the
controller is not compliant with the OpenFlow specifications after
OpenFlow 1.0. OVS implementation executes the buffered packet against
the actions of the modified or added rule, whereas OpenFlow (since
1.1) specifies that the packet should be matched against the flow
table 0 and processed accordingly.
Rather than fix this behavior, and potentially break OVS users, we
propose to remove the feature altogether, starting in OVS 2.7. This
patch announces this in 'NEWS' for OVS 2.6, and adds detail to the FAQ
question about backet buffering.
Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Add support for policing to userspace features and set DPDK v16.07 as
the supported DPDK version for release 2.6.x.
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Acked-by: Daniele Di Proietto <diproiettod@vmware.com>
This commit implements the OVS_ACTION_ATTR_CT action in dpif-netdev.
To allow ofproto-dpif to detect the conntrack feature, flow_put will not
discard anymore flows with ct_* fields set. We still shouldn't allow
flows with NAT bits set, since there is no support for NAT.
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Flavio Leitner <fbl@sysclose.org>
Acked-by: Antonio Fischetti <antonio.fischetti@intel.com>
Add contents section to FAQ and enable internal links in doc for pretty
printing on GitHub.
Signed-off-by: Bhanuprakash Bodireddy <bhanuprakash.bodireddy@intel.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
This document has two different kinds of text:
- The first sections of the document, "Release Strategy" and "Release
Numbering", describe what we've already been doing for most of the
history of Open vSwitch. If there is anything surprising in them,
then it's because our process has not been transparent enough, and not
because we're making a change.
- The final section of the document, "Release Scheduling", is a proposal
for current and future releases. We have not had a regular release
schedule in the past, but it seems important to have one in the
future, so this section requires review and feedback from everyone in
the community.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Russell Bryant <russell@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Mostly backports upstream commit along with other pieces
to make IPv6 tunneling work.
commit 6b26ba3a7d952e611dcde1f3f77ce63bcc70540a
Author: Jiri Benc <jbenc@redhat.com>
openvswitch: netlink attributes for IPv6 tunneling
Add netlink attributes for IPv6 tunnel addresses. This enables IPv6 support
for tunnels.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Acked-by: Jesse Gross <jesse@kernel.org>
I've seen users make this error several times. This FAQ will provide a
useful answer to pass along.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Gurucharan Shetty <guru@ovn.org>
Linux kernel support for features in out-of-tree module no longer depend
on particular versions, as we only support kernels 3.10-4.3; Connection
tracking status has changed recently; and NAT is a brand new feature
with only support in the latest unreleased Linux kernel version.
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Existing DPDK integration is provided by use of command line options which
must be split out and passed to librte in a special manner. However, this
forces any configuration to be passed by way of a special DPDK flag, and
interferes with ovs+dpdk packaging solutions.
This commit delays dpdk initialization until after the OVS database
connection is established, at which point ovs initializes librte. It
pulls all of the config data from the OVS database, and assembles a
new argv/argc pair to be passed along.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Kevin Traynor <kevin.traynor@intel.com>
Acked-by: Daniele Di Proietto <diproiettod@vmware.com>
The "VLAN splinters" feature works around buggy device drivers in
old Linux versions. But support for the old kernel is dropped, So
now all supported kernel vlan drivers should be working fine with
OVS kernel datapath.
Following patch removes this deprecated feature.
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
For a given release this is listed in the INSTALL.DPDK.md
but it gets asked quite a bit on the mailing list, so create
a table in the FAQ.
Signed-off-by: Kevin Traynor <kevin.traynor@intel.com>
Acked-by: Daniele Di Proietto <diproiettod@vmware.com>
The tc_police structure was filled with a value calculated in bits
instead of bytes while bytes were expected. This led the setting
of an x8 higher burst value.
Documentation and defaults have been corrected accordingly to minimize
nuisances on users sticking to the defaults.
The suggested burst value is now 80% of policing rate to make sure
TCP works correctly.
Signed-off-by: Miguel Angel Ajo <majopela@redhat.com>
Tested-by: Miguel Angel Ajo <majopela@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Currently OVS out of tree datapath supports a large number of kernel
versions. From 2.6.32 to 4.3 and various distribution-specific
kernels. But at this point major features are only available on more
recent kernels. For example, stateful services are only available
starting in kernel 3.10 and STT is available on starting with 3.5.
Since these features are becoming essential to many OVS deployments,
and the effort of maintaining the backports is high. We have decided
to drop support for older kernel. Following patch drops supports
for kernel older than 3.10.
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Acked-by: Jesse Gross <jesse@kernel.org>
This patch introduces the support for GRE TEB (trasparent ethernet bridging)
for the windows datapath.
The GRE support is based on http://tools.ietf.org/html/rfc2890, without
taking into account the GRE sequence, and it supports only the GRE protocol
type 6558 (trasparent ethernet bridging) like its linux counterpart.
Util.h: define the GRE pool tag
Vport.c/h: sort the includes alphabetically
add the function OvsFindTunnelVportByPortType which searches the
tunnelVportsArray for a given port type
Actions.c : sort the includes alphabetically
call the GRE encapsulation / decapsulation functions when needed
Gre.c/h : add GRE type defines
add initialization/cleanup functions
add encapsulation / decapsulation functions with software offloads
(hardware offloads will be added in a separate patch)
support
Tested using: PSPING
(https://technet.microsoft.com/en-us/sysinternals/psping.aspx)
(ICMP, TCP, UDP) with various packet lengths
IPERF3
(https://iperf.fr/iperf-download.php)
(TCP, UDP) with various options
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Acked-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
This is an easy way to keep track of the features supported by the
different datapaths.
Nithin helped filling the list for the Hyper-V port.
CC: Nithin Raju <nithin@vmware.com>
Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: Nithin Raju <nithin@vmware.com>
Acked-by: Justin Pettit <jpettit@ovn.org>
Some recent features have more stringent requirements for kernel
versions than the FAQ describes. Add an entry to be more explicit on
which features work with which versions of the upstream kernel.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Following patch adds support for lwtunnel to OVS datapath.
With this change OVS datapath detect lwtunnel support and
make use of new APIs if available. On older kernel where the
support is not there the backported tunnel modules are used.
These backported tunnel devices acts as lwtunnel devices.
I tried to keep backported module same as upstream for easier
bug-fix backport. Since STT and LISP are not upstream OVS
always needs to use respective modules from tunnel compat layer.
To make it work on kernel 4.3 I have converted STT and LISP
modules to lwtunnel API model.
lwtunnel make use of skb-dst to pass tunnel information to the
tunnel module. On older kernel this is not possible. So the in
case of old kernel metadata ref is stored in OVS_CB and direct
call to tunnel transmit function is made by respective tunnel
vport modules. Similarly on receive side tunnel recv directly
call netdev-vport-receive to pass the skb to OVS.
Major backported components include:
Geneve, GRE, VXLAN, ip_tunnel, udp-tunnels GRO.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Joe Stringer <joe@ovn.org>
Acked-by: Jesse Gross <jesse@kernel.org>
The plotnetcfg is an open source tool to visualy represent
relationship between network interfaces on a single host.
It helps to understand the path of a packet on a host.
Signed-off-by: Flavio Leitner <fbl@sysclose.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Unlike system interfaces, DPDK enabled interfaces must have their interface
type explicitly set when used to create ports. Mention this in relevant parts
of the documentation and add references to INTALL.DPDK.md, where there are many
examples.
Signed-off-by: Billy O'Mahony <billy.o.mahony@intel.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The Stateless TCP Tunnel (STT) protocol encapsulates traffic in
IPv4/TCP packets.
STT uses TCP segmentation offload available in most of NIC. On
packet xmit STT driver appends STT header along with TCP header
to the packet. For GSO packet GSO parameters are set according
to tunnel configuration and packet is handed over to networking
stack. This allows use of segmentation offload available in NICs
The protocol is documented at
http://www.ietf.org/archive/id/draft-davie-stt-06.txt
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
The kernel module can already support outer UDP checksums for
Geneve and VXLAN using the standard checksum flag in tunnel
metadata. This makes userspace aware of the capability so that
users can enable it on tunnel ports.
There is a complication in that there is no way for userspace to
probe or detect if the kernel does not support this capability
in order to warn the user. In this case, connectivity will appear
to function normally but packets will not be checksum protected.
This is mainly an issue for VXLAN which has existed in the kernel
for a some time without checksum support - while there are also
a few kernel versions that support Geneve only without checksums,
they are much less common.
There isn't a particularly good solution to the compatibility
issue without introducing a larger capabilities structure. However,
UDP checksums are likely to be used only rarely at this point in
time and the VXLAN spec (where the main problem lies) recommends
against them. Therefore, this is considered to be an advanced user
feature and we settle for just documenting the issue.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Pritesh Kothari <pritesh.kothari@cisco.com>
We've been warning about the change since 2.1, which was released a year
ago.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
