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

Basic concepts:

How Macvlan works:

Macvlan is a network interface supported by the Linux kernel. The required Linux internals are v3.9-3.19 and 4.0; by creating MacVlan subinterfaces for physical network cards, a physical network card is allowed to have multiple independent MAC and IP addresses. The virtual subinterface will be directly exposed to the adjacent physical network. From an external point of view, it is like separating the network cable from multiple strands and accepting it on different hosts. After the physical network card receives the packet, it will judge that the packet needs to be handed over to the virtual network card according to the destination MAC address of the packet received.

Macvlan can be used when the container needs to be directly connected to the physical network. Macvlan itself does not create a network, in essence, the physical Nic of the host is made to work in "promiscuous mode", so that the MAC address of the physical Nic will become invalid and all the traffic in the layer 2 network can be received by the physical Nic. The next step is to create a virtual network card on this physical network card and specify a MAC address for the virtual network card to achieve multiple uses of one card. From the point of view of the physical network, each virtual network card is a separate interface.

When using Macvlan, you should pay attention to the following points: the container is directly connected to the physical network, and the physical network is responsible for assigning IP addresses. The possible result is that the physical network IP addresses are exhausted. Another consequence is the network performance problem. More hosts are connected to the physical network, and the rapid increase in the proportion of broadcast packets leads to network performance degradation. A network on the host needs to work in 'chaotic mode'. As mentioned earlier, the MAC address of a physical Nic working in chaotic mode will become invalid, so the container running in this mode cannot communicate with the public network, but it will not affect the communication between the host and the public network. In the long run, bridge network and overlay network are better choices, because the virtual network should be isolated from the physical network rather than shared. Project environment:

Two docker hosts: (centos7)

Docker01: 172.16.1.30

Docker02: 172.16.1.31

Project operation: example 1: macvlan cross-host single network solution:

Docker01:

(1) enable the promiscuous mode of the ens33 network card, and enable multiple virtual interface (interfaces) of the network card [root@sqm-docker01 ~] # ip link set ens33 promisc on## to view the status of the network card: [root@sqm-docker01 ~] # ip link show ens33

(2) create a macvlan network: [root@sqm-docker01 ~] # docker network create-d macvlan-- subnet 172.16.100.0 parent=ens33 mac_net1 24-- gateway 172.16.100.1-o network

Parameter explanation:

-o: which network card is bound to (based on ens33 network card)

(3) run a container based on the newly created network: [root@sqm-docker01 ~] # docker run-itd-- name box1-- ip 172.16.100.10-- network mac_net1 busybox

Docker02: (same operation as docker01)

Enable promiscuous mode [root@sqm-docker02 ~] # ip link set ens33 promisc on [root@sqm-docker02 ~] # ip link show ens33

/ / create macvlan network [root@sqm-docker02 ~] # docker network create-d macvlan-- subnet 172.16.100.0 parent=ens33 mac_net1// 24-- gateway 172.16.100.1-o parent=ens33 mac_net1// run a container: [root@sqm-docker02 ~] # docker run-itd-- name box2-- network mac_net1-- ip 172.16.100.20 busybox

(4) Test that the two containers between two hosts communicate with each other:

Note:

The reason for ping communication is that both containers are based on real ens33 NICs, so ens33 NICs on the host must be able to communicate with each other. In this way, you can only ping the ip address, but it is impossible to ping the container name.

Example 2: macvlan cross-host multi-network solution: (1) first check the 8021q module of the host kernel: [root@sqm-docker01 ~] # modinfo 8021q

# # if the module is not found, you need to execute the following command to load: [root@sqm-docker01 ~] # modprobe 8021q enable route forwarding: [root@sqm-docker01 ~] # echo "net.ipv4.ip_forward = 1" > / etc/sysctl.conf [root@sqm-docker01 ~] # sysctl-pnet.ipv4.ip_forward = 1

(2) modify network configuration information:

Docker01:

[root@sqm-docker01 ~] # cd / etc/sysconfig/network-scripts/ [root@sqm-docker01 network-scripts] # ls

[root@sqm-docker01 network-scripts] # vim ifcfg-ens33

Create a subnet card based on the ens33 Nic:

[root@sqm-docker01 network-scripts] # cp-p ifcfg-ens33 ifcfg-ens33.10 # Nic name Custom [root@sqm-docker01 network-scripts] # cp-p ifcfg-ens33 ifcfg-ens33.20

-p: means to retain the original attribute (permission)

