LINUX.ORG.RU
ФорумAdmin

XEN. Гостевая не видит входящие пакеты пакеты на интерфейсе. Только из dom0 принимает.


0

0

Доброго вечера! Второй день не могу понять поведение гостевой.

развернут xen 4 версии:

dpkg --get-selections | grep xen
libxenstore3.0					install
linux-image-2.6.32-5-xen-amd64			install
linux-image-xen-amd64				install
xen-docs-4.0					install
xen-hypervisor-4.0-amd64			install
xen-qemu-dm-4.0					install
xen-tools					install
xen-utils-4.0					install
xen-utils-common				install
xenstore-utils					install

настроен бридж:

bridge name	bridge id		STP enabled	interfaces
xenbridge		8000.5404a6b49759	no		eth0
							                vif9.0
Интерфейсы:

eth0      Link encap:Ethernet  HWaddr 54:04:a6:b4:97:59  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:109423 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54348 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8969107 (8.5 MiB)  TX bytes:7743190 (7.3 MiB)
          Interrupt:207 Base address:0xc000 



vif9.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:944 errors:0 dropped:0 overruns:0 frame:0
          TX packets:50161 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:82081 (80.1 KiB)  TX bytes:3451568 (3.2 MiB)


xenbridge Link encap:Ethernet  HWaddr 54:04:a6:b4:97:59  
          inet addr:5.xx.xx.78  Bcast:5.xx.xx.95  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:55627 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53895 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4541839 (4.3 MiB)  TX bytes:7810736 (7.4 MiB)

Конфиг почти дефолтный:

cat /etc/xen/xend-config.sxp | grep -v '#'

(vif-script vif-bridge)
(dom0-min-mem 512)
(enable-dom0-ballooning yes)
(total_available_memory 0) 
(dom0-cpus 0)

Конфиг гостевой:

cat /etc/xen/domains/sample.cfg
name        = 'sample.ru'
kernel      = '/boot/vmlinuz-2.6.32-5-xen-amd64'
ramdisk     = '/boot/initrd.img-2.6.32-5-xen-amd64'
memory      = '2048'
vcpus         = 2
root        = '/dev/xvda1 ro'
disk        = [
    'phy:/dev/vg0/sample_root,xvda1,w',
    'phy:/dev/vg0/sample_swap,xvda2,w',
    ]
