Início / ubuntu / Perguntas / 1333453
Accepted
Doug Smythies
Asked: 2021-04-24 08:40:05 +0800 CST

Rede em ponte em pacotes endereçados por LAN KVM/Qemu descartados

  • 772

Resumo: Em uma configuração KVM/QEMU com ponte, os pacotes de rede destinados à VM convidada não chegam lá.

Configuração: O host é um servidor Ubuntu 20.04.2 LTS atualizado; O convidado é qualquer uma das 3 VMs, um servidor Ubuntu 16.04 muito antigo, um desktop Ubuntu 20.04 antigo e um desktop Ubuntu 21.04 novinho em folha. As primeiras 2 VMs estão sendo convertidas de não em ponte, NAT'd, e a 3ª foi criada especificando a rede em ponte. Em última análise, as VMs obterão seus endereços IP da LAN principal, via DHCP, mas por enquanto e para obter melhores informações de depuração, elas estão usando endereços IP estáticos.

A definição da ponte do host, /etc/netplan/01-netcfg.yaml, (esta é uma das muitas tentativas):

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
  bridges:
    br0:
#      interfaces: [ enp3s0 ]
      dhcp4: yes
#      dhcp6: no
#      link-local: [ ]
      interfaces:
        - enp3s0
#      parameters:
#        stp: true
#        forward-delay: 4

O material virtual, /etc/libvirt/qemu/networks/br0.xml:

<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit br0
or other application using the libvirt API.
-->

<network>
  <name>br0</name>
  <uuid>40a8752c-d074-4802-bae8-b0aef95d9c99</uuid>
  <forward mode='bridge'/>
  <bridge name='br0'/>
</network>

Notas: muitas versões de arquivos .xml de ponte foram testadas, incluindo nomes diferentes, e referências diferentes usam técnicas diferentes. O Ubuntu Serverguide faz referência a isso , que diz que o nome e o nome da ponte devem ser os mesmos, mas outras referências não os possuem. Uma vez que o arquivo bare foi criado com nano, estes comandos:

virsh net-define br0.xml
virsh net-autostart br0
virsh net-start br0

foram usados ​​para adicioná-lo e configurá-lo. A maneira padrão, NAT'd, foi desvinculada, do diretório de inicialização automática, para não ser. Eventualmente, foi indefinido. O resultado:

$ virsh net-list --all
 Name      State      Autostart   Persistent
----------------------------------------------
 br0       active     yes         yes

Neste ponto, não há nenhuma regra do iptables após a reinicialização. No entanto, as VMs não têm acesso à rede. Observe que algumas referências mencionam regras especiais do iptables e atributos especiais para o módulo br_netfilter, todos os quais foram testados. Esta questão já é longa o suficiente sem entrar em todos os detalhes das variações tentadas aqui.

Detalhes de depuração: Não importa a variante de configuração, o problema básico é sempre o mesmo, os pacotes destinados à VM parecem não chegar ao host, pelo menos como visto pelo tcpdump. No entanto, os pacotes do tipo broadcast chegam e chegam à VM cliente.

Este exemplo usará 192.168.111.59 (MAC: 52:54:00:60:ea:0e), a VM do servidor 16.04 e 192.168.111.132, um raspberry-pi, na LAN. O servidor host 20.04 está em 192.168.111.136. A máscara de rede é de 24 bits, 255.255.255.0. O gateway e servidor DHCP é um servidor Debian (no qual VMs convidadas em ponte funcionam bem, a propósito).

Primeiro tpcudmp visto do raspberry-pi durante o ping:

doug@rpi2:~ $ sudo tcpdump -n -tttt -i eth0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:33:19.363553 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:19.487239 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 14, length 64
2021-04-23 08:33:20.363542 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:20.527250 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 15, length 64
2021-04-23 08:33:21.567215 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 16, length 64
2021-04-23 08:33:22.607228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 17, length 64
2021-04-23 08:33:23.372351 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 08:33:23.647228 IP 192.168.111.132 > 192.168.111.59: ICMP echo request, id 27848, seq 18, length 64
2021-04-23 08:33:24.371431 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 46

