Я пытаюсь отладить проблему, связанную с экземпляром виртуальной машины KVM, когда экземпляр не отвечает на сетевые запросы, когда источник находится на другой физической машине, которая находится в той же подсети, что и экземпляр виртуальной машины, подключенный через мост Linux.
(Это происходит в контексте развертывания OpenStack, редакция Folsom, в Ubuntu 12.04, настроенном с использованием nova-network для режима FlatDHCP, а не с несколькими хостами. Эта проблема возникает только с гостями CentOS, а не с гостями Ubuntu).
Когда я сделал tcpdump внутри гостевой системы CentOS, я обнаружил, что входящие пакеты помечаются тегом «vlan 0». Например, если я вручную настраиваю IP-адрес 10.40.0.5/16 внутри гостя, а затем выполняю «arping -i eth1 10.40.0.5» с другого компьютера, с помощью tcpdump я вижу «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 ................
Если я загружу модуль 8021q, гость ответит на запрос ARP должным образом, хотя он не будет должным образом отвечать на DHCP, и результирующие пакеты UDP будут помечены как vlan 0.
Если я сделаю аналогичный tcpdump на вычислительном узле Ubuntu 12.04 на интерфейсе vnet1, который соответствует виртуальной машине, я не увижу теги 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 ............
Между двумя физическими машинами находится коммутатор Cisco Nexus 3000.
Редактировать: Коммутатор настроен только с одним vlan (vlan 1), который является собственной VLAN. Все порты коммутатора находятся в режиме доступа. Вот как выглядит типичный порт:
# 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
Почему эти теги vlan 0 добавляются в такие кадры? Может быть, коммутатор добавляет эти теги, но Ubuntu почему-то не видит их, когда передает кадры гостевой системе CentOS? Или это могло быть ядро CentOS, добавляющее теги во входящие кадры? Если да, то почему это могло произойти?
Столкнувшись с аналогичной ситуацией сегодня на centos 6, обновление до последней версии ядра исправляет это.