[ovs-discuss] Question on userspace ovs

[OVS]

Thanks Ben,

Digging further into code, i could find out that if bridge type is given as netdev, it creates br0 (say bridge name) and ovs-net (backer if) as TAP interfaces. And rest of nics (eth0 etc) will be opening PF_PACKET socket for receiving the packet.
I could see code for internal devices that you mentioned in last reply and that explains initial questions set. (Thanks for prompt reply).

I have one more query where need help, why ovs-net and br0, 2 TAP interfaces are created and where are they used for? I am looking right now for netdev type of bridge. My initial understanding was, any local PUNT of packet (e.g. L4 packet need to be sent to local applications) will go through local interface of bridge which is TAP interface. And by virtue of that, it will follow kernel stack for further processing. But i could not understand ovs-net role? Can you please brief on this?

For netdev type of bridge, i guess netlink is not used, because i don’t see any kernel configuration needed for this case. Is my understanding correct?

Thanks..
Wanted to keep name as OVS user, looks like user is missing :)



> On Jun 1, 2015, at 11:03 AM, Ben Pfaff <blp at nicira.com> wrote:
> 
> Wow, what a coincidence, someone named OVS using OVS.  Who would have
> thought!!1!
> 
> On Mon, Jun 01, 2015 at 09:54:55AM +0530, OVS wrote:
>> I am new to OVS and was going through code to understand the flow.  I
>> was looking at userspace ovs handling where no kernel module specific
>> to OVS is needed.  I understand that Bridge functionality is handled
>> using TAP interface in this scenario.
> 
> TAP interfaces are used to implement "internal" devices.
> 
>> 1. First question, will other interfaces like eth0, eth1 etc will have
>> corresponding link through TAP devices?
> 
> No.
> 
>> Ideally i think it should be TAP as we want to process the packet in
>> userspace.
> 
> I don't follow.
> 
>> 2. Second question, if everything is handled in user space, what would
>> netlink used for?
> 
> It's only used internally within the OVS process.  Also a lot of Linux
> networking (not just OVS) works through Netlink in any case, so Netlink
> is used to talk to the network stack in those cases.
> 
> You might find some enlightenment in this FAQ entry, especially in the
> last few paragraphs.
> 
> ### Q: I created a tap device tap0, configured an IP address on it, and
>    added it to a bridge, like this:
> 
>        tunctl -t tap0
> 	ifconfig tap0 192.168.0.123
> 	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
>       ifconfig int0 192.168.0.123
> 
>   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
>       ifconfig br0 192.168.0.123
> 
>   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).