The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Проблема с сетью в XEN DomU"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Виртуализация)
Изначальное сообщение [ Отслеживать ]

"Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 26-Янв-11, 17:27 
Приветствую.

Народ, помогите, пожалуйста, понять и исправить проблему. Не могу въехать, что не так.

После разворачивания domU (centos 5.5 x86) не ходят пинги/пакеты дальше dom0.

Сам dom0: Linux t1-debian 2.6.26-2-xen-amd64 #1 SMP Thu Nov 25 06:39:26 UTC 2010 x86_64 GNU/Linux.
Мои конфиги и вывод команд:

# cat /etc/xen/xend-config.sxp | grep -v '^#\|^$'
(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)
(vncpasswd '')

# brctl show
bridge name    bridge id        STP enabled    interfaces
eth0        8000.0025900af0fa    no        peth0
                            vif1.0

route на dom0:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
95.163.69.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         95.163.69.1     0.0.0.0         UG    0      0        0 eth0

route на domU:

[root@centos-x86 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
95.163.69.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         95.163.69.1     0.0.0.0         UG    0      0        0 eth0

Конфиг domU:

# cat /etc/xen/centos-x86.cfg 
bootloader = '/usr/sbin/pygrub'
memory = '256'
vcpus = '1'
name = 'centos.5-5.x86'
vif = [ 'mac=00:16:3E:E2:7E:19' ]
disk = [ 'tap:aio:/xen/domains/centos-x86/disk.img,xvda2,w', 'tap:aio:/xen/domains/centos-x86/swap.img,xvda1,w' ]
root = '/dev/xvda2'
extra = 'clocksource=jiffies fastboot'
#vnc = '1'
#vfb = [ 'type=vnc,vncpasswd=password,vncdisplay=5900' ]
on_crash = 'restart'
on_poweroff = 'destroy'
on_reboot = 'restart'

ifconfig на domU отображает интерфейс (он описан статически пока):

[root@centos-x86 ~]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:16:3E:E2:7E:19  
          inet addr:95.163.69.49  Bcast:95.163.69.255  Mask:255.255.255.0
          inet6 addr: fe80::216:3eff:fee2:7e19/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:450 errors:0 dropped:0 overruns:0 frame:0
          TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:64104 (62.6 KiB)  TX bytes:1014 (1014.0 b)
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:672 (672.0 b)  TX bytes:672 (672.0 b)

ifconfig на dom0 тоже в норме (бридж eth0):

eth0      Link encap:Ethernet  HWaddr 00:25:90:0a:f0:fa  
          inet addr:95.163.69.48  Bcast:95.163.69.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1785 errors:0 dropped:0 overruns:0 frame:0
          TX packets:701 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:164866 (161.0 KiB)  TX bytes:278190 (271.6 KiB)
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
peth0     Link encap:Ethernet  HWaddr 00:25:90:0a:f0:fa  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1766 errors:0 dropped:0 overruns:0 frame:0
          TX packets:786 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:188842 (184.4 KiB)  TX bytes:283560 (276.9 KiB)
          Memory:fb5e0000-fb600000 
vif1.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:19 errors:0 dropped:0 overruns:0 frame:0
          TX packets:422 errors:0 dropped:63 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:748 (748.0 B)  TX bytes:58096 (56.7 KiB)

То есть все стандартно.
Если делаю ping dom0, ответ есть:

[root@centos-x86 ~]# ping -c 2 95.163.69.48
PING 95.163.69.48 (95.163.69.48) 56(84) bytes of data.
64 bytes from 95.163.69.48: icmp_seq=1 ttl=64 time=0.030 ms
64 bytes from 95.163.69.48: icmp_seq=2 ttl=64 time=0.049 ms
--- 95.163.69.48 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.030/0.039/0.049/0.011 ms

Если пингую шлюз, или любой внешний адрес, то ответ:

[root@centos-x86 ~]# ping -c 2 95.163.69.1
PING 95.163.69.1 (95.163.69.1) 56(84) bytes of data.
From 95.163.69.49 icmp_seq=1 Destination Host Unreachable
From 95.163.69.49 icmp_seq=2 Destination Host Unreachable
--- 95.163.69.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1007ms

Включаю tcpdump на dom0 при пинге внешних адресов с domU,в результате вижу хождение пакетов в одну сторону:

[root@centos-x86 ~]# ping 95.163.69.1
PING 95.163.69.1 (95.163.69.1) 56(84) bytes of data.
From 95.163.69.49 icmp_seq=1 Destination Host Unreachable
From 95.163.69.49 icmp_seq=2 Destination Host Unreachable
From 95.163.69.49 icmp_seq=3 Destination Host Unreachable
root@t1-debian:~# tcpdump -i vif1.0
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif1.0, link-type EN10MB (Ethernet), capture size 96 bytes
07:30:51.092687 arp who-has 95.163.69.1 tell 95.163.69.49
07:30:52.092633 arp who-has 95.163.69.1 tell 95.163.69.49
07:30:54.092634 arp who-has 95.163.69.1 tell 95.163.69.49
07:30:55.092631 arp who-has 95.163.69.1 tell 95.163.69.49
07:30:56.092632 arp who-has 95.163.69.1 tell 95.163.69.49
07:30:58.092632 arp who-has 95.163.69.1 tell 95.163.69.49

Для сравнения то же самое при пинге dom0 c domU:

[root@centos-x86 ~]# ping 95.163.69.48
PING 95.163.69.48 (95.163.69.48) 56(84) bytes of data.
64 bytes from 95.163.69.48: icmp_seq=1 ttl=64 time=0.072 ms
64 bytes from 95.163.69.48: icmp_seq=2 ttl=64 time=0.050 ms
64 bytes from 95.163.69.48: icmp_seq=3 ttl=64 time=0.049 ms
root@t1-debian:~# tcpdump -i vif1.0
tcpdump: WARNING: vif1.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif1.0, link-type EN10MB (Ethernet), capture size 96 bytes
07:32:47.980680 IP 95.163.69.49 > t1-debian: ICMP echo request, id 51203, seq 10, length 64
07:32:47.980695 IP t1-debian > 95.163.69.49: ICMP echo reply, id 51203, seq 10, length 64
07:32:48.980669 IP 95.163.69.49 > t1-debian: ICMP echo request, id 51203, seq 11, length 64
07:32:48.980685 IP t1-debian > 95.163.69.49: ICMP echo reply, id 51203, seq 11, length 64
07:32:49.980646 IP 95.163.69.49 > t1-debian: ICMP echo request, id 51203, seq 12, length 64
07:32:49.980661 IP t1-debian > 95.163.69.49: ICMP echo reply, id 51203, seq 12, length 64
07:32:50.980666 IP 95.163.69.49 > t1-debian: ICMP echo request, id 51203, seq 13, length 64
07:32:50.980681 IP t1-debian > 95.163.69.49: ICMP echo reply, id 51203, seq 13, length 64
07:32:51.980669 IP 95.163.69.49 > t1-debian: ICMP echo request, id 51203, seq 14, length 64
07:32:51.980686 IP t1-debian > 95.163.69.49: ICMP echo reply, id 51203, seq 14, length 64

iptables & selinux ни там, ни там нет. Пробовал понижать mtu на domU до 1420, не помогло.
Подскажите, в чем может быть дело? Не знаю что делать.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Проблема с сетью в XEN DomU"  +/–
Сообщение от PavelR (??) on 26-Янв-11, 19:02 
> Приветствую.
> Народ, помогите, пожалуйста, понять и исправить проблему. Не могу въехать, что не
> так.

У провайдера привязка к мак-адресу ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 26-Янв-11, 19:27 
>> Приветствую.
>> Народ, помогите, пожалуйста, понять и исправить проблему. Не могу въехать, что не
>> так.
> У провайдера привязка к мак-адресу ?

Однозначно нет. Это отдельный сервер в датацентре.
Дело в том, что до этого я тестировал dom0 на Debian Squeeze с XEN 4.0. Там домены поднимались, сеть работала. С такой проблемой столкнулся, переустановив систеу и XEN на Lenny + XEN 3.2.

Сейчас попробовал загрузку с ядром dom0, аналогичный результат.

Также заметил, что при xm create скрипт ксена добавляет правило в iptables:

# iptables -L -n -v --line-numbers
Chain INPUT (policy ACCEPT 1451 packets, 110K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
Chain FORWARD (policy ACCEPT 39 packets, 12948 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           PHYSDEV match --physdev-in vif3.0 
Chain OUTPUT (policy ACCEPT 949 packets, 335K bytes)
num   pkts bytes target     prot opt in     out     source               destination

Если очистить таблицы и сделать пересоздание домена, оно добавится вновь. ip_forward на dom0 включен.

Отключил обработку правил в iptables на самом мосту, как сказано здесь: http://xgu.ru/wiki/%D0%A1%D0%B5%D1&... , но не помогло. Вообще такое ощущение, что проблема где-то между dom0 - domU, при уходе пакетов вовне, а не в dom0.

Может быть попробовать network-dommy и написать кастом-скрипт? Что в нем можно опробовать?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Проблема с сетью в XEN DomU"  +/–
Сообщение от shadow_alone (ok) on 26-Янв-11, 19:59 
Я то же первым делом подумал про привязку к маку, ну раз нет, то нет.

А попробуйте на domU шлюзом указать IP dom0, и будет ясно (должно быть прояснение).

Тупо конечно, то все-таки: а в сети нет девайса с IP-адресом, который вы прописываете для domU?

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 04:53 
> Я то же первым делом подумал про привязку к маку, ну раз
> нет, то нет.
> А попробуйте на domU шлюзом указать IP dom0, и будет ясно (должно
> быть прояснение).
> Тупо конечно, то все-таки: а в сети нет девайса с IP-адресом, который
> вы прописываете для domU?

Не должно быть. 95.163.69.48 у dom0, 95.163.69.49 у domU.

Прописал в /etc/sysconfig для интереса шлюзом адрес 95.163.69.48

[root@centos-x86 ~]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
95.163.69.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         95.163.69.48    0.0.0.0         UG        0 0          0 eth0

Сделал xm shutdown, xm create. Запустил пинг гугловских днс. tcpdump показывает интересно:

04:47:47.512451 IP 95.163.69.49 > google-public-dns-a.google.com: ICMP echo request, id 60163, seq 88, length 64
04:47:48.512425 arp who-has 95.163.69.1 tell 95.163.69.49
04:47:48.512451 IP 95.163.69.49 > google-public-dns-a.google.com: ICMP echo request, id 60163, seq 89, length 64
04:47:49.512424 arp who-has 95.163.69.1 tell 95.163.69.49
04:47:49.512448 IP 95.163.69.49 > google-public-dns-a.google.com: ICMP echo request, id 60163, seq 90, length 64
04:47:50.516432 arp who-has 95.163.69.1 tell 95.163.69.49
04:47:51.516432 arp who-has 95.163.69.1 tell 95.163.69.49
04:47:52.516432 arp who-has 95.163.69.1 tell 95.163.69.49
04:47:53.174693 arp who-has 95.163.69.247 tell 95.163.69.1
04:47:53.174751 IP 95.163.69.49 > google-public-dns-a.google.com: ICMP echo request, id 60163, seq 91, length 64
04:47:53.174752 IP 95.163.69.49 > google-public-dns-a.google.com: ICMP echo request, id 60163, seq 92, length 64
04:47:53.174752 IP 95.163.69.49 > google-public-dns-a.google.com: ICMP echo request, id 60163, seq 93, length 64

При этом на domU нет ответов, хотя бы частично:

[root@centos-x86 ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 95.163.69.49 icmp_seq=26 Destination Host Unreachable
From 95.163.69.49 icmp_seq=27 Destination Host Unreachable
From 95.163.69.49 icmp_seq=28 Destination Host Unreachable
From 95.163.69.49 icmp_seq=30 Destination Host Unreachable
From 95.163.69.49 icmp_seq=31 Destination Host Unreachable
From 95.163.69.49 icmp_seq=32 Destination Host Unreachable

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

10. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 06:08 
Хотя нет, показывает все то же, пакеты в одну сторону.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 04:59 
> Я то же первым делом подумал про привязку к маку, ну раз
> нет, то нет.
> А попробуйте на domU шлюзом указать IP dom0, и будет ясно (должно
> быть прояснение).
> Тупо конечно, то все-таки: а в сети нет девайса с IP-адресом, который
> вы прописываете для domU?

Изменил адрес у domU на свободный 95.163.69.50, такая же ситуация.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Проблема с сетью в XEN DomU"  +/–
Сообщение от PavelR (??) on 26-Янв-11, 21:35 
> Дело в том, что до этого я тестировал dom0 на Debian Squeeze
> с XEN 4.0. Там домены поднимались, сеть работала.

Ну а в чем проблема эксплуатировать 4.0 + 2.6.32 (Squeeze) ?
В нем в принципе и domU на 2.6.26-2 (Lenny) успешно работает.
Я наоборот, на него переезжаю, а не наоборот.

> С такой проблемой столкнулся, переустановив систеу и XEN на Lenny + XEN 3.2.

А domU переустановили ? В нем на интерфейсе ошибок не замечено ли ? А то много чего бывает интересного =)

> Сейчас попробовал загрузку с ядром dom0, аналогичный результат.

Это как ? Т.е. вы под ленни запускали domU от сквизи ? Такое запускается ??

> Также заметил, что при xm create скрипт ксена добавляет правило в iptables:

Я это "отключаю" комментированием строки handle_iptable в vif-bridge (либо свой скрипт (закомментированный) в конфиг интерфейса можно прописать)

>[оверквотинг удален]
> 1        0    
>  0 ACCEPT     all  --  
> *      *    
>   0.0.0.0/0        
>    0.0.0.0/0        
>    PHYSDEV match --physdev-in vif3.0
> Если очистить таблицы и сделать пересоздание домена, оно добавится вновь. ip_forward на
> dom0 включен.
> Отключил обработку правил в iptables на самом мосту, как сказано здесь: http://xgu.ru/wiki/%D0%A1%D0%B5%D1&...
> , но не помогло.

Вроде не ваш случай :-) Счетчики то нулевые )

> Вообще такое ощущение, что проблема где-то между
> dom0 - domU, при уходе пакетов вовне, а не в dom0.

Еще раз подробнее условия эксперимента, версии ядер/пакетов в dom0/domU.

> Может быть попробовать network-dommy и написать кастом-скрипт?
>Что в нем можно опробовать?

То же самое что и пробовали при установке Squeeze. ;-)

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 05:25 
> А domU переустановили ? В нем на интерфейсе ошибок не замечено ли
> ? А то много чего бывает интересного =)

