Quelle est la différence entre tun / tap vs bridge + vnet vs macvtap? (Pour la virtualisation KVM)


28

Je viens de découvrir de nombreuses façons différentes de mettre en réseau KVM. Mais je ne sais pas quelle est la bonne façon de le faire. J'ai découvert que openstack utilise macvtap pour faire du réseautage neutronique. Et ça a l'air bien.

Mais quelle est la différence et pourquoi utiliser dans chaque sens.

Voie 1 [VIEUX? TUN / TAP]

http://www.shakthimaan.com/installs/debian-tun-tap-setup.html

/--------\   /----\   /----\   /----\   /--------\
|Internet|---|eth0|---|br0 |---|tap0|---|Guest NIC
\--------/   \----/   \----/   \----/   \--------/

Obsolète, non?

Way 2 [Bridge + Vnet] <- C'est ce que fait virt-manager

http://www.linux-kvm.com/content/using-bridged-networking-virt-manager

Fondamentalement, vous créez une interface de pont avec votre interface physique à l'intérieur et

auto br0
#iface br0 inet dhcp
iface br0 inet static
address 172.16.0.100
network 172.16.0.0
netmask 255.255.0.0
broadcast 172.16.255.255
gateway 172.16.0.1
   bridge_ports eth2
   bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

Et lorsque vous démarrez une machine virtuelle à partir de virt-manager, une interface vnet est créée et ajoutée au pont. Du moins jusqu'à ce que je sache. Aucune interface tun / tap n'est nécessaire.

Cela a très bien fonctionné pendant une longue période, mais maintenant, avec des notes impertinentes, j'ai trouvé des problèmes.

https://bugs.launchpad.net/ubuntu/+source/core-network/+bug/1255516

Pourquoi pouvez-vous ajouter une nouvelle interface vnet au pont sans l'interface TAP?

Voie 3 [MACVTAP]

Le dernier est l'interface macvtap.

http://virt.kernelnewbies.org/MacVTap

Il copie l'interface du logiciel TUN / TAP mais il le fait d'une meilleure façon. Je ne sais pas comment, mais ça semble être mieux.

Quel est l'avantage de macvtap par rapport à la deuxième méthode?

Ce qui est mieux?

Une aide à ce sujet?

Réponses:


4

Cela dépend vraiment de ce que vous voulez atteindre

  • TAP / TUN

Peu importe que ce soit une machine virtuelle ou une machine physique. TUN vous apporte un réseau tunnelé et TAP un appareil. En bref, vous passez par un réseau tunnelé pour atteindre un autre réseau.

Par exemple, lors de la configuration d'un réseau OpenVPN, vous recevrez le 10.8.0.6 sur votre client. Le serveur VPN 10.8.0.1 achemine votre demande vers un autre réseau (par exemple 192.168.xx) derrière. Lorsque vous utilisez TAP, vous recevrez une IP (192.168.10.10/24) directement de votre réseau cible (192.168.10.x / 24). Simple.

  • Pont

"Linux Bridge" relie VNET (de VM) à Ethernet physique. Si vous voulez une VM (basée sur KVM), le pont est un must entre vnet et ethernet sur l'hôte


MMmmm. Merci pour la réponse, mais cela ne résout vraiment pas mes doutes. Si vous voyez les liens, vous constaterez qu'il y a plus de raisons d'utiliser l'un ou l'autre. En fait, le pontage ne fonctionne plus correctement sur la pile Linux actuelle pour vm. J'ai donc dû utiliser MACVTAP.
Gonzalo Aguilar Delgado

2

Je dirais que cela dépend de votre cas d'utilisation.

Ajout / suppression automatisés d'hôtes virtuels?

Essayez macvtap. Devrait également être plus performant que macvlan (ce qui revient à peu près à ajouter un autre MAC à un périphérique physique, les informations qui y arrivent sont gérées par la pile réseau) ou un pont supplémentaire, car macvtap contourne la pile réseau d'une manière ou d'une autre et exporte directement un périphérique à caractère tactile. Mais ne me clouez pas là-dessus. En outre, les deux (macvlan / macvtap) partagent les mêmes modes disponibles (VEPA / épingle à cheveux, pontage, privé), l'épingle à cheveux ne fonctionne que si votre commutateur prend en charge le mode relais réfléchissant. (Les paquets arrivant au commutateur physique sur le port x doivent être autorisés à quitter le commutateur à nouveau sur le même port x.)

