fixed coding style
[sliver-openvswitch.git] / FAQ
diff --git a/FAQ b/FAQ
index 20a3e3b..2912ae3 100644 (file)
--- a/FAQ
+++ b/FAQ
@@ -89,10 +89,9 @@ A: Distributed vswitch applications (e.g., VMware vNetwork distributed
    environments: OpenFlow, which exposes flow-based forwarding state,
    and the OVSDB management protocol, which exposes switch port state.
    In addition to the switch implementation itself, Open vSwitch
-   includes tools (ovs-controller, ovs-ofctl, ovs-vsctl) that developers
-   can script and extend to provide distributed vswitch capabilities
-   that are closely integrated with their virtualization management
-   platform.
+   includes tools (ovs-ofctl, ovs-vsctl) that developers can script and
+   extend to provide distributed vswitch capabilities that are closely
+   integrated with their virtualization management platform.
 
 Q: Why doesn't Open vSwitch support distribution?
 
@@ -148,7 +147,8 @@ 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
-       2.x        2.6.32 to 3.10
+       2.0.x      2.6.32 to 3.10
+       2.1.x      2.6.32 to 3.11
 
    Open vSwitch userspace should also work with the Linux kernel module
    built into Linux 3.3 and later.
@@ -168,7 +168,7 @@ Q: Should userspace or kernel be upgraded first to minimize downtime?
    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 possbility of incompatibilities.
+   the possibility of incompatibilities.
 
 Q: What features are not available in the Open vSwitch kernel datapath
    that ships as part of the upstream Linux kernel?
@@ -197,6 +197,25 @@ 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.
 
+Q: What happened to the bridge compatibility feature?
+
+A: Bridge compatibility was a feature of Open vSwitch 1.9 and earlier.
+   When it was enabled, Open vSwitch imitated the interface of the
+   Linux kernel "bridge" module.  This allowed users to drop Open
+   vSwitch into environments designed to use the Linux kernel bridge
+   module without adapting the environment to use Open vSwitch.
+
+   Open vSwitch 1.10 and later do not support bridge compatibility.
+   The feature was dropped because version 1.10 adopted a new internal
+   architecture that made bridge compatibility difficult to maintain.
+   Now that many environments use OVS directly, it would be rarely
+   useful in any case.
+
+   To use bridge compatibility, install OVS 1.9 or earlier, including
+   the accompanying kernel modules (both the main and bridge
+   compatibility modules), following the instructions that come with
+   the release.  Be sure to start the ovs-brcompatd daemon.
+
 
 Terminology
 -----------
@@ -399,7 +418,11 @@ A: First, why do you want to do this?  Two connected bridges are not
    ports will not work with the userspace datapath, only with the
    kernel module.
 
-Q: Why are there so many different ways to dump flows?
+
+Implementation Details
+----------------------
+
+Q: I hear OVS has a couple of kinds of flows.  Can you tell me about them?
 
 A: Open vSwitch uses different kinds of flows for different purposes:
 
@@ -415,18 +438,27 @@ A: Open vSwitch uses different kinds of flows for different purposes:
         about hidden flows.)
 
       - The Open vSwitch software switch implementation uses a second
-        kind of flow internally.  These flows, called "exact-match"
-        or "datapath" or "kernel" flows, do not support wildcards or
-        priorities and comprise only a single table, which makes them
-        suitable for caching.   OpenFlow flows and exact-match flows
+        kind of flow internally.  These flows, called "datapath" or
+        "kernel" flows, do not support priorities and comprise only a
+        single table, which makes them suitable for caching.  (Like
+        OpenFlow flows, datapath flows do support wildcarding, in Open
+        vSwitch 1.11 and later.)  OpenFlow flows and datapath flows
         also support different actions and number ports differently.
 
-        Exact-match flows are an implementation detail that is
-        subject to change in future versions of Open vSwitch.  Even
-        with the current version of Open vSwitch, hardware switch
-        implementations do not necessarily use exact-match flows.
+        Datapath flows are an implementation detail that is subject to
+        change in future versions of Open vSwitch.  Even with the
+        current version of Open vSwitch, hardware switch
+        implementations do not necessarily use this architecture.
+
+   Users and controllers directly control only the OpenFlow flow
+   table.  Open vSwitch manages the datapath flow table itself, so
+   users should not normally be concerned with it.
+
+Q: Why are there so many different ways to dump flows?
 
