Can someone explain in detail what are the differences of veth pairs and tap interfaces and how these devices connect to linux bridge or openvswitch.
I found this:
"Veth is a special net devices which were created in pair, I consider it as a method to change the traffic's direction, that is, when the out direction traffic is sent to veth device from Linux protocol stack, it was sent to another its mirror veth device, so the mirror one treats it as a in direction traffic and put it back to Linux protocol stack for further usage.
Tap device is logical net device but have different with any other one: it allows user space program directly injecting traffic into Linux protocol stack, as well as it can retrieve traffic from the stack. It opens a tunnel to Linux protocol stack at level 2(or tun device at level 3) in user space, the stack will consider data from user space as in direction traffic"
but it didn't gave me the whole picture.
thanks in advance!
Linux tap interfaces created with ip tuntap cannot be used to attach network namespaces to linuxbridges or the openvswitch so we need to depend upon veth pair.
Virtual Ethernet interfaces come in pairs, and they are connected like a tube—whatever comes in one veth interface will come out the other peer veth interface.
As a result, you can use veth interfaces to connect a network namespace to the outside world via the “default” or “global” namespace where physical
interfaces exist.
A TAP device, such as vnet0 is how hypervisors such as KVM and Xen implement a virtual network interface card (typically called a VIF or vNIC).
An Ethernet frame sent to a TAP device is received by the guest operating system.
The purpose of these virtual networking artifacts are similar. But there are subtle differences and hence they are used in different circumstances:
TAP: The user-space application/VM can read or write an ethernet frame to the tap interface and it would reach the host kernel, where it would be handled like any other ethernet frame that reached the kernel via physical (e.g. eth0) ports. You can potentially add it to a software-bridge (e.g. linux-bridge)
VETH: Typically used when you are trying to connect two entities which would want to "get hold of" (for lack of better phrase) an interface to forward/receive frames. These entities could be containers/bridges/ovs-switch etc. Say you want to connect a docker/lxc container to OVS. You can create a veth pair and push the first interface to the docker/lxc (say, as a phys interface) and push the other interface to OVS. You cannot do this with TAP.
Please note that we should not misconstrue that we need to use VETH and not tap when using the OVS. We can always create the internal ports in OVS which behave exactly like the tap interface. But this is not always possible, for instance when you want to connect to an entity that cannot synthesise a tap-like interface. I.e.:
$ ovs-vsctl add-port ovs-switch-name tap0
Now you can use tap0 like we use the tap interfaces.
Related
Two Linux machines (embedded board and PC) are connected to each other via USB cable, and communication is established via USB gadget/Ethernet. Both sides have IP address, ping works, etc.
I need to find a way to detect USB cable disconnect on the board side, ideally with a single Bash command.
ifconfig usb0 still shows IP address and that device is "UP" and "RUNNING" even after unplugging the cable.
In my particular case it turned out to be HW+SW issue: driver (atmel_usba_udc) is using USB power (VBUS) to detect connection, since it's acting as a slave and power is provided by host. However in PCB power is provided unconditionally by the board itself for all USB ports at once.
Normally any standard method should work: ifconfig or sysfs.
One way to do this is to check the file:
/sys/class/net/usb0/operstate
If the file content is "up" then the link exists. If the content is "down", then there is no link.
Can some expert please throw some light on what is knet interface and what is it used for.
One of my container images show knet2 as an interface for output of 'ifconfig'
I have no idea what it is, can someone please explain or point me to documents / web where I can find more about it.
knet is kernel network interface for efficient of packet exchange between switch and the kernel (linux operating system) network protocol stack.
There could be other methods which could used, such as implementing a software connector module over the Open NSL Rx/TX APIs.
The intent of theknet interface is to provide a network interface that
then delivers packets to the NetIO framework from the kernel.
this is nicely explained in user-networking.pdf.
I hope this is what you were expecting. feel free to comment for any clarification.
this is about knet reference
This module implements a Linux network driver for Broadcom
XGS switch devices. The driver simultaneously serves a
number of vitual Linux network devices and a Tx/Rx API
implemented in user space.
Packets received from the switch device are sent to either
a virtual Linux network device or the user mode Rx API
based on a set of packet filters.susp
Packets from the virtual Linux network devices and the user
mode Tx API are multiplexed with priority given to the Tx API
Tun/Tap interface based tunnel
Can someone tell me how such a tunnel is created and works?
I have tried Googling the answer, but there are very few ressources and they are primarily very technical.
I know that packets sent through such an interface gets injected into the OS network stack and look like packets received from an external host. Also, packets received on this interface gets passed to a user-space program.
However, what I do not understand the following:
Why does such a tunnel involve the use of setting up network connections? Is the programs on either side of the tunnel neccessarily running on the same host, or can they be running on different hosts? Does the network stack deliver tap or tun packages through TCP/UDP?
Both Tun and Tap interfaces deliver data from one host to another. The main difference is the features (pros/cons) that you get when you are using Tun or Tap.
Data delivered via Tap interface gets injected at layer2 of OSI stack and data delivered via Tun interface gets injected and layer3. There is no better/worse choice here - each is suited for specific purpose. You can read a very good explanation here.
Now to answer your questions:
Why does such a tunnel involve the use of setting up network connections?
You want to deliver packets from one host to another regardless the interface type (tun/tap). To do so you capture those packets, encapsulate them and then you need to send over encapsulated data to the remote end. To do this you need to set up a network connection.
Is the programs on either side of the tunnel neccessarily running on the same host, or can they be running on different hosts?
You are creating a VPN connection between two different hosts, so yes - there will be software running on both hosts which will handle the encapsulation/decapsulation.
Does the network stack deliver tap or tun packages through TCP/UDP?
TCP/UDP are layer4 protocols, so from point of view of TCP/UDP stack it does not matter at all if the packet came to your host via tun or tap interface.
EDIT: Clarification about the follow up questions:
Since you are asking about Tun/Tap adapters, let's take a step back. When you run a VPN, you have a computer A behaving as if it is directly connected to network N, even though it might be somewhere far away. To make this happen, you run a VPN software. You have to run this VPN software in two places - one in the computer A and another in computer (or network device) connected to the network N. When running a VPN software in the computer A, you have a choice of creating a Tun or Tap adapter.
Q1: Yes - delivered means sent and received.
Q2: Yes - means that VPN connection is like a pipe, and there is VPN software running at both ends.
Q3: When VPN software is running in the computer A, it creates what is called a virtual network adapter. This virtual network adapter, in the eyes of OS, behaves like a normal network adapter. Just instead of sending data over the wire or waves, it caputers the data, encapsulates it and sends over some other adapter in the system.
we have an embedded Linux device that primarily uses the Ethernet to communicate. We also allow access via the USB port, to support this our device has a g_ether Linux gadget driver that creates a virtual ethernet port for both our device and the clients host. A DHCP server assigns the client an IP address saving them having to configure this them selves, while the device has a fix IP address. I believe this is much the same as how Android does its tethering
This all works fine until a client wants to use 2 or more devices at once. Both devices come up as distinct network interfaces on the clients machine, but both devices have the same IP address meaning you cannot target the host specifically! A smaller problem is that there is a slight possibility that both devices might assign the clients "distinct" interface the same ip address and cause a conflict there too, but I am less concerned about that as the IP address is random since the DHCP server assigns the address based on the MAC address and g_ether randomly generates this, so a retry should fix the issue (not ideal, but will do)
I would like to know if anyone else has faced a similar problem, and if so how they solved it ?
We have developed a device that is connected to our clients network and we would like to be able to get its ip or set the ip without knowing its ip.
The device has a Linux OS.
We can save the device MAC Address before giving it to customers. We can program a service to broadcast the device IP and MAC Address to a certain IP or port/socket. We can listen to a certain port/socket for commands. Is this the right direction? Should we investigate in other network protocols other than TCP/IP?
We have seen this feature in hardware/device manufacturers provide a CD with a software that can locate their devices on a network even if they have been newly added to the network without network or ip configuration.
Best regards,
Hussam Kazah
Using propriety broadcasting protocol is a very common technique for detecting devices on network without knowing it's name.
However there's a better option:
UPNP, is an excellent protocol for achieving your goals.
libupnp can get you started in no time.
There's a standard protocol called DHCP which allows a network device to make a broadcast request for its IP address. This protocol is widely used by network appliances. On the other hand you may scan your local network for all connected devices using ARP (address resolution protocol) using for example arp-scan utility.