¿Cuál es la diferencia entre tun / tap vs bridge + vnet vs macvtap? (Para virtualización KVM)

28

Acabo de encontrar muchas formas diferentes de hacer redes KVM. Pero estoy atascado sobre cuál es la forma correcta de hacerlo. Descubrí que openstack usa macvtap para hacer redes de neutrones. Y se ve bien.

Pero, ¿cuál es la diferencia y por qué usar en cada sentido?

Camino 1 [¿ANTIGUO? TUN / TAP]

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

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

En desuso, ¿verdad?

Camino 2 [Bridge + Vnet] <- Eso es lo que hace virt-manager

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

Básicamente, crea una interfaz de puente con su interfaz física dentro y

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

Y cuando inicia una máquina virtual desde virt-manager, se crea una interfaz vnet y se agrega al puente. Al menos hasta donde yo sepa. No se necesita una interfaz tun / tap.

Funcionó bastante bien durante mucho tiempo, pero ahora con picardía he encontrado problemas.

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

¿Por qué puede agregar una nueva interfaz vnet al puente sin la interfaz TAP?

Camino 3 [MACVTAP]

El último es la interfaz macvtap.

http://virt.kernelnewbies.org/MacVTap

Copia la interfaz del software TUN / TAP pero lo hace de una mejor manera. No sé de qué manera, pero parece ser mejor.

¿Cuál es la ventaja de macvtap sobre la segunda forma?

¿Que es mejor?

¿Alguna ayuda en esto?

Gonzalo Aguilar Delgado
fuente

Respuestas:

4

Realmente depende de qué es exactamente lo que quieres lograr

  • TAP / TUN

No importa si es VM o máquina física. TUN le ofrece una red tunelizada y TAP un dispositivo. En resumen, atraviesas una red tunelizada para llegar a otra red.

Por ejemplo, al configurar una red OpenVPN, se le dará 10.8.0.6 en su cliente. El servidor VPN 10.8.0.1 enruta su solicitud a otra red (por ejemplo, 192.168.xx) detrás. Al usar TAP, recibiría una IP (192.168.10.10/24) directamente de su red de destino (192.168.10.x / 24). Simple.

  • Puente

"Linux Bridge" une VNET (desde VM) a ethernet físico. Si desea una VM (basada en KVM), el puente es imprescindible entre vnet y ethernet en el host

j3ffyang
fuente
Mmmmm. Gracias por la respuesta, pero realmente no resuelve mis dudas. Si ve los enlaces, encontrará que hay más razones para usar uno u otro. De hecho, el puente ahora no funciona bien en la pila Linux actual para VM. Así que tuve que usar MACVTAP.
Gonzalo Aguilar Delgado
2

Yo diría que depende de tu caso de uso.

Agrega / elimina automatizado de hosts virtuales?

Prueba macvtap. También debe ser más efectivo que macvlan (que es más o menos como agregar otro MAC a un dispositivo físico, la información que llega allí es manejada por la pila de red) o un puente adicional, ya que macvtap omite la pila de red de alguna manera y exporta un dispositivo de caracteres de tap directamente. Pero no me claves en eso. Además de que ambos (macvlan / macvtap) comparten los mismos modos disponibles (VEPA / horquilla, puente, privado), la horquilla solo funciona si su interruptor admite el modo de relé reflectante. (Se debe permitir que los paquetes que lleguen al conmutador físico en el puerto x salgan del conmutador nuevamente en el mismo puerto x).

Debido a que eth0 (o el que use) se pone en modo promiscuo cuando se usa un puente, se dice que los modos macvXXX tienen mayores rendimientos.

Los modos también definen la 'cantidad' de aislamiento (¿pueden los vhosts ver el tráfico de los demás? ¿Qué tal el hv?). Cómo funciona esto bajo el capó aún no lo sé.

los veth (pares virtuales de ethernet) son algo similares para el aislamiento, usted define dos interfaces virtuales, una se conecta a un puente y la otra a su VM. Allí el aislamiento se realiza poniendo la interfaz vm en su propio espacio de nombres para que los dispositivos estén algo aislados. Todo el tráfico se junta en el puente, pero un vhost no puede ver las vNIC de otro.

En caso de que trabaje con un puente, tiene que hacer una configuración adicional, y cuando el puente está caído, también lo están todas sus conexiones. Al volver a activar el puente, es posible que deba volver a conectar todas las interfaces virtuales al puente (o simplemente reiniciar el hv completo ...).

En pocas palabras: si no cambia su topología con frecuencia, simplemente realice un puente ya que encontrará la mayor cantidad de información en línea, lo cual es mejor que leer el código del kernel. Diablos, incluso el paquete iproute2-doc en sí mismo carece de la mayor parte de la información que iproute2 realmente tiene, incluso cuando ejecuta versiones de última generación. Intente averiguar sobre man ip-tcp_metricslas páginas de manual disponibles o ip-crefs.ps ...

