A detailed description of basic network equipment on Linux

A detailed description of basic network equipment on Linux

The principle and use of abstract network equipment

Network virtualization is an important part of Cloud. As a basic knowledge, this paper describes in detail the principles, usages and data flow of various network devices abstracted by Linux. Through this article, you can know how to use the basic network equipment of Linux to configure for a specific purpose, to analyze the possible causes of Linux network failure.

• Content

Introduction to Linux Abstract network devices

Similar to disk devices, Linux users want to use the network function, can not be done by direct operation of hardware, but need to directly or indirectly operate a Linux for our abstraction of the device, both common Linux network equipment to complete. A common situation is that the system is equipped with a hardware network card, Linux in the system for it to generate a network device instance, such as eth0, the user needs to issue a command to eth0 to configure or use it. More hardware will bring more instances of the device, and virtual hardware will bring more instances of the device. With the development of network technology and virtualization technology, more advanced network devices have been added to Linux, which makes the situation more complicated. In the following sections, we will analyze the various types of Linux network device abstractions that are commonly used in virtualization technologies: Bridge, 802.1.Q VLAN device, VETH, TAP, and explain in detail how to use them with Route table, IP table in Linux Simply create a local virtual network.

Related network equipment working principle bridge

Bridge is a device on Linux that is used for TCP/IP Layer two protocol switching, similar to the functionality of a real-world switch. Bridge device instances can be connected to other network device instances on Linux, both 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 the MAC information in the message.

Figure 1.Bridge Equipment Working process

, Bridge's function is mainly implemented in the kernel. When a slave device is attach to Bridge, the port of the real-world switch is plugged into a network cable with a terminal attached. At this point in the kernel program, Netdev_rx_handler_register () is called, and a callback function to accept the data is registered. This function is called every time the data is received from the device to forward the data to Bridge. When bridge receives this data, Br_handle_frame () is called to perform a similar process to the real-world switch: Judging the category of the package (broadcast/single point), locating the internal MAC port mapping table, locating the target port number, forwarding the data to the destination port, or discarding it, Automatically update the internal MAC port mapping table for self-learning.

There is a difference between

Bridge and the real-world Layer two switch, which is shown on the left side of the diagram: data is sent directly to Bridge instead of being accepted from a port. This situation can be seen as bridge itself has a MAC can actively send messages, or bridge comes with a hidden port and the host Linux system automatically connected, Linux program can directly from this port to the other port on the Bridge to send data. So when a Bridge has a network device, such as Bridge0 joined Eth0, in fact Bridge0 has two valid MAC address, one is BRIDGE0, one is eth0, they can communicate with each other. The interesting thing about this is that Bridge can set the IP address. Typically, the IP address is the content of the three layer protocol and should not appear on the two-tier device Bridge. But Linux Bridge is a generic network device abstraction, as long as the network device can set the IP address. When a BRIDGE0 has an IP, Linux can be routed through the routing table or IP table rules in the three layer positioning BRIDGE0, this time equivalent to Linux has another hidden virtual network card and Bridge of the hidden port connected, this network card is called BRIDGE0 General network Device, IP can be regarded as the network card. When data that conforms to this IP arrives at BRIDGE0, the kernel stack considers that it has received a packet of data that is intended to be native, at which point the application can receive it via the Socket. A better contrast example is the real-world lead-in switch device, which also has a hidden MAC address that is used by the three layer protocol handlers and hypervisor in the device. The three layer protocol handler in the device corresponds to a three layer protocol handler for the generic network device named BRIDGE0, which is the host Linux Kernel protocol stack program. The management program in the device corresponds to the application in the BRIDGE0 host Linux system.

Bridge implementation currently has a limitation: when a device is attach to Bridge, the IP of that device becomes invalid, and Linux no longer uses that IP to accept data on layer three. For example, if the eth0 original IP is 192.168.1.2, if you receive a destination address that is 192.168.1.2 data, the Linux application can receive it through the Socket operation. When eth0 is attach to a bridge0, the application cannot accept the above data, although Eth0 's IP is still there. IP 192.168.1.2 should be given to bridge0 at this time.

