[ovs-discuss] tap ports...

Grant Taylor gtaylor at tnetconsulting.net
Wed Mar 7 21:19:07 UTC 2018

On 03/07/2018 12:56 PM, Ben Pfaff wrote:
> 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 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?

This does not relate to my question any more than the term collisions of 
"tap" and "OVS".

> 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:

I am quite happily using internal ports for VMs.

Internal ports will not work for thinks like OpenVPN User-Mode Linux.

Both OpenVPN and UML expect to open the unix socket file (descriptor) 
and receive Ethernet frames.  They do not work with a traditional 
network interface, like an OVS "internal" port.

> 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 dev br0
>     $ ip link set br0 up

I agree with the statement, but it has no relation to my question.

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

I'm very well aware of that.  That is the exact behavior that I'm wanting.

> 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.
That is exactly what my understanding of a tap interface is used for.

It's close cousin, the tun interface, behaves quite similar, save for 
the fact that it operates at layer 3 with IP packets between the 
interface and the unix socket.

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

I would expect such transmitted ping (or more likely an associated ARP 
request) to come out the unix socket that a user space program like 
OpenVPN or UML would process.  -  Unrelated to my question.

> Open vSwitch userspace treats "tap" devices just like any other network 
> device; that is, it doesn't open them as "tap" sockets.

That's what I expected.

> That means that the ARP packet will simply get dropped.

I'd think the dropping or not has more to do with what opens the tap's 
associated unix socket and very little to do with OVS.  -  In the case 
you are describing.

> You might wonder why the Open vSwitch kernel module doesn't intercept the 
> ARP packet and bridge it.

Nope, not at all.

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

This is what I would expect.

> (You should not do that, as documented at the beginning of this section.)

IMHO the start of your reply gave an example alternative example, and 
this paragraph confirmed what I expected would be the case.

However, that being said, I have had plenty of times that I have done 
this very thing with Linux kernel native bridges for various reasons. 
Frequently the service IP would live on a bridge and the maintenance IP 
(in a different subnet) lived on the underlying Ethernet interface.  It 
worked perfectly fine.  Granted, I had to be aware of the caveat that 
you outlined.  -  My point being, there are times when it is okay (maybe 
sub-optimal) to put an IP on a member interface instead of the bridge 
device itself.

> 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 EXACT type of scenario that I was asking about.  OpenVPN and 
UML (et al) opening the unix socket with their associated network 
interfaces connected to an OVS bridge.

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

That exactly describes what I want to happen with OpenVPN and UML.

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

I'm going to have to disagree with you.  It really depends if you want 
to switch / bridge traffic from the tap interface and other interfaces 
-or- if you want to route.  The latter case would very likely have an IP 
address on the tap interface so the kernel can do stock routing between 
the tap (and what ever is connected to it's unix socket) and the rest of 
the L3 / IP interfaces the kernel has.

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

It sounds like OVS consumes multiple unix sockets (associated with tap 
interfaces) and bridges the Ethernet frames that come out of said 
sockets.  Thus handling the unix sockets much like OpenVPN and UML do.

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

Now I am curious, what is a real world use case of such an OVS 

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

I had read that OVS's tap interfaces should not be used.  I don't know 
how they differ from the kernel's tap interface, but it may not matter.

All of that being said, you have not (directly) answered my question.

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.

The answer you provided makes it sound like OVS can't create tap ports 
like OpenVPN / UML use.  Your answer also seemed to be answering a 
different question than the one that I asked, almost as if it was copied 
and pasted from elsewhere in the hope that it would answer my question 
since I asked about "tap" interfaces.

Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180307/13fd55f3/attachment-0001.p7s>

More information about the discuss mailing list