Jump to content
Калькуляторы

Catalyst шлёт трафик не туда

Предыстория

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

switch-flood-bursts.thumb.png.9889a806440365ba1a5e470bc12a0824.png

В роли коммутатора был установлен SNR-S2940-8G-POE. Однажды (может даже с момента установки камер, никто уже и не вспомнит) возникла проблема с пропаданием кадров (и соответственно пакетов) на камере 1 и 2. На камере 3 и 4 (другой вилан, другие камеры) проблем нет. На графике. Кабели отзвонили флюком, сами камеры проверили на стенде. Всё отлично. Однако периодически (около десятка раз в сутки) возникают потери пакетов (пингую с 192.168.2.200). В среднем около 0.5%. Ошибок на портах нет.

snr-losses.thumb.png.b950a44da3ff76cc8dc84dff2657a917.png

 

Собственно описание проблемы

Меняю наговский коммутатор на Catalyst 2950 (12.2.58 SE2), т.к. там статистика по-удобнее. Потери пакетов прекратились. Однако исследование на этом не прекращаю. Завожу мониторинг портов в Заббикс и обнаруживаю, что примерно с такой же периодичностью на всех клиентских портах возникают бёрсты траффика на отправку, причём по всем портам (на графике). Вешаю RSPAN на Fa0/1 и обнаруживаю, что в момёнт бёрстов с порта на камеру десять секунд начинает литься левый юникаст траффик (например, с 192.168.100.189 льётся на 192.168.100.10 UDP/6154, около 1200 пакетов). Как это возможно? CAM же не позволит этого делать. Мало того, подобная проблема наблюдается не только на этом коммутаторе.

cisco-tx-bursts.thumb.PNG.800f9a07411278fd309b499112b291dc.PNG

Share this post


Link to post
Share on other sites

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

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

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

Edited by azhur

Share this post


Link to post
Share on other sites

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

 

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

Edited by dr Tr0jan

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Edited by dr Tr0jan

Share this post


Link to post
Share on other sites
8 minutes ago, dr Tr0jan said:

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

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 укладывается.

Share this post


Link to post
Share on other sites

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

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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this