Qual é a diferença entre tun / tap vs bridge + vnet vs macvtap? (Para virtualização KVM)


28

Acabei de encontrar várias maneiras diferentes de criar redes KVM. Mas eu estou preso sobre o que é o caminho certo para fazê-lo. Descobri que o openstack usa o macvtap para criar redes de nêutrons. E parece bom.

Mas qual é a diferença e por que usar cada caminho.

Caminho 1 [VELHO? TUN / TAP]

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

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

Preterido, certo?

Caminho 2 [Bridge + Vnet] <- É isso que o virt-manager faz

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

Basicamente, você cria uma interface de ponte com sua interface física dentro e

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

E quando você inicia uma máquina virtual a partir do virt-manager, uma interface vnet é criada e adicionada à ponte. Pelo menos até onde eu sei. Nenhuma interface tun / tap é necessária.

Funcionou muito bem por um longo tempo, mas agora com atrevido eu encontrei problemas.

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

Por que você pode adicionar uma nova interface vnet à ponte sem a interface TAP?

Caminho 3 [MACVTAP]

Última é a interface macvtap.

http://virt.kernelnewbies.org/MacVTap

Ele copia a interface do software TUN / TAP, mas funciona de maneira melhor. Não sei de que maneira, mas parece ser melhor.

Qual é a vantagem do macvtap na segunda maneira?

O que é melhor?

Alguma ajuda nisso?

Respostas:


4

Realmente depende do que exatamente você deseja alcançar

  • TAP / TUN

Não importa se é VM ou máquina física. O TUN oferece uma rede em túnel e TAP em um dispositivo. Em resumo, você passa por uma rede encapsulada para alcançar outra rede.

Por exemplo, ao configurar uma rede OpenVPN, você recebe 10.8.0.6 no seu cliente. O servidor VPN 10.8.0.1 roteia sua solicitação para outra rede (por exemplo, 192.168.xx) por trás. Ao usar o TAP, você receberá um IP (192.168.10.10/24) diretamente da sua rede de destino (192.168.10.x / 24). Simples.

  • Ponte

O "Linux Bridge" conecta o VNET (da VM) à Ethernet física. Se você deseja uma VM (baseada em KVM), a ponte é obrigatória entre vnet e ethernet no host


MMmmm. Obrigado pela resposta, mas isso realmente não resolve minhas dúvidas. Se você vir os links, descobrirá que existem mais motivos para usar um ou outro. De fato, a ponte agora não está funcionando bem na pilha linux atual para vm. Então eu tive que usar o MACVTAP.
Gonzalo Aguilar Delgado

2

Eu diria que depende do seu caso de uso.

Adições / exclusões automatizadas de hosts virtuais?

Experimente o macvtap. Também deve ter um desempenho superior ao macvlan (que é mais ou menos como adicionar outro MAC a um dispositivo físico, as informações que chegam são manipuladas pela pilha de rede) ou uma ponte adicional, pois o macvtap ignora a pilha de rede de alguma forma e exporta diretamente um dispositivo de caractere de toque. Mas não me preste atenção nisso. Além de ambos (macvlan / macvtap) compartilharem os mesmos modos disponíveis (VEPA / hairpin, bridging, private), o hairpinning funcionará apenas se o seu switch suportar o modo de retransmissão reflexiva. (Os pacotes que chegam ao comutador físico na porta x devem ter permissão para deixar o comutador novamente na mesma porta x.)

Como o eth0 (ou o que você usar) é colocado no modo promíscuo ao usar uma ponte, diz-se que os modos macvXXX têm taxas de transferência mais altas.

Os modos também definem a 'quantidade' de isolamento (os fantasmas podem ver o tráfego um do outro? E quanto ao hv?). Ainda não sei como isso funciona.

Os veth (pares virtuais de ethernet) são um pouco semelhantes para isolamento, você define duas interfaces virtuais, uma é conectada a uma ponte e a outra à sua VM. Lá, o isolamento é feito colocando a interface vm em seu próprio espaço para nome, para que os dispositivos fiquem um pouco isolados. Todo o tráfego se reúne na ponte, mas um host não pode ver os vNICs de outro.

Caso você trabalhe com uma ponte, você terá uma configuração adicional a fazer e, quando a ponte estiver inoperante, todas as suas conexões também serão. Ao trazer a ponte de volta, talvez seja necessário reconectar todas as interfaces virtuais à ponte novamente (ou apenas reiniciar o hv completo ...).

Conclusão: se você não alterar sua topologia com frequência, basta usar a ponte, pois você encontra mais informações online on-line, o que é melhor do que ler o código do kernel. Heck, mesmo o pacote iproute2-doc não possui a maioria das informações que o iproute2 realmente possui, mesmo quando você executa versões de ponta. Tente descobrir sobre man ip-tcp_metricsas páginas de manual disponíveis ou ip-crefs.ps ...