Observe que a VM está enviando pacotes muito bem, conforme visto em toda a atividade ARP. No entanto, nunca responde a nada. Agora vamos observar a mesma atividade do host, observando que a saída do tcpdump é a mesma para qualquer uma das interfaces br0 ou enp3s0 ou vnet0.

$ sudo tcpdump -n -tttt -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 08:40:38.837608 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:39.837159 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:40.837122 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:43.842985 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:44.840895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:45.840991 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:48.848508 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:49.848895 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:50.848871 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:51.514011 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:52.928400 ARP, Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 08:40:53.853881 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-23 08:40:54.852472 ARP, Request who-has 192.168.111.1 tell 192.168.111.59, length 28

Observe que de vez em quando a VM responde, mas mais tarde veremos que é para um pacote de broadcast. Também parece que um problema é que 192.168.111.1 não está respondendo. É, e por qualquer motivo, que os pacotes não são vistos aqui no nível tcpdump. Observe também nenhum pacote ICMP do raspberry-pi. Agora, mostre o gateway respondendo (este é "br0" em um computador diferente. EDIT: substituído por um exemplo de captura melhor, daí os diferentes timestamps):

$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2021-04-23 22:25:17.434415 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:17.434432 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:20.440843 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:20.440859 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:21.438316 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:21.438332 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:22.438266 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:22.438283 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:25.446312 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:25.446329 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28
2021-04-23 22:25:26.446195 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-23 22:25:26.446211 xx:xx:xx:xx:xx:xx > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at xx:xx:xx:xx:xx:xx, length 28

Observe os pacotes de saída da VM e o ARP é concluído. Não consigo descobrir como copiar e colar da VM, com a qual me comunico via VNC, mas mostra algumas entradas ARP concluídas, mas obsoletas em resposta ao ip neighcomando e o tcpdump mostra alguns pacotes ARP e broadcast da LAN.

Outras informações (MACs não relevantes para esta pergunta foram ocultados):

$ brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.3c7c3f0d9983       no              enp3s0
                                                        vnet0
$ brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     xx:xx:xx:xx:xx:xx       no                 0.00
  1     3c:7c:3f:0d:99:83       yes                0.00
  1     3c:7c:3f:0d:99:83       yes                0.00
  2     52:54:00:60:ea:0e       no                 1.68
  1     xx:xx:xx:xx:xx:xx       no                 2.14
  1     xx:xx:xx:xx:xx:xx       no                36.84
  1     xx:xx:xx:xx:xx:xx       no                89.57
  1     xx:xx:xx:xx:xx:xx       no               226.51
  1     xx:xx:xx:xx:xx:xx       no                13.28
  1     xx:xx:xx:xx:xx:xx       no               165.68
  1     xx:xx:xx:xx:xx:xx       no               165.68
  1     xx:xx:xx:xx:xx:xx       no               265.02
  1     xx:xx:xx:xx:xx:xx       no                27.62
  2     fe:54:00:60:ea:0e       yes                0.00
  2     fe:54:00:60:ea:0e       yes                0.00

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:7c:3f:0d:99:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.136/24 brd 192.168.111.255 scope global dynamic br0
       valid_lft 51547sec preferred_lft 51547sec
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:60:ea:0e brd ff:ff:ff:ff:ff:ff

EDIT: curiosamente, todos os pacotes ARP do meu Roteador Gigabit Wi-Fi D-Link AC2600, configurado como um switch, sempre aparecem no host e chegam à VM e são respondidos:

$ sudo tcpdump -n -tttt -e -i br0 ether host aa:aa:aa:aa:aa:aa
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-23 22:45:51.463524 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:45:51.463631 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:46:51.466955 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:46:51.467030 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:47:51.466889 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:47:51.466965 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28
2021-04-23 22:48:51.479096 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.59 (ff:ff:ff:ff:ff:ff) tell 192.168.111.58, length 46
2021-04-23 22:48:51.479178 52:54:00:60:ea:0e > aa:aa:aa:aa:aa:aa, ethertype ARP (0x0806), length 42: Reply 192.168.111.59 is-at 52:54:00:60:ea:0e, length 28

