[ovs-dev] [PATCH] ofproto-dpif: User-space tunnels over non-LOCAL ports

[pravin shelar]

On Thu, May 19, 2016 at 3:24 PM, Jan Scheurich <jan.scheurich at web.de> wrote:
> Am 19.05.2016 um 22:47 schrieb pravin shelar:
>>
>> On Wed, May 18, 2016 at 9:41 AM, Jan Scheurich <jan.scheurich at 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.
>
When I said tap interfaces would not work I was thinking of kernel
datapath, But for userpsace datapath it should be fine.

> 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.
>
ok.

> 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.
The tunnel port type check should be done here on ingress to avoid
unnecessary lookup. with this type check we can better filter packets
received on tunnel port.