git://git.onelab.eu / sliver-openvswitch.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
Prepare for post-2.2.0 (2.2.90).
[sliver-openvswitch.git] / FAQ
diff --git a/FAQ b/FAQ
index df7b6ef..c43b0c8 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -149,6 +149,7 @@ A: The following table lists the Linux kernel versions against which the
        1.11.x     2.6.18 to 3.8
        2.0.x      2.6.32 to 3.10
        2.1.x      2.6.32 to 3.11
        1.11.x     2.6.18 to 3.8
        2.0.x      2.6.32 to 3.10
        2.1.x      2.6.32 to 3.11
+       2.2.x      2.6.32 to 3.13
 
    Open vSwitch userspace should also work with the Linux kernel module
    built into Linux 3.3 and later.
 
    Open vSwitch userspace should also work with the Linux kernel module
    built into Linux 3.3 and later.
@@ -157,38 +158,37 @@ A: The following table lists the Linux kernel versions against which the
    It should build against almost any kernel, certainly against 2.6.32
    and later.
 
    It should build against almost any kernel, certainly against 2.6.32
    and later.
 
-Q: What Linux kernel versions does IPFIX flow monitoring work with?
+Q: I get an error like this when I configure Open vSwitch:
 
 
-A: IPFIX flow monitoring requires the Linux kernel module from Open
-   vSwitch version 1.10.90 or later.
+       configure: error: Linux kernel in <dir> is version <x>, but
+       version newer than <y> is not supported (please refer to the
+       FAQ for advice)
 
 
-Q: Should userspace or kernel be upgraded first to minimize downtime?
+   What should I do?
 
 
-   In general, the Open vSwitch userspace should be used with the
-   kernel version included in the same release or with the version
-   from upstream Linux.  However, when upgrading between two releases
-   of Open vSwitch it is best to migrate userspace first to reduce
-   the possibility of incompatibilities.
+A: If there is a newer version of Open vSwitch, consider building that
+   one, because it may support the kernel that you are building
+   against.  (To find out, consult the table in the previous answer.)
+
+   Otherwise, use the Linux kernel module supplied with the kernel
+   that you are using.  All versions of Open vSwitch userspace are
+   compatible with all versions of the Open vSwitch kernel module, so
+   this will also work.  See also the following question.
 
 Q: What features are not available in the Open vSwitch kernel datapath
    that ships as part of the upstream Linux kernel?
 
 
 Q: What features are not available in the Open vSwitch kernel datapath
    that ships as part of the upstream Linux kernel?
 
-A: The kernel module in upstream Linux 3.3 and later does not include
-   tunnel virtual ports, that is, interfaces with type "gre",
-   "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "lisp".  It is
-   possible to create tunnels in Linux and attach them to Open vSwitch
-   as system devices.  However, they cannot be dynamically created
-   through the OVSDB protocol or set the tunnel ids as a flow action.
-
-   Work is in progress in adding tunnel virtual ports to the upstream
-   Linux version of the Open vSwitch kernel module.  For now, if you
-   need these features, use the kernel module from the Open vSwitch
+A: The kernel module in upstream Linux does not include support for
+   LISP. Work is in progress to add support for LISP to the upstream
+   Linux version of the Open vSwitch kernel module. For now, if you
+   need this feature, use the kernel module from the Open vSwitch
    distribution instead of the upstream Linux kernel module.
 
    distribution instead of the upstream Linux kernel module.
 
-   The upstream kernel module does not include patch ports, but this
-   only matters for Open vSwitch 1.9 and earlier, because Open vSwitch
-   1.10 and later implement patch ports without using this kernel
-   feature.
+   Certain features require kernel support to function or to have
+   reasonable performance. If the ovs-vswitchd log file indicates that
+   a feature is not supported, consider upgrading to a newer upstream
+   Linux release or using the kernel module paired with the userspace
+   distribution.
 
 Q: What features are not available when using the userspace datapath?
 
 
 Q: What features are not available when using the userspace datapath?
 
@@ -197,6 +197,19 @@ A: Tunnel virtual ports are not supported, as described in the
    actions.  On Linux kernels before 2.6.39, maximum-sized VLAN packets
    may not be transmitted.
 
    actions.  On Linux kernels before 2.6.39, maximum-sized VLAN packets
    may not be transmitted.
 
