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

This article will explain in detail what is the use of Linux virtual network device veth-pair for you. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

What is 01 veth-pair?

As the name implies, veth-pair is a pair of virtual device interfaces, and unlike tap/tun devices, it appears in pairs. One end is connected to the protocol stack and the other is connected to each other. As shown in the following figure:

Because of this feature, it often acts as a bridge to connect a variety of virtual network devices, such as "connection between two namespace", "connection between Bridge and OVS", "connection between Docker containers" and so on, so as to build very complex virtual network structures, such as OpenStack Neutron.

02 connectivity of veth-pair

Let's add IP:10.1.1.2 and 10.1.1.3 to the veth0 and veth2 in the figure above, and then veth2 from veth0 ping. Theoretically, they are in the same network segment and can be connected to ping, but the result is that ping is not available.

Grab a bag, tcpdump-nnt-I veth0

Root@ubuntu:~# tcpdump-nnt-I veth0tcpdump: verbose output suppressed, use-v or-vv for full protocol decodelistening on veth0, link-type EN10MB (Ethernet), capture size 262144 bytesARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28ARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28

As you can see, because veth0 and veth2 are on the same network segment and are connected for the first time, ARP packets are sent in advance, but veth2 does not respond to ARP packets.

After consulting, this is due to some ARP-related default configuration restrictions in the kernel of the Ubuntu system I use. You need to modify the configuration items:

Echo 1 > / proc/sys/net/ipv4/conf/veth2/accept_localecho 1 > / proc/sys/net/ipv4/conf/veth0/accept_localecho 0 > / proc/sys/net/ipv4/conf/all/rp_filterecho 0 > / proc/sys/net/ipv4/conf/veth0/rp_filterecho 0 > / proc/sys/net/ipv4/conf/veth2/rp_filter

Just ping it when you're done.

Root@ubuntu:~# ping-I veth0 10.1.1.3-c 2PING 10.1.1.3 (10.1.1.3) from 10.1.1.2 veth0: 56 (84) bytes of data.64 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=0.047 ms64 bytes from 10.1.1.3: icmp_seq=2 ttl=64 time=0.064 ms--- 10.1.1.3 ping statistics-2 packets transmitted, 2 received, 0 packet loss Time 3008msrtt min/avg/max/mdev = 0.047 ms 0.072 ms 0.113 pound 0.025

We are interested in this communication process, so we can grab the bag and have a look.

For veth0 ports:

Root@ubuntu:~# tcpdump-nnt-I veth0tcpdump: verbose output suppressed, use-v or-vv for full protocol decodelistening on veth0, link-type EN10MB (Ethernet), capture size 262144 bytesARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28ARP, Reply 10.1.1.3 is-at 5a:07:76:8e:fb:cd, length 28IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 1 Length 64IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 2, length 64IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 3, length 64IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2244, seq 1, length 64

For veth2 ports:

Root@ubuntu:~# tcpdump-nnt-I veth2tcpdump: verbose output suppressed, use-v or-vv for full protocol decodelistening on veth2, link-type EN10MB (Ethernet), capture size 262144 bytesARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28ARP, Reply 10.1.1.3 is-at 5a:07:76:8e:fb:cd, length 28IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 1 Length 64IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 2, length 64IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 3, length 64IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2244, seq 1, length 64

Strange, we don't see ICMP's echo reply package, so how does it ping?

As a matter of fact, echo reply goes through the localback entrance here, so grab a bag and have a look:

Root@ubuntu:~# tcpdump-nnt-I lotcpdump: verbose output suppressed, use-v or-vv for full protocol decodelistening on lo, link-type EN10MB (Ethernet), capture size 262144 bytesIP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 1, length 64IP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 2, length 64IP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 3 Length 64IP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 4, length 64

Why?

Let's take a look at the whole communication process.

First, the ping program constructs the ICMP echo request and sends it to the protocol stack through socket. Because ping specifies to go through the veth0 port, if it is the first time, you need to send an ARP request, otherwise the protocol stack will directly give the packet to veth0. Because veth0 is connected to veth2, ICMP request sends it directly to veth2. When veth2 receives the request, it gives it to the protocol stack on the other side. The protocol stack looks at the local IP of 10.1.1.3, so the ICMP reply packet is constructed, and the routing table is checked. It is found that the packet returned to the 10.1.1.0 network segment should go through the localback port, so the reply packet is handed over to the lo port (table 0 of the routing table will be viewed first, and ip route show table 0 will be checked). After receiving the reply packet of the protocol stack, lo did nothing and returned it to the protocol stack. After receiving the reply packet, the protocol stack found that socket was waiting for the packet, so it gave the packet to socket. Waiting for the ping program in user mode to find the return of socket, it receives the reply packet of ICMP.

The whole process is shown in the following figure:

03 Connectivity between two namespace

