OpenVZ Forum


Home » International » Russian » arp-запрос не через нужный интерфейс
arp-запрос не через нужный интерфейс [message #43627] Mon, 03 October 2011 12:03
epiphany is currently offline  epiphany
Messages: 2
Registered: September 2011
Junior Member
Привет.
У меня есть проблема с arp-запросами из виртуальной машины.
Проблема наблюдается только на 32ом ядре, на 18ом ядре таких проблем нет.

Система выглядит так:
хост (2.6.32-042stab037.1 x86_64) имеет 2 сетевых интерфейса (внешний и внутренний)
eth0:88.88.88.52
eth1:192.168.1.10


виртуалка (SL6.1 x86_64) имеет 2 сетевых интерфейса (внешний и внутренний)
eth0:88.88.88.53
eth1:192.168.1.11


роутинг хоста
88.88.88.53 dev veth1.0  scope link 
192.168.1.11 dev veth1.1  scope link 
88.88.88.48/29 dev eth0  proto kernel  scope link  src 88.88.88.52 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.10 
192.168.0.0/16 via 192.168.1.1 dev eth1 
default via 88.88.88.49 dev eth0 


роутинг виртуалки
192.168.0.0/16 dev eth1  scope link 
default dev eth0  scope link 


С хоста работает все и всегда, идут пинги в обе сети.
С виртуалки внешняя сеть (eth0) работает всегда. А вот со внутренней проблемы. Выражаются они в потере пинга. Никаких потерь с хоста в это время нет. Причем пакеты теряются неслучайным образом, а закономерно. Проходит 8-9 пактов, после чего 25 теряются, 8-9 проходят, 25 теряются.

Пингую с виртуалки 192.168.1.1 и tcpdump с начала пинга такой:
15:40:37.292085 ARP, Request who-has 192.168.1.1 tell 192.168.1.11, length 28
15:40:37.876107 ARP, Reply 192.168.1.1 is-at 00:18:51:6c:52:2e, length 28
15:40:37.876125 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 1, length 64
15:40:37.876613 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 1, length 64
15:40:38.291193 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 2, length 64
15:40:38.291662 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 2, length 64
15:40:39.291138 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 3, length 64
15:40:39.291629 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 3, length 64
15:40:40.291153 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 4, length 64
15:40:40.291612 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 4, length 64
15:40:41.291383 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 5, length 64
15:40:41.291855 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 5, length 64
15:40:42.291160 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 6, length 64
15:40:42.291639 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 6, length 64
15:40:42.876124 ARP, Request who-has 192.168.1.11 tell 88.88.88.52, length 28
15:40:43.291361 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 7, length 64
15:40:43.291803 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 7, length 64
15:40:43.876116 ARP, Request who-has 192.168.1.11 tell 88.88.88.52, length 28
15:40:44.291348 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 8, length 64
15:40:44.291801 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 8, length 64
15:40:44.876106 ARP, Request who-has 192.168.1.11 tell 88.88.88.52, length 28
15:40:45.291363 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 9, length 64
15:40:45.291793 IP 192.168.1.1 > 192.168.1.11: ICMP echo reply, id 28418, seq 9, length 64
15:40:46.291163 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 10, length 64
15:40:46.292341 ARP, Request who-has 192.168.1.11 tell 88.88.88.52, length 28
15:40:47.291154 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 11, length 64
15:40:47.292333 ARP, Request who-has 192.168.1.11 tell 88.88.88.52, length 28
15:40:48.291157 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 12, length 64
15:40:48.292335 ARP, Request who-has 192.168.1.11 tell 88.88.88.52, length 28
15:40:49.291143 IP 192.168.1.11 > 192.168.1.1: ICMP echo request, id 28418, seq 13, length 64


То есть, получив корректный arp-ответ через нужный интерфейс - пинг идет 8 секунд, после чего идет arp-запрос через неправильный интерфейс и пинг перестает идти.

Пробовал делать как написано тут http: //wiki.openvz.org/Multiple_network_interfaces_and_ARP_flux .
sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

/etc/vz/vznet.conf
#!/bin/bash
EXTERNAL_SCRIPT="/usr/lib/vzctl/scripts/vznet-custom"

/usr/lib/vzctl/scripts/vznet-custom
#!/bin/bash
/sbin/ip neigh del proxy
/sbin/ip neigh add proxy 192.168.1.11 dev eth1
/sbin/ip neigh add proxy 88.88.88.53 dev eth0

Но ситуацию это не изменило, arp-запрос через 8-9 секунд идет не через нужный интерфейс.

Подскажите, в чем может быть дело.
Previous Topic: драйвер в стиле kmod для megasr LSI1068
Next Topic: В одном из контейнеров перестали работать квоты
Goto Forum:
  


Current Time: Sun Aug 11 19:14:09 GMT 2024

Total time taken to generate the page: 0.02960 seconds