Cet article présente veth-pair et sa connectivité, ainsi que la connectivité entre deux espaces de noms.
Comme son nom l'indique , veth-pair est une paire d'interfaces de périphériques virtuels. Différentes des périphériques tap/tun, elles apparaissent toutes par paires. Une extrémité est connectée à la pile de protocoles et l'autre extrémité est connectée l'une à l'autre. Comme le montre la figure ci-dessous :
En raison de cette fonctionnalité, il agit souvent comme un pont pour connecter divers périphériques réseau virtuels. Un exemple typique est comme "entre deux espaces de noms". "Connexion entre", "Connexion entre Bridge et OVS", "Connexion entre conteneurs Docker", etc., pour construire une structure de réseau virtuel très complexe, comme OpenStack Neutron.
Nous attribuons des adresses IP à veth0 et veth1 dans la figure ci-dessus : 10.1.1.2 et 10.1.1.3 respectivement, puis pingons veth1 depuis veth0. Théoriquement, ils se trouvent sur le même segment de réseau et peuvent être pingés avec succès, mais le résultat est que le ping échoue.
Prenez le paquet et jetez un œil tcpdump -nnt -i veth0
root@ubuntu:~# tcpdump -nnt -i veth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on veth0, link-type EN10MB (Ethernet), capture size 262144 bytes ARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28 ARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28
Vous pouvez voir que puisque veth0 et veth1 sont sur le même segment de réseau et sont connectés pour la première fois, ARP le fera. être envoyé à l'avance, mais veth1 n'a pas répondu au paquet ARP.
Après vérification, cela est dû à certaines restrictions de configuration par défaut liées à ARP dans le noyau du système Ubuntu que j'utilise. Je dois modifier les éléments de configuration :
echo 1 > /proc/sys/net/ipv4/conf/veth1/accept_local echo 1 > /proc/sys/net/ipv4/conf/veth0/accept_local echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/veth0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/veth1/rp_filter
Il suffit de faire un nouveau ping après. que. .
root@ubuntu:~# ping -I veth0 10.1.1.3 -c 2 PING 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 ms 64 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 3008ms rtt min/avg/max/mdev = 0.047/0.072/0.113/0.025 ms
Nous sommes plus intéressés par ce processus de communication et pouvons capturer les paquets pour y jeter un œil.
Pour le port veth0 :
root@ubuntu:~# tcpdump -nnt -i veth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on veth0, link-type EN10MB (Ethernet), capture size 262144 bytes ARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28 ARP, Reply 10.1.1.3 is-at 5a:07:76:8e:fb:cd, length 28 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 1, length 64 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 2, length 64 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 3, length 64 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2244, seq 1, length 64
Pour le port veth1 :
root@ubuntu:~# tcpdump -nnt -i veth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes ARP, Request who-has 10.1.1.3 tell 10.1.1.2, length 28 ARP, Reply 10.1.1.3 is-at 5a:07:76:8e:fb:cd, length 28 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 1, length 64 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 2, length 64 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2189, seq 3, length 64 IP 10.1.1.2 > 10.1.1.3: ICMP echo request, id 2244, seq 1, length 64
Étrange, nous n'avons pas vu le paquet echo reply d'ICMP, alors comment est-ce possible tu cingles ?
En fait, ici echo reply utilise le port localback Si vous ne me croyez pas, prenez un sac et jetez un œil :
root@ubuntu:~# tcpdump -nnt -i lo tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes IP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 1, length 64 IP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 2, length 64 IP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 3, length 64 IP 10.1.1.3 > 10.1.1.2: ICMP echo reply, id 2244, seq 4, length 64
Pourquoi ?
Nous comprendrons si nous regardons l’ensemble du processus de communication.
echo request et l'envoie à la pile de protocoles via socket. ip route show table 0 pour vérifier). L'ensemble du processus est illustré dans la figure ci-dessous :
namespace est une fonctionnalité prise en charge par la version du noyau Linux 2.6.x et versions ultérieures, principalement utilisée pour l'isolation des ressources. Avec l'espace de noms, un système Linux peut abstraire plusieurs sous-systèmes réseau. Chaque sous-système possède son propre équipement réseau, sa pile de protocoles, etc., sans s'influencer mutuellement.
Que devons-nous faire si nous avons besoin de communiquer entre les espaces de noms ? La réponse est d'utiliser veth-pair comme pont ?
Selon la méthode et l'échelle de connexion, elle peut être divisée en « connexion directe », « connexion via Bridge » et « connexion via OVS ».
La connexion directe est le moyen le plus simple, comme indiqué ci-dessous, une paire de veth-pair connecte directement deux espaces de noms ensemble.
Configurer l'IP pour la paire veth et tester la connectivité :
# 创建 namespace ip netns a ns1 ip netns a ns2 # 创建一对 veth-pair veth0 veth1 ip l a veth0 type veth peer name veth1 # 将 veth0 veth1 分别加入两个 ns ip l s veth0 netns ns1 ip l s veth1 netns ns2 # 给两个 veth0 veth1 配上 IP 并启用 ip netns exec ns1 ip a a 10.1.1.2/24 dev veth0 ip netns exec ns1 ip l s veth0 up ip netns exec ns2 ip a a 10.1.1.3/24 dev veth1 ip netns exec ns2 ip l s veth1 up # 从 veth0 ping veth1 [root@localhost ~]# ip netns exec ns1 ping 10.1.1.3 PING 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 ms 64 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 14000ms rtt min/avg/max/mdev = 0.068/0.084/0.201/0.032 ms
Le pont Linux est équivalent à un Un commutateur peut transférer le trafic de deux espaces de noms. Voyons quel rôle y joue veth-pair.
Comme indiqué ci-dessous, deux paires de paires veth connectent deux espaces de noms au Bridge.
Configurez de la même manière l'IP pour la paire veth et testez sa connectivité :
# 首先创建 bridge br0 ip l a br0 type bridge ip l s br0 up # 然后创建两对 veth-pair ip l a veth0 type veth peer name br-veth0 ip l a veth1 type veth peer name br-veth1 # 分别将两对 veth-pair 加入两个 ns 和 br0 ip l s veth0 netns ns1 ip l s br-veth0 master br0 ip l s br-veth0 up ip l s veth1 netns ns2 ip l s br-veth1 master br0 ip l s br-veth1 up # 给两个 ns 中的 veth 配置 IP 并启用 ip netns exec ns1 ip a a 10.1.1.2/24 dev veth0 ip netns exec ns1 ip l s veth0 up ip netns exec ns2 ip a a 10.1.1.3/24 dev veth1 ip netns exec ns2 ip l s veth1 up # veth0 ping veth1 [root@localhost ~]# ip netns exec ns1 ping 10.1.1.3 PING 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 ms 64 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 999ms rtt min/avg/max/mdev = 0.060/0.082/0.105/0.024 ms
OVS est un Bridge open source tiers avec des fonctions plus puissantes que Linux Bridge Pour la même expérience, nous utilisons OVS pour voir quel est l'effet.
Comme indiqué ci-dessous :
Testez également la connectivité entre les deux espaces de noms :
# 用 ovs 提供的命令创建一个 ovs bridge ovs-vsctl add-br ovs-br # 创建两对 veth-pair ip l a veth0 type veth peer name ovs-veth0 ip l a veth1 type veth peer name ovs-veth1 # 将 veth-pair 两端分别加入到 ns 和 ovs bridge 中 ip l s veth0 netns ns1 ovs-vsctl add-port ovs-br ovs-veth0 ip l s ovs-veth0 up ip l s veth1 netns ns2 ovs-vsctl add-port ovs-br ovs-veth1 ip l s ovs-veth1 up # 给 ns 中的 veth 配置 IP 并启用 ip netns exec ns1 ip a a 10.1.1.2/24 dev veth0 ip netns exec ns1 ip l s veth0 up ip netns exec ns2 ip a a 10.1.1.3/24 dev veth1 ip netns exec ns2 ip l s veth1 up # veth0 ping veth1 [root@localhost ~]# ip netns exec ns1 ping 10.1.1.3 PING 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 ms 64 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 999ms rtt min/avg/max/mdev = 0.087/0.199/0.311/0.112 ms
veth-pair 在虚拟网络中充当着桥梁的角色，连接多种网络设备构成复杂的网络。
veth-pair 的三个经典实验，直接相连、通过 Bridge 相连和通过 OVS 相连。
http://www.opencloudblog.com/?p=66
https://segmentfault.com/a/1190000009251098
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
