Shulou(Shulou.com)06/01 Report--

What this article shares with you is about the basic network equipment on Linux. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it with the editor.

Brief introduction of Linux Abstract Network equipment

Similar to disk devices, Linux users want to use network functions, which can not be accomplished by directly operating the hardware, but need to directly or indirectly operate a device abstracted by Linux for us, that is, a general Linux network device. A common situation is that a hardware network card is installed in the system, and Linux will generate a network device instance, such as eth0, for it in the system, and the user needs to issue a command to eth0 to configure or use it. More hardware will bring more device instances, and virtual hardware will also bring more device instances. With the development of network technology and virtualization technology, more and more advanced network devices have been added to Linux, which makes the situation more complicated. In the following chapters, we will analyze several abstract types of Linux network devices commonly used in virtualization technology: Bridge, 802.1.qVLANdevice, VETH, TAP, and explain in detail how to use them with Routetable and IPtable in Linux to simply create a local virtual network.

Working principle of related network equipment

Bridge

Bridge (bridge) is a device used for TCP/IP layer 2 protocol switching on Linux, which is similar to the function of switches in the real world. Bridge device instances can be connected to other network device instances on the Linux, such as attach a slave device, similar to connecting a network cable between a real-world switch and a user terminal. When data arrives, Bridge broadcasts, forwards and discards data according to the MAC information in the message.

Figure 1.Bridge equipment working process

As shown in the figure, the function of Bridge is mainly implemented in the kernel. When a slave device is attach to Bridge, the equivalent of a real-world switch port is plugged into a network cable connected to a terminal. At this point in the kernel program, netdev_rx_handler_register () is called and a callback function to accept data is registered. In the future, whenever the device receives data, it will call this function to forward the data to the Bridge. When Bridge receives this data, br_handle_frame () is called to perform a process similar to that of a real-world switch: determine the category of the packet (broadcast / single point), find the internal MAC port mapping table, locate the destination port number, forward the data to the destination port or discard it, and automatically update the internal MAC port mapping table for self-learning.

There is one difference between a Bridge and a real-world layer 2 switch, as shown on the left side of the figure: data is sent directly to the Bridge rather than being received from a port. This situation can be seen as that Bridge has its own MAC that can actively send messages, or that Bridge comes with a hidden port to automatically connect with the host Linux system, and programs on Linux can send data directly to other ports on the Bridge. So when a Bridge owns a network device, such as when bridge0 joins eth0, bridge0 actually has two valid MAC addresses, one for bridge0 and the other for eth0, and they can communicate with each other. The interesting thing about this is that Bridge can set the IP address. Generally speaking, IP address is the content of layer 3 protocol and should not appear on layer 2 device Bridge. But Bridge in Linux is a kind of general network device abstraction, as long as it is a network device, it can set IP address. When a bridge0 has IP, Linux can locate bridge0 in layer 3 through routing table or IP table rules, which means that Linux has another hidden virtual network card connected to the hidden port of Bridge. This network card is a general network device called bridge0, and IP can be regarded as this network card. When data conforming to this IP reaches the bridge0, the kernel protocol stack assumes that it has received a packet of data destined for the native, and the application can receive it through the Socket. A better comparative example is a real-world routed switch device, which also has a hidden MAC address for use by layer 3 protocol handlers and hypervisors in the device. The layer 3 protocol handler in the device corresponds to the layer 3 protocol handler of the general network device called bridge0, that is, the host Linux system kernel protocol stack program. The hypervisor in the device corresponds to the application in the bridge0 host Linux system.

There is currently a limitation in the implementation of Bridge: when a device is attach to Bridge, the IP of that device becomes invalid and Linux no longer uses that IP to accept data at layer 3. The example is as follows: if the original IP of eth0 is 192.168.1.2, if you receive a data with the destination address of 192.168.1.2, the application of Linux can receive it through Socket operation. When the eth0 is attach to a bridge0, although the IP of the eth0 is still there, the application cannot accept the above data. At this point, IP192.168.1.2 should be assigned to bridge0.

