Am 19.05.2016 um 22:47 schrieb pravin shelar:
On Wed, May 18, 2016 at 9:41 AM, Jan Scheurich <jan.scheur...@web.de> wrote:
I agree current tunneling port check is bit arbitrary. It was designed
to handle most common tunneling setup. But I do not think we can allow
tunneling on any type of port. For example I doubt that it will work
on a tap port. It should be limited to subset of ports.
The intention of the patch is to support tunnelling only over ports
defined with type="internal" in OVSDB. By experiment I found that this
maps to netdev type "tap" in ovs-vswitchd. The LOCAL port of each bridge
belongs to that class.
It is my somewhat limited understanding of OVS that "internal" ports are
realized as Linux tap interfaces. So they can be given IP addresses and
and associated with static routes using normal Linux iproute2 commands.
It is therefore possible to inject traffic through such ports into an
OVS bridges from the hosting Linux network namespace. I have actually
tested that with my patch tunnelling over internal ports (tap netdevs)
does work.
Normal Linux interfaces, including tap interfaces created by other
processes (such as Qemu), are not of netdev type "tap" but "system".
These (and all others) are still excluded by the patch. If IP addresses
and/or routing on the Linux host are set up such that a remote tunnel
endpoint is reachable over a "system" netdev, outgoing tunnel packets
will still be dropped or misrouted.
In the ingress direction there is no check on the port type left in the
patch. That means in the slow path each packet output to a (non-tunnel)
port will be subject to a tunnel lookup. Don't know if this overhead is
acceptable, or if the lookup can be made more selective based on the
port data stored e.g. in xport.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
