[ovs-discuss] tap ports...

[Ben Pfaff]

On Mon, Mar 05, 2018 at 10:31:30PM -0700, Grant Taylor via discuss wrote:
> Can OVS create tap ports like OpenVPN or KVM (Qemu) or User Mode Linux use?
> I.e. an Ethernet interface inside OVS and a socket that applications can
> glom onto and use.
> 
> I think I can create the tap interfaces manually (via tunctl or ip tuntap…)
> and then add them to a bridge.  However I feel like this is unnecessary and
> may very well be something that OVS can do without the separate devices.
> 
> Hence my question if OVS can create (internal) tap interfaces, much the same
> way that it can create (internal) vEth (like) interfaces.

Q: I created a tap device tap0, configured an IP address on it, and added it to
a bridge, like this::

    $ tunctl -t tap0
    $ ip addr add 192.168.0.123/24 dev tap0
    $ ip link set tap0 up
    $ ovs-vsctl add-br br0
    $ ovs-vsctl add-port br0 tap0

I expected that I could then use this IP address to contact other hosts on the
network, but it doesn't work.  Why not?

    A: The short answer is that this is a misuse of a "tap" device.  Use an
    "internal" device implemented by Open vSwitch, which works differently and
    is designed for this use.  To solve this problem with an internal device,
    instead run::

        $ ovs-vsctl add-br br0
        $ ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal
	$ ip addr add 192.168.0.123/24 dev int0
        $ ip link set int0 up

    Even more simply, you can take advantage of the internal port that every
    bridge has under the name of the bridge::

        $ ovs-vsctl add-br br0
	$ ip addr add 192.168.0.123/24 dev br0
        $ ip link set br0 up

    In more detail, a "tap" device is an interface between the Linux (or BSD)
    network stack and a user program that opens it as a socket.  When the "tap"
    device transmits a packet, it appears in the socket opened by the userspace
    program.  Conversely, when the userspace program writes to the "tap"
    socket, the kernel TCP/IP stack processes the packet as if it had been
    received by the "tap" device.

    Consider the configuration above.  Given this configuration, if you "ping"
    an IP address in the 192.168.0.x subnet, the Linux kernel routing stack
    will transmit an ARP on the tap0 device.  Open vSwitch userspace treats
    "tap" devices just like any other network device; that is, it doesn't open
    them as "tap" sockets.  That means that the ARP packet will simply get
    dropped.

    You might wonder why the Open vSwitch kernel module doesn't intercept the
    ARP packet and bridge it.  After all, Open vSwitch intercepts packets on
    other devices.  The answer is that Open vSwitch only intercepts *received*
    packets, but this is a packet being transmitted.  The same thing happens
    for all other types of network devices, except for Open vSwitch "internal"
    ports.  If you, for example, add a physical Ethernet port to an OVS bridge,
    configure an IP address on a physical Ethernet port, and then issue a
    "ping" to an address in that subnet, the same thing happens: an ARP gets
    transmitted on the physical Ethernet port and Open vSwitch never sees it.
    (You should not do that, as documented at the beginning of this section.)

    It can make sense to add a "tap" device to an Open vSwitch bridge, if some
    userspace program (other than Open vSwitch) has opened the tap socket.
    This is the case, for example, if the "tap" device was created by KVM (or
    QEMU) to simulate a virtual NIC.  In such a case, when OVS bridges a packet
    to the "tap" device, the kernel forwards that packet to KVM in userspace,
    which passes it along to the VM, and in the other direction, when the VM
    sends a packet, KVM writes it to the "tap" socket, which causes OVS to
    receive it and bridge it to the other OVS ports.  Please note that in such
    a case no IP address is configured on the "tap" device (there is normally
    an IP address configured in the virtual NIC inside the VM, but this is not
    visible to the host Linux kernel or to Open vSwitch).

    There is one special case in which Open vSwitch does directly read and
    write "tap" sockets.  This is an implementation detail of the Open vSwitch
    userspace switch, which implements its "internal" ports as Linux (or BSD)
    "tap" sockets.  In such a userspace switch, OVS receives packets sent on
    the "tap" device used to implement an "internal" port by reading the
    associated "tap" socket, and bridges them to the rest of the switch.  In
    the other direction, OVS transmits packets bridged to the "internal" port
    by writing them to the "tap" socket, causing them to be processed by the
    kernel TCP/IP stack as if they had been received on the "tap" device.
    Users should not need to be concerned with this implementation detail.

    Open vSwitch has a network device type called "tap".  This is intended only
    for implementing "internal" ports in the OVS userspace switch and should
    not be used otherwise.  In particular, users should not configure KVM "tap"
    devices as type "tap" (use type "system", the default, instead).