Étant donné que le eth0 (ou celui que vous utilisez) est mis en mode promiscuous lors de l'utilisation d'un pont, les modes macvXXX auraient des débits plus élevés.

Les modes définissent également la «quantité» d'isolement (les vhosts peuvent-ils voir le trafic les uns des autres? Que diriez-vous du hv?). Comment cela fonctionne sous le capot, je ne sais pas encore.

Les veth (paires Ethernet virtuelles) sont quelque peu similaires pour l'isolement, vous définissez deux interfaces virtuelles, l'une est attachée à un pont, l'autre à votre VM. Là, l'isolement se fait en plaçant l'interface vm dans son propre espace de noms afin que les périphériques soient quelque peu isolés. Tout le trafic se rassemble au pont, mais un vhost ne peut pas voir les vNIC d'un autre.

Dans le cas où vous travaillez avec un pont, vous avez une configuration supplémentaire à faire, et lorsque le pont est en panne, il en va de même pour toutes vos connexions. Lorsque vous remettez le pont en place, vous devrez peut-être reconnecter toutes les interfaces virtuelles au pont (ou simplement redémarrer le HV complet ...).

Bottom line: Si vous ne changez pas souvent votre topologie, optez simplement pour le pontage car vous trouvez le plus d'informations en ligne, ce qui est mieux que de lire le code du noyau. Heck, même le package iproute2-doc lui-même manque la plupart des informations dont iproute2 dispose réellement, même lorsque vous exécutez des versions de pointe. Essayez de vous renseigner sur man ip-tcp_metricsles pages de manuel disponibles ou sur ip-crefs.ps ...