Namespace is a feature supported after the Linux 2.6.x kernel version and is mainly used for resource isolation. With namespace, a Linux system can abstract multiple network subsystems, each of which has its own network equipment, protocol stack and so on, which do not affect each other.

What if each namespace needs to communicate with each other? the answer is to use veth-pair as a bridge.

According to the way and scale of the connection, it can be divided into "directly connected", "connected through Bridge" and "connected through OVS".

3.1 directly connected

Direct connection is the easiest way, as shown in the following figure, a pair of veth-pair directly connects two namespace together.

Configure IP for veth-pair to test connectivity:

# create namespaceip netns a ns1ip netns a ns2# create a pair of veth-pair veth0 veth2ip l a veth0 type veth peer name veth2# add veth0 veth2 to two nsip l s veth0 netns ns1ip l s veth2 netns ns2# to two veth0 veth2 with IP and enable ip netns exec ns1ip an a 10.1.1.2 veth0 upip netns exec ns2 ip an a 24 dev veth0ip netns exec ns1ip l s veth0 upip netns exec ns2 ip an a 10.1.1.3 24 dev veth2ip netns exec ns2 ip l s veth2 up# from veth0 Ping veth2 [root@localhost ~] # ip netns exec ns1 ping 10.1.1.3PING 10.1.1.3 (10.1.1.3) 56 (84) bytes of data.64 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=0.073 ms64 bytes from 10.1.1.3: icmp_seq=2 ttl=64 time=0.068 ms--- 10.1.1.3 ping statistics-15 packets transmitted 15 received, 0% packet loss, time 14000msrtt min/avg/max/mdev = 0.068, 0.084, 0.201, 0.032 ms3.2 is connected through Bridge

Linux Bridge is the equivalent of a switch that can transfer traffic from two namespace. Let's see what role veth-pair plays in it.

As shown in the following figure, two pairs of veth-pair connect two namespace to the Bridge.

Also configure IP for veth-pair to test its connectivity:

# first create bridge br0ip l a br0 type bridgeip l s br0 up# and then create two pairs of veth-pairip l a veth0 type veth peer name br-veth0ip l a veth2 type veth peer name br-veth2# to add two pairs of veth-pair to two ns and br0ip l veth0 netns ns1ip l s br-veth0 master br0ip l s br-veth0 upip l s veth2 netns ns2ip l s br-veth2 master br0ip l s br-veth2 up# to configure IP and enable ip netns exec ns1 for veth in the two ns Ip an a 10.1.1.2 ip an a 24 dev veth0ip netns exec ns1 ip l s veth0 upip netns exec ns2 ip an a 10.1.1.3 24 dev veth2ip netns exec ns2 ip l s veth2 up# veth0 ping veth2 [root@localhost ~] # ip netns exec ns1 ping 10.1.1.3PING 10.1.1.3 (10.1.1.3) 56 (84) bytes of data.64 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=0.060 ms64 bytes from 10.1.1 .3: icmp_seq=2 ttl=64 time=0.105 ms--- 10.1.1.3 ping statistics-2 packets transmitted 2 received, 0% packet loss, time 999msrtt min/avg/max/mdev = 0.060, 0.082, 0.105, 0.024 ms3.3 is connected by OVS

OVS is a third-party open source Bridge, which is more powerful than Linux Bridge. For the same experiment, let's use OVS to see what the effect is.

As shown in the following figure:

Also test the connectivity between the two namespace:

# create an ovs bridgeovs-vsctl add-br ovs-br# with the command provided by ovs to create two pairs of veth-pairip l a veth0 type veth peer name ovs-veth0ip l a veth2 type veth peer name ovs-veth2# to add both ends of veth-pair to ns and ovs bridge respectively ip l s veth0 netns ns1ovs-vsctl add-port ovs-br ovs-veth0ip l s ovs-veth0 upip l s veth2 netns ns2ovs-vsctl add-port ovs-br ovs-veth2ip l s ovs-veth2 up# to ns Configure IP and enable ip netns exec ns1 ip an a 10.1.1.2 veth 24 dev veth0ip netns exec ns1 ip l s veth0 upip netns exec ns2 ip an a 10.1.1.3 bytes of data.64 bytes from 24 dev veth2ip netns exec ns2 ip l s veth2 up# veth0 ping veth2 [root@localhost ~] # ip netns exec ns1 ping 10.1.1.3PING 10.1.1.3 (10.1.1.3) 56 (84) bytes of data.64 bytes from 10.1.1.3: icmp_seq=1 Ttl=64 time=0.311 ms64 bytes from 10.1.1.3: icmp_seq=2 ttl=64 time=0.087 Ms ^ C-10.1.1.3 ping statistics-2 packets transmitted 2 received, 0% packet loss, time 999msrtt min/avg/max/mdev = 0.087, 0.199, 0.311, 0.112 ms about the Linux virtual network device, veth-pair, what is useful, that's it. I hope the above content can be of some help to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.