+Q: What Linux kernel versions does IPFIX flow monitoring work with?
+
+A: IPFIX flow monitoring requires the Linux kernel module from Open
+   vSwitch version 1.10.90 or later.
+
+Q: Should userspace or kernel be upgraded first to minimize downtime?
+
+   In general, the Open vSwitch userspace should be used with the
+   kernel version included in the same release or with the version
+   from upstream Linux.  However, when upgrading between two releases
+   of Open vSwitch it is best to migrate userspace first to reduce
+   the possibility of incompatibilities.
+
 Q: What happened to the bridge compatibility feature?
 
 A: Bridge compatibility was a feature of Open vSwitch 1.9 and earlier.
 Q: What happened to the bridge compatibility feature?
 
 A: Bridge compatibility was a feature of Open vSwitch 1.9 and earlier.
@@ -646,6 +659,17 @@ A: In version 1.9.0, OVS switched to using a single datapath that is
    shared by all bridges of that type.  The "ovs-appctl dpif/*"
    commands provide similar functionality that is scoped by the bridge.
 
    shared by all bridges of that type.  The "ovs-appctl dpif/*"
    commands provide similar functionality that is scoped by the bridge.
 
+Q: I created a GRE port using ovs-vsctl so why can't I send traffic or
+   see the port in the datapath?
+
+A: On Linux kernels before 3.11, the OVS GRE module and Linux GRE module
+   cannot be loaded at the same time. It is likely that on your system the
+   Linux GRE module is already loaded and blocking OVS (to confirm, check
+   dmesg for errors regarding GRE registration). To fix this, unload all
+   GRE modules that appear in lsmod as well as the OVS kernel module. You
+   can then reload the OVS module following the directions in INSTALL,
+   which will ensure that dependencies are satisfied.
+
 
 Quality of Service (QoS)
 ------------------------
 
 Quality of Service (QoS)
 ------------------------
@@ -723,6 +747,19 @@ A: Did you install OpenFlow flows that use your queues?  This is the
 
    Refer to the previous question for an example.
 
 
    Refer to the previous question for an example.
 
+Q: I'd like to take advantage of some QoS feature that Open vSwitch
+   doesn't yet support.  How do I do that?
+
+A: Open vSwitch does not implement QoS itself.  Instead, it can
+   configure some, but not all, of the QoS features built into the
+   Linux kernel.  If you need some QoS feature that OVS cannot
+   configure itself, then the first step is to figure out whether
+   Linux QoS supports that feature.  If it does, then you can submit a
+   patch to support Open vSwitch configuration for that feature, or
+   you can use "tc" directly to configure the feature in Linux.  (If
+   Linux QoS doesn't support the feature you want, then first you have
+   to add that support to Linux.)
+
 Q: I configured QoS, correctly, but my measurements show that it isn't
    working as well as I expect.
 
 Q: I configured QoS, correctly, but my measurements show that it isn't
    working as well as I expect.
 
@@ -755,6 +792,13 @@ A: With the Linux kernel, the Open vSwitch implementation of QoS has
    tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or
    mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
 
    tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or
    mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
 
+Q: Does Open vSwitch support OpenFlow meters?
+
+A: Since version 2.0, Open vSwitch has OpenFlow protocol support for
+   OpenFlow meters.  There is no implementation of meters in the Open
+   vSwitch software switch (neither the kernel-based nor userspace
+   switches).
+
 
 VLANs
 -----
 
 VLANs
 -----
@@ -1064,20 +1108,25 @@ Using OpenFlow (Manually or Via Controller)
 
 Q: What versions of OpenFlow does Open vSwitch support?
 
 
 Q: What versions of OpenFlow does Open vSwitch support?
 
-A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus
-   extensions that bring in many of the features from later versions
-   of OpenFlow).
+A: The following table lists the versions of OpenFlow supported by
+   each version of Open vSwitch:
 
 
-   Open vSwitch 1.10 and later have experimental support for OpenFlow
-   1.2 and 1.3.  On these versions of Open vSwitch, the following
-   command enables OpenFlow 1.0, 1.2, and 1.3 on bridge br0:
+       Open vSwitch      OF1.0  OF1.1  OF1.2  OF1.3  OF1.4
+       ===============   =====  =====  =====  =====  =====
+       1.9 and earlier    yes    ---    ---    ---    ---
+       1.10               yes    ---    [*]    [*]    ---
+       1.11               yes    ---    [*]    [*]    ---
+       2.0                yes    [*]    [*]    [*]    ---
+       2.1                yes    [*]    [*]    [*]    ---
+       2.2                yes    [*]    [*]    [*]    [%]
 
 
-       ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
+       [*] Supported, with one or more missing features.
+       [%] Support is unsafe: ovs-vswitchd will abort when certain
+           unimplemented features are tested.
 
 
-   Open vSwitch version 1.12 and later will have experimental support
-   for OpenFlow 1.1, 1.2, and 1.3.  On these versions of Open vSwitch,
-   the following command enables OpenFlow 1.0, 1.1, 1.2, and 1.3 on
-   bridge br0:
+   Because of missing features, OpenFlow 1.1, 1.2, and 1.3 must be
+   enabled manually.  The following command enables OpenFlow 1.0, 1.1,
+   1.2, and 1.3 on bridge br0:
 
        ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
 
 
        ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
 
