Прошлая неделя доказала, что я настоящая Кассандра: я всегда говорил, что иметь только один брандмауэр / маршрутизатор без резервного копирования или переключения при отказе - плохая идея. Таким образом, наш Cisco PIX вышел из строя, отказываясь правильно маршрутизировать. И, конечно же, единственный, кто доступен здесь в кратчайшие сроки, - это я, и хотя я достаточно знаком с Linux, на самом деле я разработчик, а не системный администратор (тот факт, что это поразило меня в день признательности системного администратора, немного иронично) .
Как бы то ни было, в эти выходные я попытался взломать временное решение: я использовал старый сервер с достаточным количеством сетевых адаптеров (два встроенных, четыре на карте), которые служили шлюзом и межсетевым экраном. Из-за некоторых проблем с рейд-контроллером у меня было запущено только два дистрибутива маршрутизатора, и между Untangle и Ebox я выбрал последнее.
Теперь все в порядке. У меня есть все разные подсети (все с отдельными коммутаторами), которые общаются друг с другом и даже с Интернетом (маршрутизатор Cisco 2800, линии T1). Но время от времени (с интервалом 20-60 минут) я получаю полный сбой маршрутизации. Наша основная офисная подсеть не может взаимодействовать с подсетью нашего сервера и не может подключиться к Интернету. Это не конец постепенного замедления, либо все работает отлично, либо каждый раз я получаю полное отсутствие связи примерно на две минуты.
Теперь я немного не понимаю, что проверить. По крайней мере, с настройкой EBox по умолчанию ничего в / var / log не показывает ничего странного, и в нем нет множества встроенных инструментов мониторинга. Так что я надеюсь, что кто-то здесь может дать мне несколько советов о том, на что обращать внимание. Я поменял кабель Ethernet с офисного коммутатора на брандмауэр, но безрезультатно. Я мог бы поменять переключатели, хотя внутри переключателя он вроде работает нормально.
редактировать: Я не уверен, является ли это единственной причиной проблемы, но после того, как я заметил несколько записей DHCP незадолго до последней капли подключения, я попытался воспроизвести это. И, увы, всякий раз, когда я обновляю DHCP-соединение, я больше не могу получить доступ к другим подсетям. Запуск ISC DHCPD 3.0.6.
20-60 секунд звучит как сходимость остовного дерева. Проверьте журналы коммутаторов (я предполагаю, что это управляемые коммутаторы) и выясните, что отключается / переключается, что вызывает конвергенцию. Если это устройство с одним кабелем, идущим к коммутатору, установите для этого коммутатора значение portfast. Или вы всегда можете докопаться до первопричины и выяснить, что вызывает включение и выключение порта. : D Удачи!
Обязательно проверьте dmesg (вывод команды, а не только в / var / log /). Я бы проверил netstat -s и сравнил его с различными ограничениями ip из "sysctl -a". Особенно, если вы используете NAT, вы можете достичь какого-то ограничения на подключение.
Вы можете попробовать настроить сценарий для получения дампа пакета на одном из интерфейсов во время простоя. Что-то вроде «while [1]; do ping -c 1 || tcpdump -s 0 -i eth0 -c 100; sleep 10; done»
Доступны ли обновления прошивки для ваших сетевых адаптеров? Если это очень старый сервер, возможно, проблемы с прерывистым подключением были решены в обновлении? По крайней мере, не помешало бы просмотреть любые примечания к выпуску прошивки, так что посмотрите, упоминается ли вообще такая проблема.
Также проверьте dmesg чтобы узнать, есть ли там что-нибудь, связанное с сетью. Некоторые драйверы иногда перестают отвечать из-за различных проблем, связанных с драйверами / картой.