Another thing to pay attention to is the direction of the data flow. For a device that is attach to the Bridge, only when it receives the data will the packet data be forwarded to the Bridge to complete the follow-up operations such as table lookup broadcast. When the request is a send type, the data is not forwarded to the Bridge, it looks for the next send exit. Users often ignore this point when configuring the network, resulting in network failure.

VLANdevicefor802.1.q

VLAN, also known as virtual network, is a widely used concept, and some applications refer to their own internal network as VLAN. Here we are mainly talking about VLAN that exist in the physical world and need to be supported by protocols. There are many kinds of it, which are generally divided into MACVLAN, 802.1.qVLAN, 802.1.qbgVLAN and 802.1.qbhVLAN according to the principle of protocol. Among them, 802.1.qVLAN appeared earlier, widely used and more mature, and its basic principle is to insert additional VLAN protocol data (called 802.1.qVLANTag) into the layer 2 protocol while maintaining compatibility with traditional layer 2 devices. The VLAN device in Linux is an internal software implementation of the 802.1.q protocol that simulates 802.1.q switches in the real world.

Figure 2.VLAN equipment working process

As shown in the figure, 802.1.qVLAN devices in Linux appear in pairs in a mother-child relationship. The mother device is equivalent to the TRUNK port of the switch in the real world, which is used to connect to the upper-level network, and the sub-device is equivalent to the common interface used to connect the lower-level network. When data is passed between parent and child devices, the kernel will act accordingly according to 802.1.qVLANTag. There is an one-to-many relationship between mother and child devices. A parent device can have multiple sub-devices, and a sub-device has only one parent device. When a sub-device has a packet of data to send, the data is added to the VLANTag and then sent out from the parent device. When the parent device receives a packet of data, it will analyze the VLANTag in it. If a corresponding sub-device exists, it forwards the data to that sub-device and removes the VLANTag according to the setting, otherwise it discards the data. Under some settings, VLANTag may not be removed to meet the needs of some listeners, such as DHCP services. The example is as follows: eth0 creates a child device eth0.100 with an ID of 100 as the parent device. At this point, if there is a program that requires a packet of data to be sent from eth0.100, the data will be sent out from eth0 by Tag of VLAN100. If eth0 receives a packet of data with a VLANTag of 100, the data will be forwarded to eth0.100 and the VLANTag will be removed based on the settings. If eth0 receives a packet of data containing VLANTag101, it will be discarded. The above process implies the following facts: for the host Linux system, the parent device can only be used to receive data, and the child device can only be used to send data. Like Bridge, the data of the mother and child devices also have a direction, the data received by the child equipment will not enter the parent device, and the data requested to be sent on the parent device will not be transferred to the child device. We can think of the VLAN mother and child equipment as an 802.1.q switch in the real world. The subordinate interface is connected to the host Linux system network through the sub-device, and the superior interface is connected to the superior network with the master device. When the parent device is a physical network card, the superior network is the external real network, and when the parent device is another Linux virtual network device, the superior network is still the host Linux system network.

It is important to note that the mother and child VLAN devices have the same MAC address and can be thought of as the MAC of the 802.1.q switch in the real world, so multiple VLAN devices share a MAC. When a parent device has multiple VLAN sub-devices, the sub-devices are isolated, and there is no exchange and forwarding relationship like Bridge. The reasons are as follows: the main purpose of 802.1.qVLAN protocol is to logically isolate the ion network. Real-world 802.1.q switches have multiple VLAN, each VLAN has multiple ports, the same VLAN port can be exchanged and forwarded, and different VLAN ports are isolated, so it contains two layers of functions: switching and isolation. LinuxVLANdevice implements the isolation function, not the switching function. It is not possible for a VLAN parent device to have two VLAN subdevices with the same ID, so data exchange is not possible. If you want to connect multiple devices in a VLAN, you need to switch functions. In Linux, Bridge specializes in switching, so attach the VLAN sub-device to a Bridge can complete the subsequent switching function. To sum up, Bridge plus VLANdevice can fully simulate real-world 802.1.q switches at the functional level.

Linux supports VLAN hardware acceleration, and the kernel processing described in the figure can be done on a physical device with specific hardware installed.