EDIT 3 - Novo teste de configuração: Na tentativa de reduzir o número de variáveis ​​foi feito o seguinte:

  • Um servidor Ubuntu 16.04 prestes a ser aposentado foi ligado, fornecendo uma nova LAN isolada.
  • o servidor host Ubuntu 20.04 foi conectado diretamente à NIC do lado da LAN do servidor 16.04. Nenhum switch estava envolvido, apenas um longo cabo Ethernet.
  • As coisas foram testadas e pareciam funcionar bem. O acesso a tudo era via ssh da minha LAN principal através do meu IP estático principal da WAN e de volta através do meu IP estático da WAN de teste para o antigo servidor 16.04. Em seguida, uma sessão ssh encadeada de lá para o servidor host 20.04.
  • O cliente VM Ubuntu 16.04 foi iniciado no host.
  • "ping" foi tentado do antigo servidor de gateway 16.04 para o cliente.
  • Os resultados foram os mesmos da configuração original.

tcpdump no servidor 16.04 antigo do gateway:

doug@DOUG-64:~$ sudo tcpdump -n -tttt -e -i enp2s0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:10:00.701941 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:00.701965 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:01.699156 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:01.699169 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:02.699141 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:02.699154 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:05.707404 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:05.707417 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:06.707097 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:06.707110 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28
2021-04-26 15:10:07.707094 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.111.1 tell 192.168.111.59, length 46
2021-04-26 15:10:07.707107 00:19:b9:0d:af:fa > 52:54:00:60:ea:0e, ethertype ARP (0x0806), length 42: Reply 192.168.111.1 is-at 00:19:b9:0d:af:fa, length 28

tcpdump no servidor host 20.04:

doug@s19:~$ sudo tcpdump -n -tttt -e -i br0 ether host 52:54:00:60:ea:0e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-04-26 15:11:35.801771 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:36.800497 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:37.800491 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:40.807062 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:41.804469 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:42.804444 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:45.812553 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:46.812405 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28
2021-04-26 15:11:47.812398 52:54:00:60:ea:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.111.1 tell 192.168.111.59, length 28

Como uma observação lateral: da minha sessão ssh encadeada para o servidor host 20.04, posso encadear novamente e ssh para o cliente VM muito bem.

Conclusão: Algo está errado na camada de link no servidor Ubuntu 20.04, de modo que os pacotes recebidos nem são "vistos" pelo tcpdump, nem chegam ao convidado da VM. Diagrama .

EDIT 4: Comparando com as informações fornecidas por Christian Ehrhardt, uma diferença potencial no meu sistema é que a lista br0 MAC pode estar incorreta, com o primeiro byte substituído. Nota: MAC não relevante excluído, 3 VMs em execução:

doug@s19:~$ brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     3c:7c:3f:0d:99:83       yes                0.00  <<< enp3s0, br0
  1     3c:7c:3f:0d:99:83       yes                0.00  <<< enp3s0, br0
  4     52:54:00:22:2f:dc       no                 5.15  <<< VM 3
  2     52:54:00:60:ea:0e       no                 3.29  <<< VM 1
  3     52:54:00:60:ea:3e       no                12.67  <<< VM 2
  4     fe:54:00:22:2f:dc       yes                0.00  <<< vnet2
  4     fe:54:00:22:2f:dc       yes                0.00  <<< vnet2
  2     fe:54:00:60:ea:0e       yes                0.00  <<< vnet0
  2     fe:54:00:60:ea:0e       yes                0.00  <<< vnet0
  3     fe:54:00:60:ea:3e       yes                0.00  <<< vnet1
  3     fe:54:00:60:ea:3e       yes                0.00  <<< vnet1

Por alguma razão Christian não mostra uma vnet, ou seja lá o que for chamado em seu sistema, conexão com a ponte (não sei se é relevante ou não):

$ brctl showmacs br0
port no mac addr        is local?   ageing timer
  2 52:54:00:48:40:69   no         2.36   <- Guest
  1 52:54:00:95:e4:2a   no         0.00   <- outside system
  1 52:54:00:9b:9b:0e   yes        0.00   <- Host
  1 52:54:00:9b:9b:0e   yes        0.00   <- Host

EDIT 5: Dados semelhantes ao EDIT 4, mas do Debian Server com 2 VMs em execução, que está funcionando corretamente:

