[dr Tr0jan]

Предыстория

Имеется сетка (упрощённо на картинке).

В роли коммутатора был установлен 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 же не позволит этого делать. Мало того, подобная проблема наблюдается не только на этом коммутаторе.

[azhur]

А не пытались промониторить, что происходит с таблицей выученных мак-адресов в момент проблемы?

Есть предположение, что происходит нечто, приводящее к сбросу этой самой таблицы (типа перестроения дерева STP).

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

Изменено 24 августа, 2018 пользователем azhur

[dr Tr0jan]

@azhur, пробовал. Однако, таблица по SNMP собирается около 20 секунд, а сама проблема наблюдается 10 секунд. Явных изменений таблицы за минуту до и после бёрстов не замечено. Да и в логах по всей сети нет ничего похожего на STP.

 

Хотя... topology last change occurred по времени как-раз совпадает с крайним бёрстом. Пойду ковырять.

Изменено 24 августа, 2018 пользователем dr Tr0jan

[dr Tr0jan]

Да, точно оно. На другом краю сети, есть каталист за неуправляемым SHDSL-каналом, который, падая, периодически вызывает TCN. Т.к. за каналом следить невозможно, то и в логи это событие не попадало.

[Telesis]

1) как вариант switchport block unicast

2) вообще вы уверены что вам нужен STP?

 

[dr Tr0jan]

@Telesis, проблема решилась включёнием portfast'а на порту в сторону проблемного коммутатора.

По предложениям:

1) switchport block unicast - блокирует входящий unicast, у меня же был исходящий.

2) нужен ли мне STP - не уверен, но с ним как-то надёжней.

 

Зато, в рамках решения это проблемы нашёл два таких коммутатора.

Изменено 30 августа, 2018 пользователем dr Tr0jan

[Telesis]

8 minutes ago, dr Tr0jan said:

1) switchport block unicast - блокирует входящий unicast, у меня же был исходящий.

ну так на аплинках его ;)

[azhur]

Если к проблемному коммутатору идёт только 1 линк, как вариант - включить bpdufilter на порту, к которому он подключен.

 

[dr Tr0jan]

@Telesis @azhur, господа, зачем такие сложности, если portfast всё решает?

[Telesis]

потому, что это лишь временное решение. в следующий раз прилетит из другого места.

[dr Tr0jan]

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 укладывается.

[Telesis]

долгие годы показали, что STP сулит больше проблем чем пользы.

в общем у себя на сети его выпилили уже лет 8 как.

unknown unicast flood - может быть из-за большого arp-cache.