TAP device and VETH device

TUN/TAP device is a kind of device that allows user-mode programs to inject data into the kernel protocol stack. One works in layer 3, one works in layer 2, and most TAP devices are used. VETH equipment appeared early, its function is to reverse the direction of communication data, the data that needs to be sent will be converted into the data that needs to be received and re-sent to the kernel network layer for processing, so as to indirectly complete the data injection.

Figure 3.TAP device and VETH device working process

As shown in the figure, when a TAP device is created, a corresponding char device will be generated in the Linux device file directory, and the user program can open the file as if it were a normal file for reading and writing. When the write () operation is performed, the data enters the TAP device, which for the Linux network layer is equivalent to receiving a packet of data from the TAP device and requesting the kernel to accept it, just as an ordinary physical network card receives a packet of data from the outside world, except that the data actually comes from a user program on the Linux. After receiving this data, Linux will carry out subsequent processing according to the network configuration, thus completing the function of user programs to inject data into the network layer of the Linux kernel. When the user program executes the read () request, it is equivalent to querying the kernel whether there is any data that needs to be sent out on the TAP device, or taking it into the user program to complete the data transmission function of the TAP device. An analogy for TAP devices is that an application that uses a TAP device is equivalent to another computer, and a TAP device is a local network card, and they are connected to each other. The application communicates with the native network core through read () / write () operation.

VETH devices always appear in pairs, and data sent to one side for request to be sent always appears in the form of request acceptance from the other side. The device can not be operated directly by the user program, but it is easy to use. Once created and configured correctly, input data to one end, and VETH will change the direction of the data and send it into the kernel network core to complete the data injection. This data can be read at the other end.

Examples of network settings

To better illustrate the use of Linux network devices, the following will use a series of examples to illustrate the flow of data in a virtual network composed of complex Linux network elements. The network settings are briefly introduced as follows: 4 network devices are attach under a central Bridge:bridge0, including 2 VETH devices, 1 TAP device tap0,1 and physical network card eth0. A VLAN sub-device is created at the other end of the VETH. There are two VLAN networks on Linux, namely vlan100 and vlan200. The physical network card is connected to the external network, and a VLAN sub-device with a VLANID of 200is created under it.

Send ARP messages from Vlan100 sub-devices

Figure 4.ARP from vlan100 child device

As shown in the figure, when a user tries ping192.168.100.3, Linux will send an ARP message from the Vlan100 sub-device according to the routing table, as follows:

1) user ping192.168.100.3

2) Linux sends ARP information to Vlan100 sub-devices.

3) the ARP message is typed into the Tag of VLANID100 to become ARP@vlan100 and forwarded to the parent device.

4) the VETH device changes the direction of this transmission request and becomes a message that needs to be processed and sent to the kernel network module.

5) because the peer VETH device is added to the bridge0, and the kernel finds that it receives a message, the message is forwarded to the bridge0.

6) bridge0 processes this ARP@vlan100 message, finds that it is a broadcast request according to TCP/IP layer 2 protocol, and broadcasts this message to all ports it knows, one way to one end of another pair of VETH devices, all the way to TAP device tap0, all the way to physical network card device eth0. At this point on tap0, the user program can read through the read () operation that ARP@vlan100,eth0 will send ARP@vlan100 to the outside world, but the VLAN sub-device of eth0 will not receive it because this data direction is sent to the request rather than received.

7) VETH changes the direction of the request, and at this time, the ARP@vlan100 message requesting acceptance is received at the other end.

8) the peer VETH device finds that there is data to be accepted and has two VLAN sub-devices of its own, so it executes the VLAN processing logic. One of the sub-devices is vlan100, which matches the ARP@vlan100, so the Tag that removes the VLANID100 is forwarded to this sub-device and becomes a standard Ethernet ARP message again. Another sub-device will not get this message because the ID does not match.

9) this VLAN sub-device is attach to another bridge bridge1, so it forwards the ARP message it has received.

10) bridge1 broadcasts ARP messages.

11) eventually another TAP device, tap1, receives this request to send a message, and the user program can get it through read ().

Send ARP messages from Vlan200 sub-devices

Figure 5.ARP from vlan200 child device

Similar to the previous situation, the difference is that the VLANID is 200 and the Vlan200 child device on the opposite side is set to reorder_hdr=0, indicating that the device is required to retain the VLANTag in the received message. At this point, the sub-device will receive the ARP message, but with the Tag of VLANID200, that is, ARP@vlan200.

Send an ARP message from the central bridge

Figure 6.ARP from central bridge

When bridge0 has IP, ARP messages can be sent directly to bridge0 through the Linux routing table user program. At this time, both the tap0 and the external network can receive the ARP, but the VLAN sub-device will not receive the ARP information due to VLANID filtering.

Send ARP@vlan200 message to physical network card from external network

Figure 7.ARP from external network

This occurs when the external network is connected to an VLAN-enabled port that is vlan200. At this point, all VLAN sub-devices with a VLANID of 200will receive a message, and if you set reorder_hdr=0, you will receive an ARP@vlan200 with Tag.

Send ARP in ping from a TAP device

Figure 8.ping from TAP device

Assign IP to the tap0 and add a route, and then Ping the unknown IP of its corresponding network segment will generate an ARP to send the request. It is important to note that because the request is sent rather than received on the tap0, the ARP message will not be forwarded to the bridge, so nothing will happen. A similar situation is drawn on the right side of the figure: sending an ARP request from a Vlan200 sub-device. Due to the lack of VETH devices to reverse the direction of the request, the message will not be forwarded to the bridge, but directly sent to the external network through the physical network card.

Send messages from TAP devices in file operation mode

Figure 9.file operation on TAP device

The user program specifies that there are two ways for tap0 devices to send messages: socket and fileoperation. When you create a new socket with the socket_raw flag and specify the device number, you can ask the kernel to send a message from the tap0. However, similar to the previous pingfromtap0, the message is not forwarded to the bridge0 because of the direction of the message. When the tap device file is opened with open (), the situation is different. When the write () operation is performed, the kernel assumes that the tap0 received the message, which triggers the forwarding action, and the bridge0 receives it. If the message sent is a single point message with VLANID100Tag at destination A, bridge0 will find the corresponding device to forward it, and the corresponding VLAN sub-device will receive the message without VLANID100Tag.

Examples of commands for configuring Network Devices on Linux

Taking the Redhat6.2 Red Hat Linux distribution as an example, if you have installed the VLAN kernel module and the management tool vconfig,TAP/TUN device management tool tunctl, you can set up the aforementioned network devices with the following command:

Create Bridge:brctladdbr [BRIDGENAME]

Delete Bridge:brctldelbr [BRIDGENAME]

Attach device to Bridge: brctladdif [BRIDGENAME] [DEVICENAME]

From Bridgedetach device: brctldelif [BRIDGENAME] [DEVICENAME]

Query Bridge: brctlshow

Create VLAN device: vconfigadd [PARENTDEVICENAME] [VLANID]

Delete VLAN device: vconfigrem [VLANDEVICENAME]

Set up VLAN device flag:vconfigset_ [VLANDEVICENAME] [FLAG] [VALUE]

Set up the VLAN device qos:

Vconfigset_egress_ map[VLANDEVICENAME] [SKB_PRIORITY] [VLAN_QOS]

Vconfigset_ingress_ map[VLANDEVICENAME] [SKB_PRIORITY] [VLAN_QOS]

Query VLAN equipment: cat/proc/net/vlan/ [VLANDEVICENAME]

Create a VETH device: iplinkaddlink [device] typeveth

Create a TAP device: tunctl-p [TAPDEVICENAME]

Delete TAP device: tunctl-d [TAPDEVICENAME]

Query all layer 2 devices in the system, including VETH/TAP devices: iplinkshow

Delete ordinary layer 2 devices: iplinkdelete [device] type [type]

Linux has provided a set of basic tools for users to create a variety of internal networks, using these tools can easily create specific networks for applications to use, including primary internal virtual networks in cloud computing.

These are the basic network devices on Linux, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.