entbops.blogg.se - Tap vs tun

Tap vs tun driver#

Uplink Port on the physical switch - connects to external network.

Ethernet Port on the server - commonly called pNIC (physical NIC).

How does this happen? As seen in the image below the following components are key for physical networking: Eventually this traffic from virtual ports needs to be sent to the physical network for external connectivity. Similarly for virtual machines this traffic needs to be handled by the virtual ethernet ports. The network data traffic is handled by the physical Ethernet ports on physical machines. Let us now focus a bit more on these virtual ports to see what happens behind the scenes to make virtual networking actually work. Usually we don't have many chances to use tun/tap devices, but because of its simple structure, it's good to learn about virtual network devices, which paves the way for the subsequent understanding of more complex virtual network devices (such as bridges) under Linux.In the previous blog of this series we saw that using Linux bridge we can connect a virtual Ethernet port of a VM to the physical Ethernet port of the hypervisor server. #Explain that the package was sent to the application correctly, but the application did not process the ping -c 4 192.168.3.12 #But in the first two windows, you can see the four icmp echo request packages sent out here. #So ping here doesn't receive the return package at all. #Because when we receive the data package in our program, we do nothing, which is equivalent to discarding the data package. #According to the default route, the packet will go to tun1 device. Start tun1 with the following sudo ip link set tun1 up Let's first attach an IP address to sudo ip addr add 192.168.3.11/24 dev tun1 #In my test environment, the name of the extra device is tun1, which may be tun0 in your environment. #After / tun is started, an additional tun device will be found in the system through the ip link command. | | User Application A | | User Application B |

Tap vs tun driver#

So one end of the virtual network device is also the protocol stack, and the other end depends on the driver implementation of the virtual network device. As for how and where to send out, it's device-driven. The data from the protocol stack will also be handed over to the network devices. The data from network devices will be forwarded to the protocol stack. For the Linux kernel network equipment management module, there is no difference between virtual devices and physical devices. What about a virtual network device? Firstly, it is also managed by the network equipment management subsystem of the kernel. The driver does not need to know the details of the protocol stack, nor does the protocol stack need to know the details of the device driver.įor a network device, like a pipe, there are two ends, and the data received from either end will be sent from the other end.įor example, a physical network card eth0, whose two ends are the core protocol stack (indirect communication through the kernel network device management module) and the external physical network, the data received from the physical network will be forwarded to the core protocol stack, and the data sent by the application from the protocol stack will be sent through the physical network. It is known that there is a network device management layer in the Linux kernel, which is between the network device driver and protocol stack, responsible for connecting the data interaction between them. Stay The Receiving Process of Linux Network Packet and The sending process of data package In these two articles, the process of sending and receiving data packets is introduced. The difference between virtual devices and physical devices Beginning with this article, we will introduce virtual network devices under Linux. In today's cloud era, there are virtual machines and containers everywhere, and the network management behind them can not be separated from virtual network devices, so understanding virtual network devices is conducive to our better understanding of the network structure in the cloud era.