@@ -1086,11 +1135,38 @@ A: Open vSwitch 1.9 and earlier support only OpenFlow 1.0 (plus
 
        ovs-ofctl -O OpenFlow13 dump-flows br0
 
 
        ovs-ofctl -O OpenFlow13 dump-flows br0
 
-   Support for OpenFlow 1.1, 1.2, and 1.3 is still incomplete.  Work
-   to be done is tracked in OPENFLOW-1.1+ in the Open vSwitch sources
-   (also via http://openvswitch.org/development/openflow-1-x-plan/).
-   When support for a given OpenFlow version is solidly implemented,
-   Open vSwitch will enable that version by default.
+   OpenFlow 1.4 is a special case, because it is not implemented
+   safely: ovs-vswitchd will abort when certain unimplemented features
+   are tested.  Thus, for now it is suitable only for experimental
+   use.  ovs-vswitchd will only allow OpenFlow 1.4 to be enabled
+   (which must be done in the same way described above) when it is
+   invoked with a special --enable-of14 command line option.
+
+   OPENFLOW-1.1+ in the Open vSwitch source tree tracks support for
+   OpenFlow 1.1 and later features.  When support for a given OpenFlow
+   version is solidly implemented, Open vSwitch will enable that
+   version by default.
+
+Q: Does Open vSwitch support MPLS?
+
+A: Before version 1.11, Open vSwitch did not support MPLS.  That is,
+   these versions can match on MPLS Ethernet types, but they cannot
+   match, push, or pop MPLS labels, nor can they look past MPLS labels
+   into the encapsulated packet.
+
+   Open vSwitch versions 1.11, 2.0, and 2.1 have very minimal support
+   for MPLS.  With the userspace datapath only, these versions can
+   match, push, or pop a single MPLS label, but they still cannot look
+   past MPLS labels (even after popping them) into the encapsulated
+   packet.  Kernel datapath support is unchanged from earlier
+   versions.
+
+   Open vSwitch version 2.2 will be able to match, push, or pop up to
+   3 MPLS labels.  Looking past MPLS labels into the encapsulated
+   packet will still be unsupported.  Both userspace and kernel
+   datapaths will be supported, but MPLS processing always happens in
+   userspace either way, so kernel datapath performance will be
+   disappointing.
 
 Q: I'm getting "error type 45250 code 0".  What's that?
 
 
 Q: I'm getting "error type 45250 code 0".  What's that?
 
@@ -1363,9 +1439,9 @@ A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
    even be convenient, e.g. it is often the desired behavior in a flow
    that forwards a packet to several ports ("floods" the packet).
 
    even be convenient, e.g. it is often the desired behavior in a flow
    that forwards a packet to several ports ("floods" the packet).
 
-   Sometimes one really needs to send a packet out its ingress port.
-   In this case, output to OFPP_IN_PORT, which in ovs-ofctl syntax is
-   expressed as just "in_port", e.g.:
+   Sometimes one really needs to send a packet out its ingress port
+   ("hairpin"). In this case, output to OFPP_IN_PORT, which in
+   ovs-ofctl syntax is expressed as just "in_port", e.g.:
 
        ovs-ofctl add-flow br0 in_port=2,actions=in_port
 
 
        ovs-ofctl add-flow br0 in_port=2,actions=in_port
 
@@ -1435,6 +1511,23 @@ A: These flows drop the ARP packets that IP hosts use to establish IP
       priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2
       priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1
 
       priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2
       priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1
 
+
+Development
+-----------
+
+Q: How do I implement a new OpenFlow message?
+
+A: Add your new message to "enum ofpraw" and "enum ofptype" in
+   lib/ofp-msgs.h, following the existing pattern.  Then recompile and
+   fix all of the new warnings, implementing new functionality for the
+   new message as needed.  (If you configure with --enable-Werror, as
+   described in INSTALL, then it is impossible to miss any warnings.)
+
+   If you need to add an OpenFlow vendor extension message for a
+   vendor that doesn't yet have any extension messages, then you will
+   also need to edit build-aux/extract-ofp-msgs.
+
+
 Contact 
 -------
 
 Contact 
 -------
 
sliver-openvswitch