Description of problem: openvswitch upstream (not in the kernel) implements port based tunneling, and the ovs userspace commands utilize this port based tunneling directly. port based tunneling from openvswitch will likely not make it into the core kernel. Instead, the kernel implements flow based tunneling (outside of the openvswitch kmod). There are two main requirements: * Quantum openvswitch plugin needs to be able to use tunneling * Other 3rd party plugins that rely on openvswitch need to be able to use tunneling Since port based tunneling will not be in RHEL (or RHOS), this means that we can either: * Fix every Quantum plugin that relies on openvswitch (individually) to use direct calls to the ip binary to create flow based tunnels or * Fix openvswitch userspace a single time to have it create flow based tunnels As a short term hack, it would certainly be possible to just fix the quantum openvswitch plugin, but that would leave all 3rd party plugin vendors with the same problem and needing to implement this as well So the best solution would be for us to fix openvswitch userspace to utilize flow based tunneling directly This bug, therefore, becomes a blocker for RHOS Networking to be able to utilize tunneling for Quantum networks
Support for in-tree tunneling implementation is being merged into upstream kernels and support for these changes on the user space side is likely to land in the OVS 1.12 release if not the 1.11 release. Rebasing to the release will enable the Quantum plugin to use tunneling in RHEL based kernels through both OpenFlow and the ovs-vsctl add-port CLI interface.
Thomas, will the OVS user space version that supports tunneling (as used by quantum-openvswitch-agent) also require a new kernel with corresponding OVS changes?
(In reply to Bob Kukura from comment #3) > Thomas, will the OVS user space version that supports tunneling (as used by > quantum-openvswitch-agent) also require a new kernel with corresponding OVS > changes? Yes, it will require an update to the tunneling implementation and the addition of a new port type for tunnels. This is being tracked in BZ976810
We have verified that the current 1.11 git branch out of which the 1.11 release will be based on is sufficient to support GRE tunneling from a user space POV.
GRE was tested according to test plan - seems ok
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html