Another thing to note is the direction of the data flow. For a device to be attach to bridge, only when it receives data, the packet data will be forwarded to bridge to complete the subsequent operations such as table-check broadcast. When the request is a send type, the data is not forwarded to Bridge and it looks for the next send exit. Users often ignore this when they configure the network and cause network failures.

VLAN Device for 802.1.Q

VLANs, also known as virtual networks, are a widely used concept, with some applications calling their own internal networks also known as VLANs. The main point here is that there are VLANs in the physical world that require protocol support. There are many kinds of it, according to the principle of protocol generally divided into: Macvlan, 802.1.q VLAN, 802.1.QBG VLAN, 802.1.QBH VLAN. Among the earlier, widely used and mature 802.1.q VLANs, the rationale is to insert additional VLAN protocol data (called 802.1.Q VLAN Tag) in the two layer protocol, while maintaining compatibility with traditional two-tier devices. VLAN devices in Linux are an internal software implementation of the 802.1.Q protocol, simulating 802.1.Q switches in the real world.

Figure 2. VLAN Device Work Process

, the Linux 802.1.q VLAN device is a parent-child relationship in pairs, the parent device equivalent to the real-world switch TRUNK port, used to connect the upper network, sub-devices equivalent to the normal interface for the connection of subordinate networks. When data is passed between mother and child devices, the kernel will perform the corresponding operation according to the 802.1.Q VLAN Tag. Mother and child equipment is a one-to-many relationship, a parent device can have multiple sub-devices, a sub-device only a single parent device. When a child device has a packet of data that needs to be sent, the data is added to the VLAN Tag and then sent out from the parent device. When the parent device receives a packet of data, it analyzes the VLAN tag in it and, if there is a corresponding sub-device, forwards the data to that child device and removes the VLAN tag according to the settings, otherwise discarding the data. Under certain settings, VLAN Tag can be removed from the need to satisfy certain listeners, such as a DHCP service program. Examples are as follows: Eth0 creates a child device with ID 100 as the parent device eth0.100. At this point, if a program requires a packet of data to be sent from eth0.100, the data will be sent from eth0 with the Tag on VLAN 100. If Eth0 receives a packet of data, the VLAN tag is 100, the data is forwarded to the eth0.100, and the VLAN tag is removed based on the settings. If eth0 receives a packet containing VLAN TAG 101 data, it will be discarded. The above procedure implies the fact that for a host Linux system, the parent device can only be used to collect data, and the sub-device can only be used to send data. Like Bridge, the data of the mother and child device is also in the direction, the data received by the sub-device does not enter the parent device, and the data requested on the parent device will not be transferred to the child device. VLAN mother and child devices can be used as a whole to imagine the real world of 802.1.Q switches, sub-interface through the child device connected to the host Linux system network, the parent interface with the main device connected to the upper network, when the parent device is a physical network card, the superior network is the external real networks, when the mother device is another In Linux virtual network devices, the parent network is still the host Linux system network.

It is important to note that the parent-child VLAN device has the same MAC address, which can be used as a Mac for the real-world 802.1.q switch, 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 Bridge-like exchange-forwarding relationship for the following reasons: The main purpose of the 802.1.Q VLAN protocol is to logically isolate subnets. A 802.1.q switch in the real world has multiple VLANs, each with multiple ports, a single VLAN port that can be exchanged for forwarding, and isolation between different VLAN ports, so it contains two layers of functionality: Swap and quarantine. Linux VLAN Device implements the isolation function without switching. A VLAN parent device cannot have two VLAN sub-devices of the same ID, so there is no possibility of data exchange. If you want to connect multiple devices to a VLAN, you need to switch functions. In Linux, Bridge is dedicated to switching functions, so the VLAN sub-device is attach to a bridge to complete the subsequent switching functions. In summary, Bridge plus VLAN device can fully simulate the real-world 802.1.Q switches at the functional level.

Linux supports VLAN hardware acceleration, and in the case of a specific hardware installation, the kernel process described in the figure can be placed on a physical device.

TAP Equipment and VETH equipment

The TUN/TAP device is a device that allows user-state programs to inject data into the kernel protocol stack, one that works on three levels, one that works on two levels, and that uses more TAP equipment. VETH device appears earlier, its role is to reverse the direction of communication data, the need to send the data will be converted into the data needed to be sent back to the core network layer for processing, thereby indirectly complete the data injection.

Figure 3. TAP Equipment and VETH equipment working process

, 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 to read and write like a normal file. When the write () operation, the data into the tap device, at this time for the Linux network layer, the equivalent of a tap device received a packet of data, request the kernel to accept it, as the normal physical network card from the outside world received a packet of data, the difference is actually the data from a Linux user program. After receiving this data, Linux will follow the network configuration for subsequent processing, thus completing the user program's ability to inject data into the Linux kernel network layer. When the user program executes the read () request, it is equivalent to querying the kernel for data that needs to be sent out on the tap device, and some words are taken out to the user program to complete the data transmission function of the tap device. A metaphor for a tap device is that an application that uses a tap device is equivalent to another computer, and the TAP device is a network card for the machine, and they are connected to each other. The application communicates with the native network core through the read ()/write () operation.

VETH devices are always paired, and the data sent to one end of the request is always seen in the form of request acceptance from the other end. The device cannot be operated directly by the user program, but it is relatively simple to use. Once created and configured correctly, the data is entered at one end, and VETH changes the direction of the data and feeds it into the kernel network core to complete the data injection. This data can be read at the other end.

Network Setup Example Description

To better illustrate the use of Linux network devices, the following is a series of examples showing the flow of data in a virtual network composed of a complex set of Linux network elements. The network settings are described as follows: a central BRIDGE:BRIDGE0 attach 4 network devices, including 2 VETH devices, 1 TAP devices tap0,1 physical NIC Eth0. VLAN sub-devices are created at the other end of the VETH. There are a total of 2 VLAN networks on Linux, both vlan100 and vlan200. The physical NIC is connected to the external network and a VLAN sub-device with a VLAN ID of 200 is created below it.

Send ARP Message from vlan100 sub-device Figure 4. ARP from vlan100 child device

, when the user attempts to ping 192.168.100.3, Linux will emit ARP messages from the VLAN100 sub-device based on the routing table, as follows:

1) User Ping 192.168.100.3

2) Linux sends ARP messages to vlan100 sub-devices.

3) ARP message is tagged with VLAN ID 100 as [email protected] and forwarded to the parent device.

4) The VETH device transforms this sending request into a message that needs to be processed into the kernel network module.

5) as the VETH device on the end is added to the BRIDGE0, and the kernel discovers that it receives a message, the message is forwarded to the BRIDGE0.

6) BRIDGE0 processing this [email protected] information, according to the TCP/IP two Layer protocol discovery is a broadcast request, so to all the ports it knows to broadcast this message, which all the way into another pair of VETH equipment, one end, all the way into the TAP device tap0, all the way into the physical Nic device eth0. At this time on the TAP0, the user program can read through the [) operation [email Protected],eth0 will be sent to the outside [email protected], but the eth0 VLAN sub-device will not receive it, because this data direction for the request sent instead of the request to receive 。

7) VETH the request direction, and at the other end of the request to receive the [email protected] message.

8) The end VETH device discovers that there is data to be accepted, and that it has two VLAN sub-devices, and then performs the VLAN processing logic. One of the sub-devices is vlan100, and [email protected] match, so the removal of the VLAN ID 100 Tag forwarding to this sub-device, re-become the standard Ethernet ARP message. Another sub-device does not receive this message because it does not match the ID.

9) This VLAN sub-device is attach to another bridge bridge1 and forwards the ARP messages it receives.

Bridge1 broadcast ARP messages.

11) Finally, another TAP device TAP1 received this request to send a message, the user program through read () can get it.

