Linux supports virtual networking via various artifacts such as:
A quick definition of tap/veth is as follows:
TAP
A TAP is a simulated interface which exists only in the kernel and has no physical component associated with it. It can be viewed as a simple Point-to-Point or Ethernet device, which instead of receiving packets from a physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program.
When a user space program (in our case the VM) gets attached to the tap interface it gets hold of a file descriptor, reading from which gives it the data being sent on the tap interface. Writing to the file descriptor will send the data out on the tap interface.
Veth (Virtual Ethernet)
Veth interfaces always come in pairs and are like two ethernet adapters connected together by a RJ45 cable. Data sent on one interface exits the other and viceversa.
Openstack heavily uses these artifacts and when a person gets newly introduced to these concepts things can become quite fuzzy. One area that can cause confusion is in understanding what the difference between a tap interface is as compared to veth interface, as both of them seem to be doing the same thing i.e transmitting ethernet frames.
To illustrate, when a VM (vm01) is spawned in Openstack, the artifacts used in the background are shown below:
The network connectivity of vm01 is as follows:
vm01:eth0 <==== connected to ===> vnet0 (tap interface) of qbrXXX (bridge)
qbrXXX (Linux bridge) <=== connected to ===> br-int (OVS bridge) by the veth pair qvbXXX---qv0XXX.
As can be seen the tap connects vm0 to the first bridge and the veth pair connects the first bridge to the next. So both of them look like an RJ45 cable connecting devices. So whats the big deal? Why can't we use only one type? Why do we need this mix?
The answer is* because of legacy technologies in play. When a VM is spawned on KVM it expects a tap interface to be connected to the VM's ethernet port (eth0). By this process, KVM gets a file descriptor on which it can write/read ethernet frames.
Veth on the other hand is a newer construct and is supported by latest artifacts such as linux bridges, namespaces and openvswith.
In summary, both tap & Veth do the same job but interface with technologies from different eras.
Further Reading:
- Soft Switches (Linux Bridge, OpenVSwitch)
- Virtual Network Adapters (tun, tap, veth and a few more)
A quick definition of tap/veth is as follows:
TAP
A TAP is a simulated interface which exists only in the kernel and has no physical component associated with it. It can be viewed as a simple Point-to-Point or Ethernet device, which instead of receiving packets from a physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program.
When a user space program (in our case the VM) gets attached to the tap interface it gets hold of a file descriptor, reading from which gives it the data being sent on the tap interface. Writing to the file descriptor will send the data out on the tap interface.
Veth (Virtual Ethernet)
Veth interfaces always come in pairs and are like two ethernet adapters connected together by a RJ45 cable. Data sent on one interface exits the other and viceversa.
Openstack heavily uses these artifacts and when a person gets newly introduced to these concepts things can become quite fuzzy. One area that can cause confusion is in understanding what the difference between a tap interface is as compared to veth interface, as both of them seem to be doing the same thing i.e transmitting ethernet frames.
To illustrate, when a VM (vm01) is spawned in Openstack, the artifacts used in the background are shown below:
 |
| Pic obtained from Openstack Admin Guide |
The network connectivity of vm01 is as follows:
vm01:eth0 <==== connected to ===> vnet0 (tap interface) of qbrXXX (bridge)
qbrXXX (Linux bridge) <=== connected to ===> br-int (OVS bridge) by the veth pair qvbXXX---qv0XXX.
As can be seen the tap connects vm0 to the first bridge and the veth pair connects the first bridge to the next. So both of them look like an RJ45 cable connecting devices. So whats the big deal? Why can't we use only one type? Why do we need this mix?
The answer is* because of legacy technologies in play. When a VM is spawned on KVM it expects a tap interface to be connected to the VM's ethernet port (eth0). By this process, KVM gets a file descriptor on which it can write/read ethernet frames.
Veth on the other hand is a newer construct and is supported by latest artifacts such as linux bridges, namespaces and openvswith.
In summary, both tap & Veth do the same job but interface with technologies from different eras.
Further Reading:
- Linux Kernel Documentation for tun/tap
- http://backreference.org/2010/03/26/tuntap-interface-tutorial/
Comments