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
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?
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
+ 2.1.x 2.6.32 to 3.11
+ 2.2.x 2.6.32 to 3.14
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?
+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 possbility 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?
-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.
- 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?
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.
+ 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
-----------
ovs-vsctl add-port br0 tap0
ovs-vsctl add-port br0 tap1 \
-- --id=@p get port tap1 \
- -- --id=@m create mirror name=m0 select-all=true output-port=@p \
- -- set bridge br0 mirrors=@m
+ -- --id=@m create mirror name=m0 select-all=true output-port=@p \
+ -- set bridge br0 mirrors=@m
To later disable mirroring, run:
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 tap0 tag=10
ovs-vsctl \
- -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \
+ -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \
output-vlan=15 \
- -- set bridge br0 mirrors=@m
+ -- set bridge br0 mirrors=@m
To later disable mirroring, run:
ovs-vsctl add-port br0 gre0 \
-- set interface gre0 type=gre options:remote_ip=192.168.1.10 \
-- --id=@p get port gre0 \
- -- --id=@m create mirror name=m0 select-all=true output-port=@p \
- -- set bridge br0 mirrors=@m
+ -- --id=@m create mirror name=m0 select-all=true output-port=@p \
+ -- set bridge br0 mirrors=@m
To later disable mirroring and destroy the GRE tunnel:
ports will not work with the userspace datapath, only with the
kernel module.
-Q: Why are there so many different ways to dump flows?
+Q: How do I configure a bridge without an OpenFlow local port?
+ (Local port in the sense of OFPP_LOCAL)
+
+A: Open vSwitch does not support such a configuration.
+ Bridges always have their local ports.
+
+
+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:
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
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
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
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.
+
+Q: Open vSwitch does not seem to obey my packet filter rules.
+
+A: It depends on mechanisms and configurations you want to use.
+
+ You cannot usefully use typical packet filters, like iptables, on
+ physical Ethernet ports that you add to an Open vSwitch bridge.
+ This is because Open vSwitch captures packets from the interface at
+ a layer lower below where typical packet-filter implementations
+ install their hooks. (This actually applies to any interface of
+ type "system" that you might add to an Open vSwitch bridge.)
+
+ You can usefully use typical packet filters on Open vSwitch
+ internal ports as they are mostly ordinary interfaces from the point
+ of view of packet filters.
+
+ For example, suppose you create a bridge br0 and add Ethernet port
+ eth0 to it. Then you can usefully add iptables rules to affect the
+ internal interface br0, but not the physical interface eth0. (br0
+ is also where you would add an IP address, as discussed elsewhere
+ in the FAQ.)
+
+ For simple filtering rules, it might be possible to achieve similar
+ results by installing appropriate OpenFlow flows instead.
+
+ If the use of a particular packet filter setup is essential, Open
+ vSwitch might not be the best choice for you. On Linux, you might
+ want to consider using the Linux Bridge. (This is the only choice if
+ you want to use ebtables rules.) On NetBSD, you might want to
+ consider using the bridge(4) with BRIDGE_IPF option.
+
Quality of Service (QoS)
------------------------
ovs-vsctl -- \
add-br br0 -- \
- add-port br0 eth0 -- \
- add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
- add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
- set port eth0 qos=@newqos -- \
- --id=@newqos create qos type=linux-htb \
+ add-port br0 eth0 -- \
+ add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \
+ add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \
+ set port eth0 qos=@newqos -- \
+ --id=@newqos create qos type=linux-htb \
other-config:max-rate=1000000000 \
- queues:123=@vif10queue \
- queues:234=@vif20queue -- \
+ queues:123=@vif10queue \
+ queues:234=@vif20queue -- \
--id=@vif10queue create queue other-config:max-rate=10000000 -- \
--id=@vif20queue create queue other-config:max-rate=20000000
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.
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
-----
ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal
ifconfig vlan9 192.168.0.7
+ See also the following question.
+
+Q: I configured one IP address on VLAN 0 and another on VLAN 9, like
+ this:
+
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 eth0
+ ifconfig br0 192.168.0.5
+ ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal
+ ifconfig vlan9 192.168.0.9
+
+ but other hosts that are only on VLAN 0 can reach the IP address
+ configured on VLAN 9. What's going on?
+
+A: RFC 1122 section 3.3.4.2 "Multihoming Requirements" describes two
+ approaches to IP address handling in Internet hosts:
+
+ - In the "Strong ES Model", where an ES is a host ("End
+ System"), an IP address is primarily associated with a
+ particular interface. The host discards packets that arrive
+ on interface A if they are destined for an IP address that is
+ configured on interface B. The host never sends packets from
+ interface A using a source address configured on interface B.
+
+ - In the "Weak ES Model", an IP address is primarily associated
+ with a host. The host accepts packets that arrive on any
+ interface if they are destined for any of the host's IP
+ addresses, even if the address is configured on some
+ interface other than the one on which it arrived. The host
+ does not restrict itself to sending packets from an IP
+ address associated with the originating interface.
+
+ Linux uses the weak ES model. That means that when packets
+ destined to the VLAN 9 IP address arrive on eth0 and are bridged to
+ br0, the kernel IP stack accepts them there for the VLAN 9 IP
+ address, even though they were not received on vlan9, the network
+ device for vlan9.
+
+ To simulate the strong ES model on Linux, one may add iptables rule
+ to filter packets based on source and destination address and
+ adjust ARP configuration with sysctls.
+
+ BSD uses the strong ES model.
+
Q: My OpenFlow controller doesn't see the VLANs that I expect.
A: The configuration for VLANs in the Open vSwitch database (e.g. via
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 OF1.5
+ =============== ===== ===== ===== ===== ===== =====
+ 1.9 and earlier yes --- --- --- --- ---
+ 1.10 yes --- [*] [*] --- ---
+ 1.11 yes --- [*] [*] --- ---
+ 2.0 yes [*] [*] [*] --- ---
+ 2.1 yes [*] [*] [*] --- ---
+ 2.2 yes [*] [*] [*] [%] [*]
+ 2.3 yes yes yes yes [*] [*]
- ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow12,OpenFlow13
+ [*] Supported, with one or more missing features.
+ [%] Experimental, unsafe implementation.
- 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:
+ Open vSwitch 2.3 enables OpenFlow 1.0, 1.1, 1.2, and 1.3 by default
+ in ovs-vswitchd. In Open vSwitch 1.10 through 2.2, OpenFlow 1.1,
+ 1.2, and 1.3 must be enabled manually in ovs-vswitchd. OpenFlow
+ 1.4 and 1.5 are also supported, with missing features, in Open
+ vSwitch 2.3 and later, but not enabled by default. In any case,
+ the user may override the default:
- ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
+ - To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0:
- Use the -O option to enable support for later versions of OpenFlow
- in ovs-ofctl. For example:
+ ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13
+
+ - To enable OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 on bridge br0:
+
+ ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15
+
+ - To enable only OpenFlow 1.0 on bridge br0:
+
+ ovs-vsctl set bridge br0 protocols=OpenFlow10
+
+ All current versions of ovs-ofctl enable only OpenFlow 1.0 by
+ default. Use the -O option to enable support for later versions of
+ OpenFlow in ovs-ofctl. For example:
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.
+ (Open vSwitch 2.2 had an experimental implementation of OpenFlow
+ 1.4 that could cause crashes. We don't recommend enabling it.)
+
+ OPENFLOW-1.1+ in the Open vSwitch source tree tracks support for
+ OpenFlow 1.1 and later features. When support for OpenFlow 1.4 and
+ 1.5 is solidly implemented, Open vSwitch will enable those version
+ by default. Also, the OpenFlow 1.5 specification is still under
+ development and thus subject to change.
+
+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: 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=
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
+
+ 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
+ ("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
+
+ 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[]
+
+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
+
+
+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
-------