/ / modify ens33.10 Nic: [root@sqm-docker01 network-scripts] # vim ifcfg-ens33.10## retains only the following options:

/ / modify ens33.20 Nic: [root@sqm-docker01 network-scripts] # vim ifcfg-ens33.20 configuration is the same as ens33.10, only need to modify the ip address:

(3) launch the subnet card:

[root@sqm-docker01 network-scripts] # ifup ifcfg-ens33.10 [root@sqm-docker01 network-scripts] # ifup ifcfg-ens33.20 / / View network information [root@sqm-docker01 network-scripts] # ifconfig

(4) create a macvlan network based on ens33.10 and ens33.20:

Note: different network segments lead to different network names

[root@sqm-docker01] # docker network create-d macvlan-- subnet 172.16.200.0 parent=ens33.20 mac_net20 24-- gateway 172.16.200.1-o parent=ens33.10 mac_ net10 [root @ sqm-docker01 ~] # docker network create-d macvlan-- subnet 172.16.210.0 gateway 172.16.210.1-o parent=ens33.20 mac_net20

(5) run 2 containers based on the above network:

[root@sqm-docker01] # docker run-itd-- name test1-- ip 172.16.200.10-- network mac_net10 busybox [root@sqm-docker01 ~] # docker run-itd-name test2-- ip 172.16.210.10-- network mac_net20 busybox

Deploy docker02:

The operation is basically the same as docker01, note that the network segment is the same, but the host ip is different.

# the following operations will not be explained:

Enable routing forwarding: [root@sqm-docker01 ~] # echo "net.ipv4.ip_forward = 1" > / etc/sysctl.conf [root@sqm-docker01 ~] # sysctl-pnet.ipv4.ip_forward = 1 [root@sqm-docker02 network-scripts] # pwd/etc/sysconfig/network-scripts [root@sqm-docker02 network-scripts] # vim ifcfg-ens33

[root@sqm-docker02 network-scripts] # cp-p ifcfg-ens33 ifcfg-ens33.10 [root@sqm-docker02 network-scripts] # cp-p ifcfg-ens33 ifcfg-ens33.20

[root@sqm-docker02 network-scripts] # vim ifcfg-ens33.10

[root@sqm-docker02 network-scripts] # vim ifcfg-ens33.20

[root@sqm-docker02 network-scripts] # ifup ifcfg-ens33.10 [root@sqm-docker02 network-scripts] # ifup ifcfg-ens33.20// create a macvlan network: [root@sqm-docker02 ~] # docker network create-d macvlan-- subnet 172.16.200.0 parent=ens33.10 mac_ 24-- gateway 172.16.200.1-o parent=ens33.10 mac_ net10 [root @ sqm-docker02 ~] # docker network create-d macvlan-- subnet 172.16.210.0Mab 24-- Gateway 172.16.210.1-o parent=ens33.20 mac_net20// runtime container (different ip address): [root@sqm-docker02 ~] # docker run-itd-- name test3-- network mac_net10-- ip 172.16.200.11 busybox [root@sqm-docker02 ~] # docker run-itd-- name test4-- network mac_net20-- ip 172.16.210.11 busybox

/ / ensure the normal operation of the container:

(6) the test containers can communicate across hosts: (note: if you are in a vmware environment, due to the VMware virtual machine, the default NAT mode of the two hosts must be changed to bridge mode in order to communicate normally.)

Test3 communicates with test1 (same network segment):

Test4 communicates with test2 (same network segment):

Troubleshooting idea: if the hosts cannot communicate after deployment, first confirm whether the firewall or iptables rules are turned off or released, and whether selinux is disabled. Secondly, check whether the network card configuration file of ens33 and its sub-network card contents are modified. Finally, check whether you create the macvlan network segment definition error, or whether the ip address is specified incorrectly when running the container.

-- macvlan multi-network communication across hosts has been deployed-

Expand knowledge points:

Suppose we run a T1 container, and then the T2 container uses the network stack of the T1 container.

[root@sqm-docker03] # docker run-itd-- name T1 busybox [root@sqm-docker03] # docker exec T1 ip a

[root@sqm-docker03] # docker run-it-- name T2-- network container:t1 busybox

/ / next, operate in T1 container: [root@sqm-docker03 ~] # docker exec-it T1 bin/sh

Then you can also see this service in the T2 container:

The above is the basic content of deploying the network stack, which is not often used by yourself, or in order to realize that other containers can share resources in one of the containers.

-this is the end of this article. Thank you for reading-

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.