Send ARP Message from vlan200 sub-device Figure 5. ARP from vlan200 child device

Similar to the previous case, the difference is that the VLAN ID is 200, and the vlan200 child device on the peer is set to REORDER_HDR = 0, indicating that the device is required to retain the VLAN Tag in the received message. At this point the child device receives the ARP message, but with the VLAN ID 200 Tag, both [email protected].

Send ARP message from Central bridge Figure 5. ARP from the Central bridge

When Bridge0 owns the IP, the ARP message can be sent directly to BRIDGE0 through the Linux routing table user program. At this point the tap0 and the external network can receive ARP, but the VLAN sub-device because of the VLAN ID filtering, will not be receiving ARP information.

Send the [email protected] message from the external network to the physical network card Figure 6. ARP from External network

This condition occurs when the external network connection is in a support VLAN and the corresponding port is vlan200. All VLAN sub-devices with VLAN ID 200 will receive the message at this time, and if set reorder_hdr=0, they will get [email protected] with Tag.

Send ARP diagram from a tap device ping 7. Ping from tap device

Assigning IP to the Tap0 and joining the route, and then pinging the unknown IP of its corresponding network segment, will generate ARP send requests. It is important to note that the ARP message will not be forwarded to the bridge, and nothing will happen because the TAP0 is sending instead of receiving the request. A similar scenario is drawn on the right side of the diagram: sending an ARP request from a vlan200 child device. Due to the lack of VETH device reversal request direction, the message will not be forwarded to the bridge, but directly through the physical network card sent to the external network.

Send a newspaper from a tap device as a file operation Article 8. File operation on tap device

The user program specifies that the TAP0 device sends a message in two ways: socket and file operation. When you create a new socket with the SOCKET_RAW flag and specify the device number, you can ask the kernel to send the message from TAP0. However, similar to the previous ping from tap0, messages are not forwarded to BRIDGE0 because of the message orientation. When opening a tap device file with open (), the situation is different. When the write () operation is performed, the kernel thinks that Tap0 received the message, which triggers the forwarding action and BRIDGE0 will receive it. If the sent message is a single-point message with a VLAN ID of $ tag at a destination, BRIDGE0 will find the corresponding device to be forwarded, and the corresponding VLAN sub-device will receive a message without the VLAN ID of the tag.

Example of configuring network device commands on Linux

In the case of Redhat6.2 Red Hat Linux distributions, if you have installed the VLAN kernel modules and management Tools Vconfig,tap/tun Device Management tool TUNCTL, you can set up the aforementioned network devices with the following command:

• Create Bridge:brctl ADDBR [Bridge NAME]
• Delete Bridge:brctl Delbr [Bridge NAME]
• Attach device to Bridge:brctl addif [Bridge name] [device name]
• From bridge Detach device: Brctl Delif [Bridge name] [device name]
• Check Bridge situation: Brctl Show
• To create a VLAN device: vconfig Add [PARENT device NAME] [VLAN ID]
• Remove VLAN device: vconfig REM [VLAN device NAME]
• Set VLAN devices flag:vconfig Set_flag [VLAN device NAME] [flag] [VALUE]
• To set VLAN device QoS:

Vconfig Set_egress_map [VLAN DEVICE NAME] [skb_priority] [Vlan_qos]

Vconfig Set_ingress_map [VLAN DEVICE NAME] [skb_priority] [Vlan_qos]

• Query VLAN device Condition: Cat/proc/net/vlan/[vlan device NAME]
• Create VETH Device: IP link Add link [DEVICE NAME] Type VETH
• Create a tap device: tunctl-p [tap device NAME]
• Delete tap device: tunctl-d [tap device NAME]
• Query all two-tier devices in the system, including VETH/TAP devices: IP link Show
• Remove normal two-tier device: IP link Delete [device NAME] type [type]

Summary

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

Transferred from: http://www.ibm.com/developerworks/cn/linux/1310_xiawc_networkdevice/

A detailed description of basic network equipment on Linux