задержка arp-ответа

[tx2]

здраствуйте!

не знаю даже с какой стороны подобратся к задаче.
в процессе максимально упростил условия.
описываю максимально подробно, ТК уже даже не знаю к чему цеплятся.

итак:
есть 2 компьютера
10.0.1.4 - свежепоставленный debian etch, пустой
10.0.1.16 - зло ХР (можно пинать), тоже пустой

10.0.1.4 $ ip l
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0e:a6:6e:9c:ed brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ieee1394 00:e0:18:00:00:61:31:da brd ff:ff:ff:ff:ff:ff:ff:ff
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0

при этом здесь eth0 - виртуальная сетевуха 1394 - не нужна
а eth1 - смотрит в локалку

все это подключено к гигабитному свичу 3com office connect

на 10.0.1.4 фаервола нет
на 10.0.1.16 - настройки iptables - разрешить все

ситуация: 10.0.1.4 не трогается в течении ~5-10 мин - никакой сетевой активности и пр.
на 10.0.1.16 запускается wireshark (без него такая же ситуация)
и делается попытка установления соединения по ssh, с помощью putty (аналогично - любое другое соединение)

в снифере картина выглядит так:
14:14:30.696126 AsustekC_98:73:fc Broadcast ARP Who has 10.0.1.5? Tell 10.0.1.16
### ЗАДЕРЖКА в ДЕВЯТЬ!!! секунд
14:14:39.623569 AsustekC_98:73:fc Broadcast ARP Who has 10.0.1.5? Tell 10.0.1.16
14:14:39.623862 AsustekC_6e:9c:ed AsustekC_98:73:fc ARP 10.0.1.5 is at 00:0e:a6:6e:9c:ed
### тут нормально устанавливается соединение

как ликвидировать эту задержку???

в процессе нашел следующее:
http://linux-ip.net/html/ether-arp.html
http://wiki.openvz.org/Multiple_Network_In...es_And_ARP_Flux
(в статьях )

и пробовал (в разных комбинациях и пр.):
sysctl -w net.ipv4.conf.all.arp_filter=1
sysctl -w net.ipv4.conf.all.arp_announce=2
sysctl -w net.ipv4.conf.all.arp_ignore=2

также пробовал отключать eth0 (rmmod eth1394)

пробовал запустить tcpdump на самом 10.0.1.4 в момент запроса - задержки нет

единственным способом эффективно влияющим на ситуацию - arping в crontab.
но это самый настоящий костыль - исключено

вариант - прописать статически в arp таблицу - тоже крайне нежелателен

может у меня совсем глаза "замылены" и я не вижу чегото простого и очевидного?

на опеннете по этому вопросу - тишина

а вот буквально несколько минут назад выяснилось, что той же фигней страдает комп с centos 4.4.. который уже заброшенным стоит немеряно времени..

мысли? идеи?

зарание огромное спасибо!!!

[sash-kan]

мысли? идеи?

«все это подключено к гигабитному свичу 3com office connect» — вот с него-то и начните.
а смотреть сетевую активность сразу на обоих концах — весьма способствует.

[tx2]

чуть ниже я писал:
>> пробовал запустить tcpdump на самом 10.0.1.4 в момент запроса - задержки нет

причем эксперемент не однократный...

[calculator]

tx2,
10.0.1.4 - свежепоставленный debian etch, пустой
14:14:30.696126 AsustekC_98:73:fc Broadcast ARP Who has 10.0.1.5? Tell 10.0.1.16

10.0.1.16 - зло ХР (можно пинать), тоже пустой
на 10.0.1.16 - настройки iptables - разрешить все

Как то неочень понятно что и где.
пробовал запустить tcpdump на самом 10.0.1.4 в момент запроса - задержки нет
Попробуй зайти на debian и половить с чистой arp таблицей на обоих машинах что бы был arp who has от win машины - не теряются ли пакеты по дороге(врятли). Удалить MAC из таблицы можно через # arp -d

