Enfrentamos uma situação parecida hoje no centos 6, uma atualização para o kernel mais recente corrige isso.
Estou tentando depurar um problema envolvendo uma instância de máquina virtual KVM em que a instância não responde a solicitações de rede quando a origem está em outra máquina física, que está na mesma sub-rede que a instância de máquina virtual conectada via Linux ponte.
(Isso está acontecendo no contexto de uma implementação do OpenStack, edição Folsom, no Ubuntu 12.04, configurado usando nova-rede para o modo FlatDHCP, não multi-host. Esse problema ocorre apenas com convidados do CentOS, não com convidados do Ubuntu). / p>
Quando eu fiz um tcpdump dentro do convidado do CentOS, descobri que os pacotes de entrada estão sendo marcados com "vlan 0". Por exemplo, se eu configurar manualmente um endereço IP de 10.40.0.5/16 dentro do convidado e, em seguida, fizer um "arping -i eth1 10.40.0.5" de outra máquina, com tcpdump eu vejo "vlan 0"
# tcpdump -i eth0 -XX -vv -e
14:29:29.907212 54:78:1a:86:50:c9 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 0, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.40.0.5 (Broadcast) tell 10.40.0.1, length 46
0x0000: ffff ffff ffff 5478 1a86 50c9 8100 0000 ......Tx..P.....
0x0010: 0806 0001 0800 0604 0001 5478 1a86 50c9 ..........Tx..P.
0x0020: 0a28 0001 ffff ffff ffff 0a28 0005 0000 .(.........(....
0x0030: 0000 0000 0000 0000 0000 0000 dac7 07ed ................
Se eu carregar o módulo 8021q, o convidado responderá à solicitação ARP corretamente, embora ele não responda adequadamente ao DHCP e os pacotes UDP resultantes sejam marcados como vlan 0.
Se eu fizer um tcpdump semelhante no host de computação do Ubuntu 12.04 na interface vnet1 que corresponde à máquina virtual, não vejo as tags vlan 0:
# tcpdump -i vnet1 -XX -vv -e
tcpdump: WARNING: vnet1: no IPv4 address assigned
tcpdump: listening on vnet1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:59:34.023145 54:78:1a:86:50:c9 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.40.0.5 (Broadcast) tell 10.40.0.1, length 46
0x0000: ffff ffff ffff 5478 1a86 50c9 0806 0001 ......Tx..P.....
0x0010: 0800 0604 0001 5478 1a86 50c9 0a28 0001 ......Tx..P..(..
0x0020: ffff ffff ffff 0a28 0005 0000 0000 0000 .......(........
0x0030: 0000 0000 0000 0000 dac7 07ed ............
Entre as duas máquinas físicas existe um switch Cisco Nexus 3000.
Edit: O switch é configurado com apenas uma vlan (vlan 1), que é a VLAN nativa. Todas as portas no switch estão no modo de acesso. Veja como é uma porta típica:
# show interface switchport
Name: Ethernet1/1
Switchport: Enabled
Switchport Monitor: Not enabled
Operational Mode: access
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: 1
Administrative private-vlan primary host-association: none
Administrative private-vlan secondary host-association: none
Administrative private-vlan primary mapping: none
Administrative private-vlan secondary mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Por que essas tags vlan 0 serão adicionadas aos quadros assim? Será que o switch está adicionando essas tags, mas o Ubuntu de alguma forma não as vê quando passa os frames para o guest do CentOS? Ou poderia ser o kernel do CentOS adicionando as tags aos frames recebidos? Se sim, por que isso aconteceria?
Enfrentamos uma situação parecida hoje no centos 6, uma atualização para o kernel mais recente corrige isso.