Merge branch 'mainstream'

[sliver-openvswitch.git] / FAQ

diff --git a/FAQ b/FAQ
index a0eb1cd..5744d5a 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -27,7 +27,7 @@ A: Open vSwitch is a production quality open source software switch
 Q: What virtualization platforms can use Open vSwitch?
 
 A: Open vSwitch can currently run on any Linux-based virtualization
 Q: What virtualization platforms can use Open vSwitch?
 
 A: Open vSwitch can currently run on any Linux-based virtualization

-   platform (kernel 2.6.18 and newer), including: KVM, VirtualBox, Xen,
+   platform (kernel 2.6.32 and newer), including: KVM, VirtualBox, Xen,

    Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the
    mainline kernel.  The bulk of the code is written in platform-
    independent C and is easily ported to other environments.  We welcome
    Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the
    mainline kernel.  The bulk of the code is written in platform-
    independent C and is easily ported to other environments.  We welcome


@@ -148,13 +148,13 @@ A: The following table lists the Linux kernel versions against which the
        1.9.x      2.6.18 to 3.8
        1.10.x     2.6.18 to 3.8
        1.11.x     2.6.18 to 3.8
        1.9.x      2.6.18 to 3.8
        1.10.x     2.6.18 to 3.8
        1.11.x     2.6.18 to 3.8

-       1.12.x     2.6.18 to 3.10
+       2.0.x      2.6.32 to 3.10

 
    Open vSwitch userspace should also work with the Linux kernel module
    built into Linux 3.3 and later.
 
    Open vSwitch userspace is not sensitive to the Linux kernel version.
 
    Open vSwitch userspace should also work with the Linux kernel module
    built into Linux 3.3 and later.
 
    Open vSwitch userspace is not sensitive to the Linux kernel version.

-   It should build against almost any kernel, certainly against 2.6.18
+   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?
    and later.
 
 Q: What Linux kernel versions does IPFIX flow monitoring work with?


@@ -1249,6 +1249,56 @@ A: An empty set of actions causes a packet to be dropped.  You can
 
        ovs-ofctl add-flow br0 priority=65535,actions=drop
 
 
        ovs-ofctl add-flow br0 priority=65535,actions=drop
 

+Q: I added a flow to send packets out the ingress port, like this:
+
+       ovs-ofctl add-flow br0 in_port=2,actions=2
+
+   but OVS drops the packets instead.
+
+A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
+   out its ingress port.  The rationale is that dropping these packets
+   makes it harder to loop the network.  Sometimes this behavior can
+   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.:
+
+       ovs-ofctl add-flow br0 in_port=2,actions=in_port
+
+   This also works in some circumstances where the flow doesn't match
+   on the input port.  For example, if you know that your switch has
+   five ports numbered 2 through 6, then the following will send every
+   received packet out every port, even its ingress port:
+
+       ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port
+
+   or, equivalently:
+
+       ovs-ofctl add-flow br0 actions=all,in_port
+
+   Sometimes, in complicated flow tables with multiple levels of
+   "resubmit" actions, a flow needs to output to a particular port
+   that may or may not be the ingress port.  It's difficult to take
+   advantage of OFPP_IN_PORT in this situation.  To help, Open vSwitch
+   provides, as an OpenFlow extension, the ability to modify the
+   in_port field.  Whatever value is currently in the in_port field is
+   the port to which outputs will be dropped, as well as the
+   destination for OFPP_IN_PORT.  This means that the following will
+   reliably output to port 2 or to ports 2 through 6, respectively:
+
+       ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT[],2
+       ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT[],2,3,4,5,6
+
+   If the input port is important, then one may save and restore it on
+   the stack:
+
+        ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\
+                                       load:0->NXM_OF_IN_PORT[],\
+                                       2,3,4,5,6,\
+                                       pop:NXM_OF_IN_PORT[]
+

 
 Contact 
 -------
 
 Contact 
 -------