sjas
fuente
Ni siquiera recuerdo escribir esto, mucho menos donde encontré toda esa información. :(
sjas
0

Estos métodos están haciendo cosas fundamentalmente diferentes. Para comprender por qué, debe comprender el modelo de redes en capas. Para nuestros propósitos aquí, las capas 1, 2 y 3 son importantes:

  • La capa 1 es la capa física: esto especifica cosas como qué cables puede usar, qué patrones de voltaje / corriente representan 1s y 0s en ese cable, cómo los dispositivos en cada extremo de un cable negocian a qué velocidad de bits operan, etc.
  • La capa 2 es la capa de enlace: esto especifica en qué idioma se comunican las cosas en cada extremo de un cable. Los dispositivos Ethernet en esta capa tienen elementos como marcos y direcciones MAC.
  • La capa 3 es la capa de red: esto especifica cómo los dispositivos usan un enlace directo de la capa 2 a otro dispositivo para llegar a un tercer dispositivo que no pueden alcanzar directamente en la capa 2. Los dispositivos en esta capa tienen direcciones IP y tablas de enrutamiento.

MACVLAN / MACVTAP

MACVLAN crea una capa virtual 2 o dispositivo de capa de enlace, con su propia dirección MAC, que comparte la capa 1 o capa física con un dispositivo existente. El caso más obviamente comprensible es cuando tiene un dispositivo Ethernet conectado a una red y crea un dispositivo MACVLAN basado en ese dispositivo Ethernet; ahora tiene dos "dispositivos" Ethernet con diferentes direcciones MAC pero que transmiten sus tramas en el mismo cable. Hablaré sobre MACVTAP un poco más abajo.

Las interfaces MACVLAN pueden interactuar de varias maneras diferentes con la interfaz Ethernet existente, en particular cuando aparece una trama en una de las interfaces que se dirige a la otra:

  • En modo privado , el marco se tira; No es posible que las dos interfaces se comuniquen entre sí, solo con dispositivos externos.
  • En modo vepa , el cuadro se envía a través de la capa física como cualquier otro cuadro. Si tiene el dispositivo conectado a un conmutador que es lo suficientemente inteligente como para detectar que la trama debe enviarse de vuelta al mismo puerto en el que llegó, entonces será recibida por la misma capa física que la envió y luego la capa 2 use el MAC para enviarlo a la interfaz de red deseada.
  • En modo puente , cuando aparece un marco en un dispositivo, se verifica para ver si está destinado al otro y, de ser así, se envía allí sin pasar por la capa 1.
  • También hay un par de modos más oscuros.

Tenga en cuenta que las interfaces MACVLAN tienen una restricción importante: no son capaces de abordar el aprendizaje. Por lo tanto, no puede conectar una interfaz MACVLAN a un segundo dispositivo físico y esperar poder alcanzar ese segundo dispositivo físico sobre el primero. Esto funciona con la interfaz Ethernet original pero no con una interfaz MACVLAN conectada a ella.

TUN / TAP

Una interfaz TAP también es un nuevo dispositivo virtual de capa 2 pero sin capa 1 adjunta. En cambio, un programa puede obtener un descriptor de archivo que representa la capa física. Luego puede escribir datos de trama Ethernet sin procesar en ese descriptor de archivo y el núcleo lo tratará como cualquier otro paquete Ethernet que reciba en una interfaz física real.

Lo importante de las interfaces TAP es que la capa física está en modo de usuario; cualquier bit de software con los permisos apropiados puede generar tramas Ethernet de la forma que desee y meterlas en algo que el núcleo trata de la misma manera que una interfaz física real. Esto los hace muy útiles para cosas como VPN y túneles; puede escribir cualquier tipo de software de tunelización que desee en el espacio del usuario y no es necesario entrometerse en el espacio del kernel para obtener los marcos en la pila de red, simplemente cree un dispositivo TAP y escriba los marcos en su descriptor de archivo.

Los dispositivos TUN son como los dispositivos TAP, excepto que operan en la capa 3 en lugar de la capa 2 y el software de modo de usuario tiene que escribir paquetes IP sin procesar en el descriptor de archivo en lugar de tramas Ethernet sin procesar.

Volviendo a los dispositivos MACVTAP , estos son una especie de confusión entre las interfaces MACVLAN y TAP. Al igual que las interfaces TAP, un programa en modo de usuario puede obtener un descriptor de archivo y escribir tramas Ethernet sin procesar en él. Al igual que una interfaz MACVLAN, esas tramas se envían a través de la capa física de un dispositivo Ethernet real. Esto le permite adaptar fácilmente el software que está escrito para usar dispositivos TAP para usar un dispositivo MACVLAN.

Red virtual

Esto es conceptualmente similar a las redes TUN / TAP, pero tiene un plano de control más desarrollado (por lo que el software en modo de usuario que lo utiliza puede configurar la interfaz de manera más flexible) y un plano de datos más optimizado (para que pueda mover datos a través del dispositivo de red virtual más eficientemente).

Todos estos hacen cosas similares pero tienen capacidades ligeramente diferentes. Todos ellos se pueden usar para conectar una VM a una red Ethernet:

  • Un producto de virtualización puede tomar tramas Ethernet del huésped y escribirlas en el descriptor de archivo para un dispositivo TAP. El host puede asignar a su dispositivo TAP su propia dirección IP, o puede ser esclavo de un puente junto con una interfaz Ethernet para compartir la dirección IP del host, o iptables puede configurarse para reenviar el tráfico en él utilizando NAT.
  • Un producto de virtualización puede que tramas Ethernet del invitado y escribirlas en el descriptor de archivo para un dispositivo MACVTAP; estos se transmiten directamente en la capa física de un dispositivo Ethernet, lo que le da a la VM un dispositivo Ethernet "real" (aunque tenga en cuenta que es posible crear dispositivos MACVLAN / MACVTAP para otros tipos de interfaces de red, como puentes).
  • Un producto de virtualización puede conectar un controlador virtio en el invitado al controlador virtio en el host para una red muy eficiente.
Tom
fuente