Nem me lembro de escrever isso, muito menos de onde encontrei toda essa informação. :(
sjas

0

Esses métodos estão fazendo coisas fundamentalmente diferentes. Para entender o porquê, você precisa entender o modelo em camadas de rede. Para nossos propósitos aqui, as camadas 1, 2 e 3 são importantes:

  • A camada 1 é a camada física - especifica coisas como quais cabos você pode usar, quais padrões de tensão / corrente representam 1s e 0s nesse cabo, como os dispositivos em cada extremidade de um cabo negociam em qual taxa de bits eles operam etc.
  • A camada 2 é a camada de link - isso especifica o idioma em que cada extremidade de um cabo se comunica. Os dispositivos Ethernet nessa camada têm coisas como quadros e endereços MAC.
  • A camada 3 é a camada de rede - especifica como os dispositivos usam um link direto da camada 2 para outro dispositivo para alcançar um terceiro dispositivo que eles não podem alcançar diretamente na camada 2. Os dispositivos dessa camada têm endereços IP e tabelas de roteamento.

MACVLAN / MACVTAP

O MACVLAN cria um dispositivo de camada virtual 2 ou de camada de link, com seu próprio endereço MAC, que compartilha a camada 1 ou física com um dispositivo existente. O caso mais obviamente compreensível é quando você tem um dispositivo Ethernet conectado a uma rede e cria um dispositivo MACVLAN com base nesse dispositivo Ethernet; agora você tem dois "dispositivos" Ethernet com endereços MAC diferentes, mas que transmitem seus quadros no mesmo cabo. Vou falar um pouco mais sobre o MACVTAP.

As interfaces MACVLAN podem interagir de várias maneiras diferentes com a interface Ethernet existente, principalmente quando um quadro aparece em uma das interfaces que é endereçada à outra:

  • No modo privado , o quadro é jogado fora; não é possível que as duas interfaces se comuniquem entre si, apenas com dispositivos externos.
  • No modo vepa , o quadro é enviado sobre a camada física como qualquer outro quadro. Se você tiver o dispositivo conectado a um comutador inteligente o suficiente para detectar que o quadro precisa ser enviado de volta pela mesma porta em que chegou, ele será recebido pela mesma camada física que o enviou e a camada 2 será use o MAC para enviá-lo para a interface de rede pretendida.
  • No modo de ponte , quando um quadro aparece em um dispositivo, ele é verificado para ver se é destinado ao outro e, se for o caso, é enviado para lá sem passar pela camada 1.
  • Existem também alguns modos mais obscuros.

Observe que as interfaces MACVLAN têm uma restrição importante: elas não são capazes de aprender sobre endereços. Portanto, você não pode conectar uma interface MACVLAN a um segundo dispositivo físico e espera poder alcançar esse segundo dispositivo físico pelo primeiro. Isso funciona com a interface Ethernet original, mas não com uma interface MACVLAN conectada a ela.

TUN / TAP

Uma interface TAP também é um novo dispositivo virtual da camada 2, mas sem a camada 1 anexada. Em vez disso, um programa pode obter um descritor de arquivo representando a camada física. Ele pode gravar dados brutos do quadro Ethernet nesse descritor de arquivo e o kernel os tratará como qualquer outro pacote Ethernet que receber em uma interface física real.

O grande problema das interfaces TAP é que a camada física está no modo de usuário; qualquer software com as permissões apropriadas pode gerar quadros Ethernet da maneira que desejar e transformá-los em algo que o kernel trata da mesma forma que uma interface física real. Isso os torna muito úteis para coisas como VPNs e encapsulamento; você pode escrever qualquer tipo de software de encapsulamento que desejar no espaço do usuário e não há necessidade de se intrometer no espaço do kernel para colocar os quadros na pilha de rede, basta criar um dispositivo TAP e gravar os quadros no seu descritor de arquivo.

Os dispositivos TUN são exatamente como os dispositivos TAP, exceto que operam na camada 3, em vez da camada 2, e o software no modo de usuário precisa gravar pacotes IP brutos no descritor de arquivo em vez de quadros Ethernet brutos.

Voltando aos dispositivos MACVTAP , essas são uma espécie de confusão entre as interfaces MACVLAN e TAP. Como as interfaces TAP, um programa no modo usuário pode obter um descritor de arquivo e gravar quadros Ethernet brutos nele. Como uma interface MACVLAN, esses quadros são enviados pela camada física de um dispositivo Ethernet real. Isso permite que você adapte facilmente o software que foi escrito para usar dispositivos TAP para usar um dispositivo MACVLAN.

VNet

Isso é conceitualmente semelhante à rede TUN / TAP, mas possui um plano de controle mais desenvolvido (para que o software no modo usuário possa configurar a interface com mais flexibilidade) e um plano de dados mais otimizado (para que você possa mover mais os dados pelo dispositivo de rede virtual) eficientemente).

Tudo isso faz coisas semelhantes, mas tem recursos ligeiramente diferentes. Todos eles podem ser usados ​​para conectar uma VM a uma rede Ethernet:

  • Um produto de virtualização pode pegar quadros Ethernet do convidado e gravá-los no descritor de arquivo para um dispositivo TAP. Esse dispositivo TAP pode receber seu próprio endereço IP pelo host, ou pode escravizar uma ponte junto com uma interface Ethernet para compartilhar o endereço IP do host, ou as tabelas de ip podem ser configuradas para encaminhar o tráfego usando NAT.
  • Um produto de virtualização pode que os quadros Ethernet do convidado e os gravem no descritor de arquivo para um dispositivo MACVTAP; estes são transmitidos diretamente na camada física de um dispositivo Ethernet, efetivamente dando à VM um dispositivo Ethernet "real" (embora observe que é possível criar dispositivos MACVLAN / MACVTAP para outros tipos de interfaces de rede, como pontes).
  • Um produto de virtualização pode conectar um driver virtio no convidado ao driver virtio no host para uma rede muito eficiente.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.