doug@s15:~$ sudo brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     52:54:00:22:2f:dc       no                17.85
  2     52:54:00:27:1b:5e       no                18.48  <<< VM 1
  3     52:54:00:27:1b:ae       no                 2.14  <<< VM 2
  1     f4:8c:eb:c8:08:a0       no                18.48
  2     fe:71:fa:75:16:93       yes                0.00  <<< tap0 (VM1)
  2     fe:71:fa:75:16:93       yes                0.00  <<< tap0
  3     fe:e1:c5:2a:c7:e3       yes                0.00  <<< tap1 (VM2)
  3     fe:e1:c5:2a:c7:e3       yes                0.00  <<< tap1

EDIT 6: informações de networkctl, o que deve ser observado é que o servidor Debian mostra "Master: br0", enquanto o servidor Ubuntu não:

Ubuntu:

doug@s19:~$ networkctl
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp3s0 ether    enslaved    configured
  3 br0    bridge   routable    configured
  4 vnet0  ether    carrier     unmanaged

4 links listed.
doug@s19:~$ man networkctl
doug@s19:~$ networkctl^Cnetworkctl
doug@s19:~$ networkctl status vnet0
● 4: vnet0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: n/a
                  Type: ether
                 State: carrier (unmanaged)
                Driver: tun
            HW Address: fe:54:00:60:ea:0e
                   MTU: 1500 (min: 68, max: 65521)
  Queue Length (Tx/Rx): 1/1
      Auto negotiation: no
                 Speed: 10Mbps
                Duplex: full
                  Port: tp

Apr 30 07:40:51 s19 systemd-networkd[530]: vnet0: Link UP
Apr 30 07:40:51 s19 systemd-networkd[530]: vnet0: Gained carrier

Debian:

doug@s15:~$ networkctl
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp3s0 ether    enslaved    configured
  3 enp1s0 ether    routable    configured
  4 br0    bridge   routable    configured
 10 tap0   ether    carrier     unmanaged

5 links listed.
doug@s15:~$ networkctl status tap0
● 10: tap0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: n/a
                  Type: ether
                 State: carrier (unmanaged)
                Driver: tun
            HW Address: fe:8a:6a:ce:18:9c
                   MTU: 1500 (min: 68, max: 65521)
                 QDisc: pfifo_fast
                Master: br0   <<<<< Different than Ubuntu
  Queue Length (Tx/Rx): 1/1
      Auto negotiation: no
                 Speed: 10Mbps
                Duplex: full
                  Port: tp

Pergunta: O que está errado e como posso fazer com que as VMs em ponte funcionem corretamente?

networking

2 respostas

  1. Temos o mesmo problema de ponte kvm vlan no PowerEdge R740 e Broadcomm 10GB NIC. O que encontramos são

    　　Broadcom Adv. Ethernet dupla de 10 Gb 21.65.33.33 e kernel 5.4 -> ruim
　　Broadcom Adv. Ethernet dupla de 10 Gb 21.65.33.33 e kernel 5.5 -> bom
　　Broadcom Adv. Ethernet dupla de 10 Gb 21.80.16.95 e kernel 5.5 -> ruim
　　Broadcom Adv. Ethernet dupla de 10 Gb 21.80.16.95 e kernel 5.12 -> ruim

    No entanto, a reversão do firmware não funcionará, portanto, tenha cuidado.

    • 2
  2. Best Answer

    O problema era o núcleo. O servidor host 20.04 não está usando a pilha HWE e, portanto, o kernel atual é 5.4.0.72.

    No entanto, tudo funciona bem com todos os kernels testados a partir do mainline 5.5-rc1 e superior, incluindo 5.12-rc6 (ainda não consegui instalar o 5.12). Alguns kernels mais antigos da série 5.4 também foram testados, incluindo as linhas principais 5.4.0 e 5.4.117 e todos falharam.

    Parece que a bissecção do kernel não funciona ao contrário, ou seja, quando o kernel bom está atrás do kernel ruim. No entanto, se alguém apenas inverte a definição de bom e ruim, então talvez. Referência .

    EDIT 1: Este servidor 20.04 precisa da pilha HWE, porque o hardware é novo para o kernel da série 5.4. Não consegui dividir o kernel, pois havia muitos git bisect skips necessários, pois muitos kernels não inicializavam ou nem compilavam. Essa coisa toda foi uma colossal perda de tempo.

    • 1

relate perguntas