про sysctl: /usr/src/linux/Documentation/networking/ip-sysctl.txt
net.ipv4.conf.all.* как я понимаю шаблон для установки правил всем параметрам(*) Работает при старте. На интерфейс нужно указывать конкретно, например sysctl -w net.ipv4.conf.eth1.arp_filter=1 Но имхо лучьше там оставить что было по умолчанию или нули. 10.0.1.4 и 10.0.1.16 из одной подсети /24?

И еще вопрос: Задержки только при коннекте через ssh или первый пинг тоже _долгий_?

[tx2]

подсеть одна - /24

подключил к сети третью машину, тоже с etch - ставлю на нее снифер - видно, что пакеты не теряются...
порты свича тоже с помощью нее проверил.

задержки при любой активности, провоцирующей arp запрос-ответ - будь то tcp соединения, пинг или что еще...

чистить arp таблицы пробовал как на винде, так и на дебиане - задержка возникает только в случае если компы не имеют друг-друга в arp кешах

опции ядра arp_*** пробовал указывать как для all, так и для интерфейсов индивидуально

[susik]

подсеть одна - /24

подключил к сети третью машину, тоже с etch - ставлю на нее снифер - видно, что пакеты не теряются...
порты свича тоже с помощью нее проверил.

задержки при любой активности, провоцирующей arp запрос-ответ - будь то tcp соединения, пинг или что еще...

чистить arp таблицы пробовал как на винде, так и на дебиане - задержка возникает только в случае если компы не имеют друг-друга в arp кешах

опции ядра arp_*** пробовал указывать как для all, так и для интерфейсов индивидуально

Добрый день, коллеги
я бы подошел к проблеме поэтапно.
1) Исключаем из схесмы свич. Соединяем две машины кроссоверным кабелем. Оцениваем задержки.
2) Если задержки есть меняем сетевые карты или смотрим настройки ОС
3) Если задержек нет во 2 варианте, попробуйте другой свич и оцените задержки.

Ну вообще таки образом действовать, данный подход меня не раз выручал :-) думаю и вам поможет.

[tx2]

мысль понятна. спасибо.

кроссовый кабель пробовал.

также, пробовал на всем-том-же железе, поставить вместо дебиана - ХРюшку.
проблем нет...
имхо из этого вполне можно сделать вывод что проблема в ОС / её настройках

да.. недосказал: кроме как с arp-ответом задержек нет никаких...
потерь пакетов также...

[tx2]

последний эксперемент:

итак, есть сеть из 4х компов

две тестовых машины:
W1 - винда
W2 - дебиан етч

два пациента:
S1 - центос 4.4
S2 - дебиан етч

---

ход эксперемента:

###изначальная ситуация - арп кеши всех очищены.
отключены все активные(шлющие чтото в сеть) сетевые сервисы,
в.т.ч функции файлового сервера на винде
S1 и S2 висят пустые: запущены klogd, syslog, udevd, sshd, getty несколько штук...

1. пингуем c W1 S1 - задержка есть, пингуем c W1 S2 - задержка есть

2. ждем 20 минут

3. пингуем c W1 S1 - задержка есть, пингуем c W1 S2 - задержка есть

4. ждем 20 минут

5. пингуем c W2 S1 - задержка есть

### сейчас таблица W1 - пуста

6. пингуем c W1 S1 - задержки нет, пингуем c W1 S2 - задержка есть

7. ждем 20 минут

8. пингуем c W2 S2 - задержка есть

### сейчас таблица W1 - пуста

9. пингуем c W1 S1 - задержка есть, пингуем c W1 S2 - задержки нет

---

точно такая ситуация воспроизводится сколь угодно много раз (я пробовал раз 10)

при попытке запустить tcpdump на одном из S* - эксперемент не повторяется - задержек нет

---

напрашивается какойто тупой и невнятный вывод, будто компы в простое засыпают, и чтобы их разбудить - нужно пинать посильнее...
на "физику" грешить не получается.

---

как эту ситуацию можно объяснить техническим языком??
и главное: как правильно решить проблему??
(вариант с arping или nmap -sP по крону - не катят)