Basic network equipment on Linux

Introduction to Linux Abstract network devices

Similar to disk devices, Linux users want to use the network function, not through direct operation of the hardware, but need to directly or indirectly operate a Linux for our abstraction of the device, the Universal Linux network equipment to complete. A common situation is that the system has a hardware network card, Linux will be in the system to generate a network device instance, such as eth0, the user needs to eth0 issued a command to configure or use it. More hardware will bring more device instances, and virtual hardware will bring in more device instances. With the development of network technology and virtualization technology, more advanced network devices have been added to Linux, making the situation more complicated. In the following chapters, you will analyze the various types of Linux network devices that are often used in virtualization technology: Bridge, 802.1.Q VLAN device, VETH, TAP, and explain how to use them in conjunction with Linux Route table, IP table Simple to create a local virtual network.

Working principle of related network equipment

Bridge

Bridge is a device used on Linux to make TCP/IP two-layer protocol exchange, similar to the real-world switch function. Bridge device instances can be connected to other network device instances on Linux, both attach a 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

As shown in the diagram, bridge functions are mainly implemented in the kernel. When a device is attach to bridge    , the equivalent of a switch port in the real world is plugged into a network cable with a terminal attached. At this point in the kernel program, Netdev_rx_handler_register () is invoked, and a callback function for accepting data is registered. This function is then invoked whenever this data is received from the device to forward the data to the    bridge. When bridge receives this data, Br_handle_frame () is called to perform a similar process to the real world switch: To determine the packet's category (broadcast/single point), to locate the internal MAC port mapping table, to locate the target port number, to forward the data to the target port or discard, Automatically updates the internal MAC port mapping table to learn from self.

The difference between the

Bridge and the real world two-tier switch is shown on the left side of the picture: The data is sent directly to the bridge, not from a port. This situation can be considered as bridge     own a MAC can send messages, or bridge itself with a hidden port and host Linux system automatically connected, Linux programs can be directly from this port to &N   BSP; the other port on the is sending data. So when a bridge has a network device, such as when Bridge0 joins the eth0, BRIDGE0 actually has two valid MAC addresses, one is BRIDGE0, the other is eth0, and they can communicate with each other. The interesting thing about this is that bridge can set an IP address. Typically, the IP address is the content of the three-tier protocol and should not appear on the two-tier device bridge. But Linux Bridge is a common network device abstraction, as long as the network device can set IP address. When a BRIDGE0 has IP, Linux can be routed through the table or IP table rules in the three-tier positioning bridge0, at this time the equivalent of Linux has another hidden virtual network card and bridge hidden port connected, this network card is called BRIDGE0 Universal network Device, IP can be considered as this network card. When a data that matches this IP arrives at BRIDGE0, the kernel protocol stack considers that a packet of target data is received, and the application can receive it via the Socket. A better contrast example is the real-world lead-by switch device, which also has a hidden MAC address for use by the three-tier protocol handler and the management program in the device. The three-layer protocol handler in the device, which corresponds to the three-layer protocol handler of the Universal network device named BRIDGE0, the host Linux System kernel protocol stack program. A management program in a device that corresponds to an application in a BRIDGE0 host Linux system.

The implementation of bridge currently has a limitation: when a device is attach on the island, the IP of that device becomes invalid, and Linux no longer uses that IP to accept data on the three level. For example: If Eth0 IP is 192.168.1.2, if you receive a target address is 192.168.1.2 data, Linux applications can receive it through the Socket operation. When eth0 is attach to a bridge0, the application cannot accept the above data, although Eth0 IP is still there. The 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 that is attach to bridge, only when it receives data, the packet data is forwarded to bridge, which completes the subsequent operations such as look-up table broadcast. When the request is a send type, the data is not forwarded to bridge, it will look for the next send exit. Users often ignore this when they configure the network, causing network failure.

VLAN Device for 802.1.Q

VLAN also known as virtual network, is a widely used concept, some applications to their own internal network also known as VLANs. The main point here is that there is a VLAN in the physical world that requires protocol support. It is a lot of kinds, according to the principle of the agreement is generally divided into: Macvlan, 802.1.q VLAN, 802.1.QBG VLAN, 802.1.QBH VLAN. It appears earlier, widely used and more mature is the 802.1.q VLAN, its 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. The VLAN device in Linux is an internal software implementation of the 802.1.Q protocol, simulating the 802.1.Q switch in the real world.

Figure 2. VLAN Device Working process

As shown in the picture, Linux 802.1.q VLAN device is a pair of parent-child relationship, the mother device equivalent to the real world Switch TRUNK port, used to connect the superior network, the child device equivalent to the normal interface used to connect the subordinate network. When data is passed between mother and child devices, the kernel will operate according to the 802.1.Q VLAN Tag. Mother-child devices are a one-to-many relationship, one parent device can have multiple child devices, and one child device has only one parent device. When a child device has a packet of data to send, the data is added to the VLAN Tag and sent from the parent device. When the parent device receives a packet of data, it will analyze the VLAN tag, and if there is a corresponding child device, forward the data to that child device and remove the VLAN tag according to the settings, otherwise discard the data. Under some settings, VLAN Tag can be removed without being moved to meet the needs of some listeners, such as DHCP service programs. As an example, Eth0 creates a child device with ID 100 as a parent device eth0.100. At this point, if a program requires sending a packet of data from ETH0.100, the data will be sent out from eth0 with the Tag of VLAN 100. If Eth0 receives a packet of data, the VLAN tag is 100, the data is forwarded to the eth0.100, and the settings decide whether to remove the VLAN tag. If Eth0 receives a packet of data containing the VLAN Tag 101, it will be discarded. The above process implies the fact that, for host Linux systems, the parent device can only be used to collect data, and the child devices can only be used to send data. Like bridge, the data for the mother-child device is also in the direction, and the data received by the child device does not enter the parent device, and the data requested on the parent device is not transferred to the child device. You can imagine the VLAN parent-child device as a whole in the real-world 802.1.Q switch, subordinate interface through the child devices connected to the host Linux system network, the superior interface with the main device to connect to the superior network, when the mother device is a physical network card is the network is the external reality, when the mother device is another The parent network is still the host Linux system network in Linux virtual network devices.

Note that the parent-child VLAN device has the same MAC address and can be used as a Mac for the 802.1.Q switch in the real world, so multiple VLAN devices share a Mac. When a parent device has multiple VLAN devices, the sub devices are isolated and there is no exchange forwarding relationship like bridge, for the following reasons: The main purpose of the 802.1.Q VLAN protocol is to isolate subnets logically. The real World 802.1.Q switch has multiple VLANs, each VLAN has multiple ports, the same VLAN port can be exchanged between forwarding, different VLAN port isolation, so it contains two layers of functionality: Exchange and isolation. The Linux VLAN device is isolated and has no switching capabilities. It is not possible for a VLAN parent device to have two VLAN devices with the same ID, so data exchange cannot occur. Switching functionality is required if you want to have multiple devices in one VLAN. In Linux, Bridge is dedicated to switching functions, so attach the VLAN device to an end can be the next Exchange function. To sum up, bridge plus VLAN device can simulate the real world 802.1.q switch completely at the functional level.

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

TAP Equipment and VETH equipment

Tun/tap device is a device that allows user-state programs to inject data into the kernel protocol stack, one working on the three floor, one working on the two floor, and more using TAP equipment. VETH equipment appears earlier, its role is to reverse the direction of communication data, the need to send the data will be converted to the need to receive the data back into the kernel Network layer processing, so that the indirect completion of data injection.

Figure 3. TAP Equipment and VETH equipment working process