|
Есть похожая проблема с DGS-3627G. В непонятные моменты времени пропадает часть маршрутизации на L3. В лучшем случае перестает пинговатся из сети один-два клиента, в худшем - до 70% все IP адресов сети.
Очень похоже, как описано в темах выше по постам. В частности перестают пинговатьсся остальные свичи сети. Клиенты начинаю звонить позже.
1. Протекание болезни.
Если пинговать пропавший IP адрес из любого участка сети (кроме того, где этот адрес доступен по L2), то пинга нет (и любого доступа тоже). Причем на свич отправляется правильный пакет, а к адресату ничего не доходит. От адресата иногда приходят некоторые пакеты. НО. если зайти на консоль свича, то весь диапазон пропавших адресов пингуетсе без проблем. В fdb и arp таблицах все ок. Загрузка свича в норме. Утилизация портов как обычно. Количество МАС и АРП - до 3 000. Периодичность - а как захочется. Нет зависимости от загрузки сети, фазы луны, выплаты зарплаты админам. Последний раз пропало в 3 ночи.
Как правило сначала пропадает пинг к остальным свичам и различным устройствам (датчики вибрации, доступа и т.д.). Потом начинают звонить клиенты. Но не все. Примерно 10%. У остальных проблеми в доступе к сервису не наблюдаются. Не помагают ребуты свичей доступа и агрегации. Передергивание линков на L3 свиче - тоже.
2. Лечение симптомов
clear arptable - решает все. Правда в момент выполнение команды модет пропать до 1-2 пингов у всех, но зато все работает. Включил в cron на 6 утра - и забыл - нет проблем. Но, падлюка, пару раз пропала вся L3 в 23-24 ночи. Надо что-то решать. Не дергать же clear arptable каждый час?
3. Оценка причин
Создается впечатление (подтвержденное постами сведущих товарищей), что в свиче есть две таблицы arp. Одна на уровне софта, которую видно по каманде show arpentry, и другая, наверное аппаратная, которую не видно простым смертным. Там хеш и все дела. И это правильно. Наверное софт время от времени синхронизирует две таблицы. И когда L3 не работает, то проблемы с таблицей которую не видно - аппаратной, а с софтовой все ок. Заставить их синхронизироватся окромя как через ребут свича или clear arptable - я не знаю как.
Время жизни записи в таблице по умолчанию - 20 минут. Изменение этого числа не привела в изменению синопсиса вообще.
Когда же обновляюся записи в таблице? Однозначно запись создается по arp is at. А обновляется? Ясное дело что не по MAC каждого пакета по известной связке arp. Где-то читал, что таблица, например, во FreeBSD, должна обновлятся исключительно по arp is at и только на запрос who has. И при каждом случае использования этой связки при отправке пакетов. Но. Давайте предположим, что в нашем свиче по arp is at обновление происходит, а по каждому факту использование нет. Точнее происходит, но не для каждого пакета. Накладно, наверное. Допустим что для каждого сотого или раз в секунду. Уборка мусора, похоже апаратно и програмно реализована паралельно. Скорее всего связка убирается из апаратного чипа самостоятельно. В идеале в тот-же момент времени эта-же связка должна пропадать и из софтовой таблице. Тогда свич спросит who has, и обновит все свои две таблицы.
Допустим, что в следствии непонятных причин: например свич был очень занят, запись в аппаратной таблице умерла, а в софтовой нет. Все приходящие пакеты из умершей связки будут комутироватся (на самом деле не всегда, т.к. апаратно этот трафик, скорее всего, расценивается как "не локальный", не помню точно как, есть такой тип в traffic control). А вот с исходящими - беда. Куда отсылать свичу - аппаратно - неясно. Тут бы програмная часть сформировала пакет who has, но програмно эта запись есть. И может даже обновится ее считчик жизни.
Когда есть время (например проблемы только у одного клиента), то помагает вообще клиетну потушисть свое оборудование больше чем на 20 минут (при отсутствии входящего трафика) и тогда софтовая запись тоже умрет и все будет ок. Даже не подозреваю, сколько клиентов имели какие проблемы. Но они автоматически восстанавливали работу на утро, например. Обзваниваешь заявки про неисправность - в 5-10% все уже ок. Ну, думаешь, вирусы, солнечная активность. А может быть и 3627G. Кто ж знает.
Все тут зависит от алгоритма работы на 0х806 протоколе клиента. Видно, часть роутеров, я так подозреваю, начинает самостоятельно рассылать is at пакеты, даже когда никто не спрашивает, и этим лечит ситуацию. Но специфичиске устройства, типа наших свичей доступа, и некоторые клиенты из особо правильных - никогда не скажут is at если не спросили. А их и не спрашивают. Dead lock.
4. Потенциальные виновники проблем
После долгих и безутешных поисков причин есть один подозреваемый. Multicast. Похоже, что случайно был направлен тегированый multicast поток на 15 тис. пакетов/сек на порт, где он попадал на default vlan. Причем на свиче не включены igmp snooping и т.д., т.к. там вообще не должно было быть мультикаста. Наверное (очень хочется верить), мультикастовый поток или занимал всю аппаратную таблицу или перегружал чип. Вследствии чего или не создавались аппаратные записи arp или умирали рано.
Пока жду. Будут ли проблемы.
P.S. Вспомнилось. Такое же поведение было и лет 10 назад на DES-3828. Я начал было грешить на железо - поменал - все так-же. Там проблема проявлялась уже при 600-800 arp.
|
Вход
Регистрация
FAQ
Поиск