Je ne me souviens même pas d'avoir écrit cela, encore moins où j'ai trouvé toutes ces informations. :(
sjas

0

Ces méthodes font des choses fondamentalement différentes. Pour comprendre pourquoi, vous devez comprendre le modèle de réseautage en couches. Pour nos besoins ici, les couches 1, 2 et 3 sont importantes:

  • La couche 1 est la couche physique - elle spécifie des éléments tels que les câbles que vous pouvez utiliser, quels modèles de tension / courant représentent 1 et 0 sur ce câble, comment les périphériques à chaque extrémité d'un câble négocient le débit binaire sur lequel ils fonctionnent, etc.
  • La couche 2 est la couche de liaison - elle spécifie quelle langue les choses à chaque extrémité d'un câble se parlent. Les périphériques Ethernet de cette couche ont des éléments tels que des trames et des adresses MAC.
  • La couche 3 est la couche réseau - elle spécifie comment les appareils utilisent un lien direct de la couche 2 vers un autre appareil pour atteindre un troisième appareil qu'ils ne peuvent pas atteindre directement à la couche 2. Les appareils de cette couche ont des adresses IP et des tables de routage.

MACVLAN / MACVTAP

MACVLAN crée un périphérique virtuel de couche 2 ou de couche liaison, avec sa propre adresse MAC, qui partage la couche 1 ou la couche physique avec un périphérique existant. Le cas le plus compréhensible est celui où vous avez un périphérique Ethernet branché sur un réseau et où vous créez un périphérique MACVLAN basé sur ce périphérique Ethernet; vous avez maintenant deux "périphériques" Ethernet avec des adresses MAC différentes mais qui transmettent tous les deux leurs trames sur le même câble. Je parlerai de MACVTAP un peu plus loin.

Les interfaces MACVLAN peuvent interagir de plusieurs manières différentes avec l'interface Ethernet existante, notamment lorsqu'une trame apparaît sur l'une des interfaces qui est adressée à l'autre:

  • En mode privé , le cadre est jeté; il n'est pas possible que les deux interfaces communiquent entre elles, uniquement avec des appareils externes.
  • En mode vepa , la trame est envoyée sur la couche physique comme n'importe quelle autre trame. Si vous avez branché l'appareil sur un commutateur suffisamment intelligent pour repérer que la trame doit ensuite être renvoyée sur le même port sur lequel elle est arrivée, elle sera reçue par la même couche physique qui l'a envoyée, puis la couche 2 utilisez le MAC pour l'envoyer à l'interface réseau prévue.
  • En mode pont , lorsqu'une trame apparaît sur un appareil, elle est vérifiée pour voir si elle est destinée à l'autre et si oui, elle y est envoyée sans passer par la couche 1.
  • Il existe également quelques modes plus obscurs.

Notez que les interfaces MACVLAN ont une restriction importante: elles ne sont pas capables d'apprendre l'adresse. Vous ne pouvez donc pas relier une interface MACVLAN à un deuxième périphérique physique et vous attendre à pouvoir atteindre ce deuxième périphérique physique par-dessus le premier. Cela fonctionne avec l'interface Ethernet d'origine mais pas avec une interface MACVLAN qui lui est attachée.

TUN / TAP

Une interface TAP est également un nouveau périphérique virtuel de couche 2 mais sans couche 1 qui lui est attachée. Au lieu de cela, un programme peut obtenir un descripteur de fichier représentant la couche physique. Il peut ensuite écrire des données de trame Ethernet brutes dans ce descripteur de fichier et le noyau les traitera comme tout autre paquet Ethernet qu'il reçoit sur une véritable interface physique.

La grande chose au sujet des interfaces TAP est que la couche physique est en mode utilisateur; n'importe quel logiciel avec les autorisations appropriées peut générer des trames Ethernet comme bon lui semble et les insérer dans quelque chose que le noyau traite de la même manière qu'une véritable interface physique. Cela les rend très utiles pour des choses comme les VPN et le tunneling; vous pouvez écrire n'importe quel type de logiciel de tunneling que vous aimez dans l'espace utilisateur et il n'est pas nécessaire de se mêler de l'espace du noyau pour obtenir les trames dans la pile réseau, il vous suffit de créer un périphérique TAP et d'écrire les trames dans son descripteur de fichier.

Les périphériques TUN sont exactement comme les périphériques TAP, sauf qu'ils fonctionnent sur la couche 3 au lieu de la couche 2 et que le logiciel en mode utilisateur doit écrire des paquets IP bruts dans le descripteur de fichier au lieu de trames Ethernet brutes.

Pour en revenir aux périphériques MACVTAP , il s'agit d'une sorte de confusion entre les interfaces MACVLAN et TAP. Comme les interfaces TAP, un programme en mode utilisateur peut obtenir un descripteur de fichier et y écrire des trames Ethernet brutes. Comme une interface MACVLAN, ces trames sont ensuite envoyées sur la couche physique d'un véritable périphérique Ethernet. Cela vous permet d'adapter facilement un logiciel écrit pour utiliser des appareils TAP pour utiliser un appareil MACVLAN à la place.

VNet

Ceci est conceptuellement similaire à la mise en réseau TUN / TAP mais a un plan de contrôle plus développé (de sorte que le logiciel en mode utilisateur l'utilisant peut configurer l'interface de manière plus flexible) et un plan de données plus optimisé (afin que vous puissiez déplacer les données via le périphérique réseau virtuel plus efficacement).

Tous ces éléments font des choses similaires mais ont des capacités légèrement différentes. Tous peuvent être utilisés pour connecter une machine virtuelle à un réseau Ethernet:

  • Un produit de virtualisation peut prendre des trames Ethernet de l'invité et les écrire dans le descripteur de fichier pour un périphérique TAP. Ce périphérique TAP peut se voir attribuer sa propre adresse IP par l'hôte, ou il peut être asservi à un pont avec une interface Ethernet pour partager l'adresse IP de l'hôte, ou iptables peut être configuré pour transférer le trafic sur celui-ci à l'aide de NAT.
  • Un produit de virtualisation peut que les trames Ethernet de l'invité et les écrire dans le descripteur de fichier pour un périphérique MACVTAP; ceux-ci sont ensuite transmis directement sur la couche physique d'un périphérique Ethernet, ce qui donne à la machine virtuelle un «véritable» périphérique Ethernet (bien qu'il soit possible de créer des périphériques MACVLAN / MACVTAP pour d'autres types d'interfaces réseau telles que des ponts).
  • Un produit de virtualisation peut connecter un pilote virtio dans l'invité au pilote virtio dans l'hôte pour une mise en réseau très efficace.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.