Ага, имел ввиду, что до этого ставил Squeeze с нуля, правда это был weekly-build образ, потому что squeeze как стэйбл релиз ожидается в феврале. Потом поднимал dom0 на тамошнем xen 4.0.

То есть Squeeze затер полностью и установил стэйбл Lenny. Поэтому конечно и dom0 стоит новый, на xen 3.2.1, и domU создаю заново. Шаблоны у меня заранее подготовлены в тарболлах. То есть создаю файлы для domU через `dd' и потом разворачиваю готовый шаблон, подмонтировав img-файл. Начал с CentOS 5.5 x86 domU, сам dom0 - это, как видно выше, Debian Lenny amd64.

> Это как ? Т.е. вы под ленни запускали domU от сквизи ?
> Такое запускается ??

Нене. Закомментировал bootloader = '/usr/sbin/pygrub' в конфиге и добавил kernel = '/boot/vmlinuz-2.6.26-2-xen-amd64' и ramdisk = '/boot/initrd.img-2.6.26-2-xen-amd64'. То есть вместо собственного ядра domU проверил с ядром от dom0, хотя оно и дебиановское. domU загружается, свиду все так же, но пинг не ходит.

> Я это "отключаю" комментированием строки handle_iptable в vif-bridge (либо свой скрипт
> (закомментированный) в конфиг интерфейса можно прописать)

Тоже убрал, так как вчера заметил это добавление правила в таблицу filter. Так же. Да и не думаю, что в стэйбл дебиане сделали бы такую подлость. :)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Проблема с сетью в XEN DomU"  +/–
Сообщение от PavelR (??) on 26-Янв-11, 21:38 

Ну и побольше сделайте tcpdump-ов при попытках пинга внешнего шлюза из domU. Т.е. подампьте трафик vif, eth,peth.... Там всё и будет ясно.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

9. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 06:05 
> Ну и побольше сделайте tcpdump-ов при попытках пинга внешнего шлюза из domU.
> Т.е. подампьте трафик vif, eth,peth.... Там всё и будет ясно.

Значит так...

Запустил domU, вот его ifconfig и route:

[root@centos-x86 ~]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:50:56:29:D5:7A  
          inet addr:95.163.69.50  Bcast:95.163.69.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe29:d57a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:55 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6762 (6.6 KiB)  TX bytes:762 (762.0 b)
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
[root@centos-x86 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
95.163.69.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         95.163.69.1     0.0.0.0         UG    0      0        0 eth0

Пингую с domU ip-адрес dom0, все в порядке:

[root@centos-x86 ~]# ping -c 2 95.163.69.48
PING 95.163.69.48 (95.163.69.48) 56(84) bytes of data.
64 bytes from 95.163.69.48: icmp_seq=1 ttl=64 time=0.097 ms
64 bytes from 95.163.69.48: icmp_seq=2 ttl=64 time=0.067 ms

Выхожу из domU в dom0 и пингую с него domU, тоже норма:

root@t1-debian:~# ping -c 2 95.163.69.50
PING 95.163.69.50 (95.163.69.50) 56(84) bytes of data.
64 bytes from 95.163.69.50: icmp_seq=1 ttl=64 time=0.063 ms
64 bytes from 95.163.69.50: icmp_seq=2 ttl=64 time=0.054 ms

Пакеты dom0 <-> domU ходят.
Далее.. Начинаю пинговать что-нибудь внешнее, например, шлюз 95.163.69.1 (но цель пинга не важна, с 8.8.8.8 будет так же). Внешка c domU уже не работает:

[root@centos-x86 ~]# ping -c 2 95.163.69.1 
PING 95.163.69.1 (95.163.69.1) 56(84) bytes of data.
From 95.163.69.50 icmp_seq=1 Destination Host Unreachable
From 95.163.69.50 icmp_seq=2 Destination Host Unreachable
--- 95.163.69.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1010ms, pipe 2

Сразу говорю, что на dom0 с сетью порядок, иначе я бы не смог подключаться и т.п. :)

Теперь. Смотрю список интерфейсов для tcpdump:

root@t1-debian:~# tcpdump -D
1.peth0
2.eth0
3.vif10.0
4.any (Pseudo-device that captures on all interfaces)
5.lo

Запускаю ping 95.163.69.1 с domU и смотрю вывод tcpdump сначала на интерфейсе vif10.0:

[root@centos-x86 ~]# ping 95.163.69.1
PING 95.163.69.1 (95.163.69.1) 56(84) bytes of data.
root@t1-debian:~# tcpdump -nq -i vif10.0 host 95.163.69.50
tcpdump: WARNING: vif10.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif10.0, link-type EN10MB (Ethernet), capture size 96 bytes
05:54:45.774605 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 9, length 64
05:54:46.774567 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 10, length 64
05:54:47.774549 arp who-has 95.163.69.1 tell 95.163.69.50
05:54:47.774576 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 11, length 64
05:54:48.774578 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 12, length 64
05:54:49.774571 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 13, length 64
05:54:50.774568 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 14, length 64
05:54:51.774570 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 15, length 64
05:54:52.774571 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 16, length 64
05:54:53.774558 arp who-has 95.163.69.1 tell 95.163.69.50
05:54:53.774583 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 17, length 64
05:54:54.774560 arp who-has 95.163.69.1 tell 95.163.69.50
05:54:54.774616 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 18, length 64
05:54:55.774559 arp who-has 95.163.69.1 tell 95.163.69.50
05:54:55.774585 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 19, length 64
05:54:56.778544 arp who-has 95.163.69.1 tell 95.163.69.50
05:54:57.778555 arp who-has 95.163.69.1 tell 95.163.69.50
05:54:58.531966 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 20, length 64
05:54:58.531967 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 21, length 64

Теперь смотрю tcpdump на мосту eth0:

root@t1-debian:~# tcpdump -nq -i eth0 host 95.163.69.50
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
05:56:38.154609 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:38.774577 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 122, length 64
05:56:39.154560 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:39.774604 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 123, length 64
05:56:40.154562 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:40.774580 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 124, length 64
05:56:41.778557 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:42.778550 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:43.778556 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:45.778556 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:46.778549 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:47.778556 arp who-has 95.163.69.1 tell 95.163.69.50
05:56:48.513994 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 129, length 64
05:56:48.513995 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 130, length 64

Аналогично, пакеты видны в одну сторону, domU -> dom0. dom0 не дает ответа.
Ну и tcpdump peth0:

root@t1-debian:~# tcpdump -nq -i peth0 host 95.163.69.50
tcpdump: WARNING: peth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on peth0, link-type EN10MB (Ethernet), capture size 96 bytes
05:58:46.774605 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 250, length 64
05:58:47.774612 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 251, length 64
05:58:48.774585 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 252, length 64
05:58:49.774563 arp who-has 95.163.69.1 tell 95.163.69.50
05:58:49.774607 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 253, length 64
05:58:50.774560 arp who-has 95.163.69.1 tell 95.163.69.50
05:58:50.774585 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 254, length 64
05:58:51.774573 arp who-has 95.163.69.1 tell 95.163.69.50
05:58:51.774610 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 255, length 64
05:58:52.778555 arp who-has 95.163.69.1 tell 95.163.69.50
05:58:53.778566 arp who-has 95.163.69.1 tell 95.163.69.50
05:58:54.778559 arp who-has 95.163.69.1 tell 95.163.69.50

Получается, дело не в dom0. Значит бриджинг работает.

Для сравнения, включил на domU опять пинг dom0. tcpdump:

root@t1-debian:~# tcpdump -nq -i vif10.0 host 95.163.69.50
tcpdump: WARNING: vif10.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif10.0, link-type EN10MB (Ethernet), capture size 96 bytes
06:03:03.246632 IP 95.163.69.50 > 95.163.69.48: ICMP echo request, id 61187, seq 48, length 64
06:03:03.246711 IP 95.163.69.48 > 95.163.69.50: ICMP echo reply, id 61187, seq 48, length 64

То есть без проблем выдны echo request & echo reply при tcpump vif10.0 и eth0. tcdump peth0 в этом случае конечно молчит, потому что это бридж -- работает vif <-> eth0, без участия peth0.
Извиняюсь за такую подробность, разжевал как мог :)

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

11. "Проблема с сетью в XEN DomU"  +/–
Сообщение от PavelR (??) on 27-Янв-11, 07:54 

Значит вкратце, чтобы было понятнее:

У вас не хватает вот таких ответов:

10:47:13.297244 arp who-has 2.6.1.69 tell 2.6.1.65
10:47:13.297398 arp reply 2.6.1.69 is-at 00:16:3e:6c:81:4f (oui Unknown)

Это хост 2.6.1.65 ищет в подсетке мак-адрес хоста 2.6.1.69.

Кроме этого, есть волшебный ключик -e который превращает ответ в :

10:50:09.264250 00:1c:c0:06:56:e1 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: arp who-has 2.6.1.69 tell 2.6.1.65


А еще есть команда arp, которая покажет вам интересную для сравнения/размышления информацию.

Куда у вас отправляются пакеты, если нет арп-ответа, слегка не понятно:

>05:58:51.774610 IP 95.163.69.50 > 95.163.69.1: ICMP echo request, id 60931, seq 255, length 64
>05:58:52.778555 arp who-has 95.163.69.1 tell 95.163.69.50

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 09:44 
> Кроме этого, есть волшебный ключик -e который превращает ответ в :
> 10:50:09.264250 00:1c:c0:06:56:e1 (oui Unknown) > Broadcast, ethertype ARP (0x0806),
> length 42: arp who-has 2.6.1.69 tell 2.6.1.65

При пинге с domU наблюдаю такие вещи через tcpdump на dom0:

tcpdump -enq -i vif11.0
tcpdump: WARNING: vif11.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vif11.0, link-type EN10MB (Ethernet), capture size 96 bytes
09:43:18.013215 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 10, length 64
09:43:19.013207 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 11, length 64
09:43:19.439996 3c:df:1e:db:83:48 > ff:ff:ff:ff:ff:ff, ARP, length 60: arp who-has 95.163.69.168 tell 95.163.69.1
09:43:20.013188 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 12, length 64
09:43:20.628348 00:25:90:0a:fc:02 > 01:80:c2:00:00:0e, Unknown Ethertype (0x88cc), length 118: 
09:43:21.013203 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 13, length 64
09:43:21.285459 3c:df:1e:db:83:48 > ff:ff:ff:ff:ff:ff, ARP, length 60: arp who-has 95.163.69.112 tell 95.163.69.1
09:43:22.013185 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 14, length 64
09:43:22.484594 3c:df:1e:db:83:48 > ff:ff:ff:ff:ff:ff, ARP, length 60: arp who-has 95.163.69.122 tell 95.163.69.1
09:43:22.627703 00:25:90:0a:fc:07 > 01:80:c2:00:00:0e, Unknown Ethertype (0x88cc), length 118: 
09:43:22.631897 3c:df:1e:db:83:48 > ff:ff:ff:ff:ff:ff, ARP, length 60: arp who-has 95.163.69.91 tell 95.163.69.1
09:43:23.013205 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 15, length 64
09:43:24.013178 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 16, length 64
09:43:25.013206 00:16:3e:cf:d9:5e > 3c:df:1e:db:83:48, IPv4, length 98: 95.163.69.49 > 95.163.69.1: ICMP echo request, id 1028, seq 17, length 64
09:43:25.334491 3c:df:1e:db:83:48 > ff:ff:ff:ff:ff:ff, ARP, length 60: arp who-has 95.163.69.122 tell 95.163.69.1

Что-то мне подсказывает, что истина где-то рядом :(

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 10:13 
Насчет того, если буду обновлять xen. Вы использовали backports?
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

16. "Проблема с сетью в XEN DomU"  +/–
Сообщение от DISTROFIC email on 06-Фев-11, 15:20 
>> Приветствую.
>> Народ, помогите, пожалуйста, понять и исправить проблему. Не могу въехать, что не
>> так.
> У провайдера привязка к мак-адресу ?

Такая же ситуация....
Только есть привязка по маку..

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

13. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 09:54 
Сейчас попробую развернуть еще один domU с CentOS, но 64bit. Посмотрю, как они будут между собой.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Проблема с сетью в XEN DomU"  +/–
Сообщение от Gular (ok) on 27-Янв-11, 16:29 
Всем спасибо за отклик. Проблема была со стороны NOC, как и предполагал. Вопрос закрыт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру