forum.lissyara.su

Несколько раз уже сталкивался с такой проблемой:
Есть распределенная сеть на маршрутизаторах Cisco c GRE over IPSEC.
В центральном офисе стоит серверо с FreeBSD 4.11 в удаленном - SCO OpenServer. Иногда после пропадания связи вырисовывается следующая картина. Пропадает доступ с сервера с SCO на сервер под фрей. Если запустить пинг с сервера под фрей, ответ от ско приходит, а если наоборот - то ответ для ско от фри не приходит, притом tcpdump пишет что icmp запрос от сервера с ско получен и ответ отправлен. Если попробовать пропинговать другой хост в сети центрального офиса - ответ приходит. Перезагрузка сервера с СКО не помогает, зато если дергнуть на сервере с фрей netstart - проблема исчезает.
Долго грешили на старый сервер под фрей и СКО ОпенСервер, но тут недавно поставили сервер под 8.1, а в удаленном офисе (не тот где стоит СКО) - MOXA nPort5510A и ситуация повторяется. И тут подозрения упали на сетевой стек FreeBSD. Никто не сталкивался с такими граблями?
ЗЫ возможности запустить tcpdump на SCO нет (серверу более 10 лет, никто его трогать не хочет, вдруг что - нет спеца, который бы мог с ним что-то сделать), в ближайшее время будем вместо него ставить nPort5510A, а в нем tcpdump'a естественно нет.

Я сталкивался с таким, но только на роутерах с прошивками OpenWRT. Пока проблему не поборол , мучаюсь.

А если попробовать отправить пинг со SCO, на FreeBSD, когда всё хорошо, и сдампить сессию, а потом сравнить её с той которая когда всё плохо, может это даст ответ в чём разница?

Врезать между сеткой и SCO сервер с двумя сетевыми в режиме моста и делать все что надо.

skeletor писал(а):Я сталкивался с таким, но только на роутерах с прошивками OpenWRT. Пока проблему не поборол , мучаюсь.

хм... тогда возможно дело и не в FreeBSD... это еще хуже

f_andrey писал(а):А если попробовать отправить пинг со SCO, на FreeBSD, когда всё хорошо, и сдампить сессию, а потом сравнить её с той которая когда всё плохо, может это даст ответ в чём разница?

разницы нет, правдо tcpdump запускал без -vvv... надо будет попробовать с -vvv

InventoR писал(а):Врезать между сеткой и SCO сервер с двумя сетевыми в режиме моста и делать все что надо.

вариант, только случается эт очень редко, да и ехать надо в другой город.
=====
меня больше всего смущает тот момент, что с сервера с фрей сервер с СКО или nPort пингаются, а наоборот - нет, но пакеты все-таки приходят и ответы на них отправляются %) то есть icmp echo reply до сервера под фрей доходит, а до СКО или нпорта - нет. хрень какая-то

А как дела с маршрутами на СКО когда пропадает связь?

да тут СКО непричем, т.к. проблема ведь и с nPort'ом
=====
сегодня опять повторилось... решил более детально отследить какой из пунктов в netstart приводит в чувство сервер с фрей. оказалось следующий скрипт: /etc/rc.d/routing
насколько я понимаю, из его содержимого, то в ситуации с дефолтными настройками rc.conf (ip,маршрут по умолчанию и лабуда связанная с настройками шрифтов), действия скрипта при рестарте заключаются в сбросе маршрутов: route -n flush, добавления дефолтного маршрута.

нашел в чем дело:
когда пропадает связь с удаленным офисом, в сети пропадает маршрут в удаленный офис, соответственно все пакеты отсылаются по маршруту по умолчанию (на файрвол, который смотрит в инет) и фря добавляет себе в таблицу маршрутизации маршрут для ip сервера СКО на файрвол, а не маршрутизатор. почему появляется этот маршрут на фре, как это можно предотвратить?
зы. сори если невнятно описал ситуацию, вчера отметили НГ на работе, сегодня голова туго варит

у маршрута есть флаг D, то есть он создается динамически при помощи перенаправления (в линуксе у меня такие маршруты не появляются). как можно выключить этот "наворот"? это должно решить проблему.

но все равно остается открытым вопрос: почему пинг с фри проходит, а с SCO и nPort'a нет?

а трасса как идет?

нашел как отключить:
icmp_drop_redirect="YES"
буду следить, о результатах сообщу

прошло 6 дней, пока жалоб не было.