-  Each of the commands for dumping flows has a different purpose:
+A: Open vSwitch has two kinds of flows (see the previous question), so
+   it has commands with different purposes for dumping each kind of
+   flow:
 
       - "ovs-ofctl dump-flows <br>" dumps OpenFlow flows, excluding
         hidden flows.  This is the most commonly useful form of flow
@@ -437,7 +469,7 @@ A: Open vSwitch uses different kinds of flows for different purposes:
         including hidden flows.  This is occasionally useful for
         troubleshooting suspected issues with in-band control.
 
-      - "ovs-dpctl dump-flows [dp]" dumps the exact-match flow table
+      - "ovs-dpctl dump-flows [dp]" dumps the datapath flow table
         entries for a Linux kernel-based datapath.  In Open vSwitch
         1.10 and later, ovs-vswitchd merges multiple switches into a
         single datapath, so it will show all the flows on all your
@@ -445,8 +477,29 @@ A: Open vSwitch uses different kinds of flows for different purposes:
         useful for debugging.
 
       - "ovs-appctl dpif/dump-flows <br>", new in Open vSwitch 1.10,
-        dumps exact-match flows for only the specified bridge,
-        regardless of the type.
+        dumps datapath flows for only the specified bridge, regardless
+        of the type.
+
+
+Performance
+-----------
+
+Q: I just upgraded and I see a performance drop.  Why?
+
+A: The OVS kernel datapath may have been updated to a newer version than
+   the OVS userspace components.  Sometimes new versions of OVS kernel
+   module add functionality that is backwards compatible with older
+   userspace components but may cause a drop in performance with them.
+   Especially, if a kernel module from OVS 2.1 or newer is paired with
+   OVS userspace 1.10 or older, there will be a performance drop for
+   TCP traffic.
+
+   Updating the OVS userspace components to the latest released
+   version should fix the performance degradation.
+
+   To get the best possible performance and functionality, it is
+   recommended to pair the same versions of the kernel module and OVS
+   userspace.
 
 
 Configuration Problems
@@ -1235,9 +1288,11 @@ A: To debug network behavior problems, trace the path of a packet,
 
 Q: How do I make a flow drop packets?
 
-A: An empty set of actions causes a packet to be dropped.  You can
-   specify an empty set of actions with "actions=" on the ovs-ofctl
-   command line.  For example:
+A: To drop a packet is to receive it without forwarding it.  OpenFlow
+   explicitly specifies forwarding actions.  Thus, a flow with an
+   empty set of actions does not forward packets anywhere, causing
+   them to be dropped.  You can specify an empty set of actions with
+   "actions=" on the ovs-ofctl command line.  For example:
 
        ovs-ofctl add-flow br0 priority=65535,actions=
 
@@ -1249,6 +1304,9 @@ A: An empty set of actions causes a packet to be dropped.  You can
 
        ovs-ofctl add-flow br0 priority=65535,actions=drop
 
+   "drop" is not an action, either in OpenFlow or Open vSwitch.
+   Rather, it is only a way to say that there are no actions.
+
 Q: I added a flow to send packets out the ingress port, like this:
 
        ovs-ofctl add-flow br0 in_port=2,actions=2
@@ -1299,6 +1357,39 @@ A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
                                        2,3,4,5,6,\
                                        pop:NXM_OF_IN_PORT[]
 
+Q: My bridge br0 has host 192.168.0.1 on port 1 and host 192.168.0.2
+   on port 2.  I set up flows to forward only traffic destined to the
+   other host and drop other traffic, like this:
+
+      priority=5,in_port=1,ip,nw_dst=192.168.0.2,actions=2
+      priority=5,in_port=2,ip,nw_dst=192.168.0.1,actions=1
+      priority=0,actions=drop
+
+   But it doesn't work--I don't get any connectivity when I do this.
+   Why?
+
+A: These flows drop the ARP packets that IP hosts use to establish IP
+   connectivity over Ethernet.  To solve the problem, add flows to
+   allow ARP to pass between the hosts:
+
+      priority=5,in_port=1,arp,actions=2
+      priority=5,in_port=2,arp,actions=1
+
+   This issue can manifest other ways, too.  The following flows that
+   match on Ethernet addresses instead of IP addresses will also drop
+   ARP packets, because ARP requests are broadcast instead of being
+   directed to a specific host:
+
+      priority=5,in_port=1,dl_dst=54:00:00:00:00:02,actions=2
+      priority=5,in_port=2,dl_dst=54:00:00:00:00:01,actions=1
+      priority=0,actions=drop
+
+   The solution already described above will also work in this case.
+   It may be better to add flows to allow all multicast and broadcast
+   traffic:
+
+      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
 
 Contact 
 -------