vif         = [ 'ip=5.xx.xx.70,bridge=xenbridge,mac=00:16:3f:4d:86:a1' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Запущено в dom0:

xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0 14952     8     r-----    229.5
sample.ru                                     9  2048     2     -b----     10.5

Захожу с dom0 в гостевую, как по ssh так и через консоль (hvc0). Файрволлы везде отключены. В гостевой: ifconfig -a

eth0      Link encap:Ethernet  HWaddr 00:16:3f:4d:86:a1  
          inet addr:5.xx.xx.70  Bcast:5.xx.xx.95  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:50172 errors:0 dropped:0 overruns:0 frame:0
          TX packets:944 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2749872 (2.6 MiB)  TX bytes:95297 (93.0 KiB)
          Interrupt:18 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0


route -n:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
5.xx.xx.64        0.0.0.0         255.255.255.224 U     0      0        0 eth0
0.0.0.0         5.xx.xx.65        0.0.0.0         UG    0      0        0 eth0

Из гостевой запускаю в одной консоли пинг на шлюз, в другой дампом на интерфейс наблюдаю: tcpdump -ni eth0 arp
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:59:42.659118 ARP, Request who-has 5.xx.xx.65 tell 5.xx.xx.70, length 28
22:59:42.660151 ARP, Reply 5.xx.xx.65 is-at 78:fe:3d:47:19:06, length 46
и так далее. Однако arp -na:
? (5.xx.xx.65) at <incomplete> on eth0
? (5.xx.xx.78) at 54:04:a6:b4:97:59 [ether] on eth0

И естественно:

PING 5.xx.xx.65 (5.xx.xx.65) 56(84) bytes of data.
From 5.xx.xx.70 icmp_seq=1 Destination Host Unreachable
From 5.xx.xx.70 icmp_seq=2 Destination Host Unreachable

Прописываю статик:

 arp -na
? (5.xx.xx.65) at 78:fe:3d:47:19:06 [ether] PERM on eth0
? (5.xx.xx.78) at 54:04:a6:b4:97:59 [ether] on eth0

Снова в гостевой запускаю ping, в другой консоли смотрю:

tcpdump -ni eth0 icmp
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

23:04:00.608555 IP 5.xx.xx.70 > 5.xx.xx.65: ICMP echo request, id 729, seq 1, length 64
23:04:00.611958 IP 5.xx.xx.65 > 5.xx.xx.70: ICMP echo reply, id 729, seq 1, length 64

Реплаи есть на интерфейсе, однако система их не видит:

ping 5.xx.xx.65
PING 5.xx.xx.65 (5.xx.xx.65) 56(84) bytes of data.
^C
--- 5.xx.xx.65 ping statistics ---
68 packets transmitted, 0 received, 100% packet loss, time 67535ms

Что за <цензура>?

Игры со всякими rp_filter и proxy_arp на интерфейсе гостевой и dom0 ни к чему не привели :(

На гостевой файрволл пуст по всем цепочкам. На dom0, после старта гостевой правила в транзите:

Chain FORWARD (policy ACCEPT 62035 packets, 3323K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   77  6468 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif9.0 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-in vif9.0 udp spt:68 dpt:67 
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif9.0 
   77  6468 ACCEPT     all  --  *      *       5.xx.xx.70             0.0.0.0/0           PHYSDEV match --physdev-in vif9.0 

Между гостевой и dom0 все отлично:

ping 5.xx.xx.78
PING 5.xx.xx.78 (5.xx.xx.78) 56(84) bytes of data.
64 bytes from 5.xx.xx.78: icmp_req=1 ttl=64 time=2.80 ms
64 bytes from 5.xx.xx.78: icmp_req=2 ttl=64 time=0.153 ms

Из dom0 шлюз тоже отлично виден (одна подсеть на dom0 и гостевую): Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
5.xx.xx.64        0.0.0.0         255.255.255.224 U     0      0        0 xenbridge
0.0.0.0         5.xx.xx.65        0.0.0.0         UG    0      0        0 xenbridge

PING 5.xx.xx.65 (5.xx.xx.65) 56(84) bytes of data.
64 bytes from 5.xx.xx.65: icmp_req=1 ttl=64 time=3.27 ms
64 bytes from 5.xx.xx.65: icmp_req=2 ttl=64 time=1.12 ms

В гостевой и dom0 ядро одинаковое:

Linux sample.ru 2.6.32-5-xen-amd64 #1 SMP Sun May 6 08:57:29 UTC 2012 x86_64 GNU/Linux
Что за мистика??? Как побороть можно?

Гостевая видит только пакеты от dom0, а все что извне не воспринимает :(

Мак-адреса на бридже:

brctl showmacs xenbridge

port no	mac addr		is local?	ageing timer
  1	54:04:a6:b4:97:59	yes		   0.00
  1	74:44:01:76:85:22	no		   8.85
  1	78:fe:3d:47:19:06	no		   0.00
  2	fe:ff:ff:ff:ff:ff	yes		   0.00



Последнее исправление: xnt (всего исправлений: 2)

Попробуйте в domU сбросить арп таблицу, затем сделать

ip monitor

И в другой консоли запустить пинг к шлюзу куда то. В iptables domU вы смотрели во все таблицы nat,filter,mangle,raw? Никаких ebtables не используется?

ventilator ★★★
()
Ответ на: комментарий от ventilator

В iptables domU вы смотрели во все таблицы nat,filter,mangle,raw? Никаких ebtables не используется?

Да, все таблицы просмотрел. ebtables нигде не используется.

В domU (.78 dom0 .65 шлюз)

ip monit
5.xx.xx.78 dev eth0 lladdr 54:04:a6:b4:97:59 STALE
5.xx.xx.65 dev eth0  FAILED
5.xx.xx.78 dev eth0 lladdr 54:04:a6:b4:97:59 REACHABLE
5.xx.xx.65 dev eth0  FAILED
5.xx.xx.65 dev eth0  FAILED
5.xx.xx.65 dev eth0  FAILED
5.xx.xx.65 dev eth0  FAILED
5.xx.xx.65 dev eth0  FAILED

В dom0 при старте гостевой:

ip monit

6: vif2.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
6: vif2.0: <BROADCAST,MULTICAST> mtu 1500 master xenbridge state DOWN 
    link/ether fe:ff:ff:ff:ff:ff
6: vif2.0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
6: vif2.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN 
    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
ff00::/8 dev vif2.0  table local  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev vif2.0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
6: vif2.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 
    link/ether fe:ff:ff:ff:ff:ff
6: vif2.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master xenbridge state UNKNOWN 
    link/ether fe:ff:ff:ff:ff:ff

При том что пакеты в domU на интерфейсе есть :( Темные силы электроники :(

xnt
() автор топика
Ответ на: комментарий от xnt

Проблема решена.

У Хетцнера привязка была к MAC-адресам. Блин столько времени потерял из-за такой ерунды.

xnt
() автор топика
Ответ на: Проблема решена. от xnt

Что то я не совсем понял, как привязка в DC мешала попадать записям в arp таблицу, если вы tcpdumpoм видите

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:59:42.659118 ARP, Request who-has 5.xx.xx.65 tell 5.xx.xx.70, length 28
22:59:42.660151 ARP, Reply 5.xx.xx.65 is-at 78:fe:3d:47:19:06, length 46
ventilator ★★★
()
Ответ на: комментарий от ventilator

Ну дык, ответ от шлюза идет на другой мак. Потому он на интерфейсе есть (виртуальный бридж), а система его честно не воспринимает.

У Хетцнера, привязка к маку. Любой ответ идет с тем маком, который знает Хетцнер.

Эта блин особенность столько времени отняла... Нет слов.

Запрашиваешь дополнительный IP - привязан к маку сетевухи сервера. Поднимаешь виртуалку - запроси мак, они выдадут, который надо на виртуалке прописать.

Пипец. Я чуть не разуверился в своем видении мира и компетенции...

xnt
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.