It should build against almost any kernel, certainly against 2.6.18
and 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 possbility of incompatibilities.
+
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
- the following features:
-
- - Tunnel virtual ports, that is, interfaces with type "gre",
- "ipsec_gre", "capwap". 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 these features 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 distribution instead of the upstream Linux kernel
- module.
-
- - Patch virtual ports, that is, interfaces with type "patch".
- You can use Linux "veth" devices as a substitute.
-
- We don't have any plans to add patch ports upstream.
+ tunnel virtual ports, that is, interfaces with type "gre",
+ "ipsec_gre", "gre64", "ipsec_gre64", "vxlan", or "capwap". 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
+ 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.
Q: What features are not available when using the userspace datapath?
-A: Tunnel and patch virtual ports are not supported, as described in the
+A: Tunnel virtual ports are not supported, as described in the
previous answer. It is also not possible to use queue-related
actions. On Linux kernels before 2.6.39, maximum-sized VLAN packets
may not be transmitted.
alternative, Open vSwitch supports mirroring to a GRE tunnel (see
above).
+Q: Why are there so many different ways to dump flows?
+
+A: Open vSwitch uses different kinds of flows for different purposes:
+
+ - OpenFlow flows are the most important kind of flow. OpenFlow
+ controllers use these flows to define a switch's policy.
+ OpenFlow flows support wildcards, priorities, and multiple
+ tables.
+
+ When in-band control is in use, Open vSwitch sets up a few
+ "hidden" flows, with priority higher than a controller or the
+ user can configure, that are not visible via OpenFlow. (See
+ the "Controller" section of the FAQ for more information
+ 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
+ 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.
+
+ Each of the commands for dumping flows has a different purpose:
+
+ - "ovs-ofctl dump-flows <br>" dumps OpenFlow flows, excluding
+ hidden flows. This is the most commonly useful form of flow
+ dump. (Unlike the other commands, this should work with any
+ OpenFlow switch, not just Open vSwitch.)
+
+ - "ovs-appctl bridge/dump-flows <br>" dumps OpenFlow flows,
+ 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
+ entries for a Linux kernel-based datapath. In Open vSwitch
+ 1.10 and later, ovs-vswitchd later merges multiple switches
+ into a single datapath, so it will show all the flows on all
+ your kernel-based switches. This command can occasionally be
+ 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.
+
Configuration Problems
----------------------
point, so the same problems will show up with the Linux bridge or
any other way to do bridging.
+Q: I can't seem to add my PPP interface to an Open vSwitch bridge.
+
+A: PPP most commonly carries IP packets, but Open vSwitch works only
+ with Ethernet frames. The correct way to interface PPP to an
+ Ethernet network is usually to use routing instead of switching.
+
Q: Is there any documentation on the database tables and fields?
A: Yes. ovs-vswitchd.conf.db(5) is a comprehensive reference.
controller is not configured, this happens implicitly to
every packet.)
- - The "autopath" Nicira extension action. However, "autopath"
- is deprecated and scheduled for removal in February 2013.
-
- Mirrors configured for output to a bonded port.
It would make a lot of sense for Open vSwitch to present a bond as
git://git.onelab.eu / sliver-openvswitch.git / blobdiff