dr Tr0jan Опубликовано 24 августа, 2018 · Жалоба Предыстория Имеется сетка (упрощённо на картинке). В роли коммутатора был установлен SNR-S2940-8G-POE. Однажды (может даже с момента установки камер, никто уже и не вспомнит) возникла проблема с пропаданием кадров (и соответственно пакетов) на камере 1 и 2. На камере 3 и 4 (другой вилан, другие камеры) проблем нет. На графике. Кабели отзвонили флюком, сами камеры проверили на стенде. Всё отлично. Однако периодически (около десятка раз в сутки) возникают потери пакетов (пингую с 192.168.2.200). В среднем около 0.5%. Ошибок на портах нет. Собственно описание проблемы Меняю наговский коммутатор на Catalyst 2950 (12.2.58 SE2), т.к. там статистика по-удобнее. Потери пакетов прекратились. Однако исследование на этом не прекращаю. Завожу мониторинг портов в Заббикс и обнаруживаю, что примерно с такой же периодичностью на всех клиентских портах возникают бёрсты траффика на отправку, причём по всем портам (на графике). Вешаю RSPAN на Fa0/1 и обнаруживаю, что в момёнт бёрстов с порта на камеру десять секунд начинает литься левый юникаст траффик (например, с 192.168.100.189 льётся на 192.168.100.10 UDP/6154, около 1200 пакетов). Как это возможно? CAM же не позволит этого делать. Мало того, подобная проблема наблюдается не только на этом коммутаторе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 24 августа, 2018 (изменено) · Жалоба А не пытались промониторить, что происходит с таблицей выученных мак-адресов в момент проблемы? Есть предположение, что происходит нечто, приводящее к сбросу этой самой таблицы (типа перестроения дерева STP). И пока таблица вновь не заполнится, возможны подобные чудеса с отправкой юникаста не в тот порт. Изменено 24 августа, 2018 пользователем azhur Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dr Tr0jan Опубликовано 24 августа, 2018 (изменено) · Жалоба @azhur, пробовал. Однако, таблица по SNMP собирается около 20 секунд, а сама проблема наблюдается 10 секунд. Явных изменений таблицы за минуту до и после бёрстов не замечено. Да и в логах по всей сети нет ничего похожего на STP. Хотя... topology last change occurred по времени как-раз совпадает с крайним бёрстом. Пойду ковырять. Изменено 24 августа, 2018 пользователем dr Tr0jan Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dr Tr0jan Опубликовано 24 августа, 2018 · Жалоба Да, точно оно. На другом краю сети, есть каталист за неуправляемым SHDSL-каналом, который, падая, периодически вызывает TCN. Т.к. за каналом следить невозможно, то и в логи это событие не попадало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 30 августа, 2018 · Жалоба 1) как вариант switchport block unicast 2) вообще вы уверены что вам нужен STP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dr Tr0jan Опубликовано 30 августа, 2018 (изменено) · Жалоба @Telesis, проблема решилась включёнием portfast'а на порту в сторону проблемного коммутатора. По предложениям: 1) switchport block unicast - блокирует входящий unicast, у меня же был исходящий. 2) нужен ли мне STP - не уверен, но с ним как-то надёжней. Зато, в рамках решения это проблемы нашёл два таких коммутатора. Изменено 30 августа, 2018 пользователем dr Tr0jan Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 30 августа, 2018 · Жалоба 8 minutes ago, dr Tr0jan said: 1) switchport block unicast - блокирует входящий unicast, у меня же был исходящий. ну так на аплинках его ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 30 августа, 2018 · Жалоба Если к проблемному коммутатору идёт только 1 линк, как вариант - включить bpdufilter на порту, к которому он подключен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dr Tr0jan Опубликовано 30 августа, 2018 · Жалоба @Telesis @azhur, господа, зачем такие сложности, если portfast всё решает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 30 августа, 2018 · Жалоба потому, что это лишь временное решение. в следующий раз прилетит из другого места. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dr Tr0jan Опубликовано 30 августа, 2018 · Жалоба 1 hour ago, azhur said: как вариант - включить bpdufilter на порту, к которому он подключен. А вот хрен там, сегодня днём прилетел TCN с порта на котором spanning-tree bpdufilter enable. 12 minutes ago, Telesis said: потому, что это лишь временное решение. в следующий раз прилетит из другого места. Насколько я понял, не каждый topology change приводит к unknown unicast flood. Однако, любое topology change на сети - это уже повод обратить внимание. Одно дело, когда topology change происходит десяток раз в сутки, другое дело, когда это происходит во время аварии или во время регламентных работ. В SLA укладывается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 30 августа, 2018 · Жалоба долгие годы показали, что STP сулит больше проблем чем пользы. в общем у себя на сети его выпилили уже лет 8 как. unknown unicast flood - может быть из-за большого arp-cache. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...