Перегруз CPU коммутаторов DLink

[roma33rus]

Всем привет. Имеется сеть из коммутаторов DLink, 3200 серия, 3120, 3420, на данный момент всего 4 менеджмент влана под них выделено.

Время от времени на некоторых коммутаторах сети происходит такая картина:

 

Загрузка CPU в полке, увеличение задержек и скачок непонятного трафика.

В логах коммутатора идет постоянный перевыбор корневого коммутатора STP:

Скрытый текст

1285  2020-05-06 22:20:47 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1284  2020-05-06 22:19:49 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1283  2020-05-06 22:19:49 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1282  2020-05-06 22:19:22 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1281  2020-05-06 22:19:22 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1280  2020-05-06 22:18:15 Safeguard Engine enters EXHAUSTED mode
1279  2020-05-06 22:18:10 Safeguard Engine enters NORMAL mode
1278  2020-05-06 22:18:08 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1277  2020-05-06 22:18:08 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1276  2020-05-06 22:17:54 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1275  2020-05-06 22:17:54 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1274  2020-05-06 22:16:59 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1273  2020-05-06 22:16:59 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1272  2020-05-06 22:15:53 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1271  2020-05-06 22:15:53 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1270  2020-05-06 22:15:01 Safeguard Engine enters EXHAUSTED mode
1269  2020-05-06 22:14:56 Safeguard Engine enters NORMAL mode
1268  2020-05-06 22:14:54 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1267  2020-05-06 22:14:54 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1266  2020-05-06 22:14:47 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)
1265  2020-05-06 22:14:47 New Root bridge selected (Instance:0 MAC:28-10-7B-F9-6
                          5-30 Priority:32768)
1264  2020-05-06 22:14:16 Safeguard Engine enters EXHAUSTED mode
1263  2020-05-06 22:14:11 Safeguard Engine enters NORMAL mode
1262  2020-05-06 22:14:09 New Root bridge selected (Instance:0 MAC:C0-A0-BB-3B-4
                          4-00 Priority:4096)

 

Мак адрес 28:10:7B:F9:65:30, который фигурирует в логах, это мак самого коммутатора, то есть он сам себя корневым выбирает. Как по умному найти это узкое место? может ли это значит, что где-то линк между коммутаторами барахлит и заставляет перестраиваться топологию, тем самым создавая мусорный трафик?

Edited May 8, 2020 by roma33rus

[TriKS]

10 минут назад, roma33rus сказал:

постоянный перевыбор корневого коммутатора STP

Если не используете - отключите.

[roma33rus]

 

2 минуты назад, TriKS сказал:

Если не используете - отключите.

STP как раз используем

[TriKS]

тогда смотрите, почему идет перестройка STP топологии. Может линк где флапает, может еще что, типа BPDU не пролазят\дропаются.

 

Edited May 8, 2020 by TriKS

[roma33rus]

1 час назад, TriKS сказал:

тогда смотрите, почему идет перестройка STP топологии. Может линк где флапает, может еще что, типа BPDU не пролазят\дропаются.

 

Да я путем чтения логов вышел на пару наших STP колец. В этих двух кольцах идет постоянное перестроение, и постоянное изменение STP статуса порта, то на Learning, то на Forwarding. Когда-то было такое, когда линк падал (порт гасился), а сейчас порты не падают. Может просто где-то качество линии плохое и бывают такие коллизии?

[roma33rus]

И еще нужна критика моих настроек stp портов:

1. абонентский порт config stp ports 28 state disable fbpdu disable restricted_role true restricted_tcn true p2p false edge true

2. Аплинк порт к другому коммутатору config stp ports 17 state enable fbpdu enable restricted_role false restricted_tcn false p2p auto edge false

 

еще на абонентских портах включено bpdu_protection

Edited May 8, 2020 by roma33rus

[roma33rus]

И вообще не может ли быть такое, что в одном stp сегменте уже коммутаторов много и они начинают с ума сходить?

 

Или просто может перестроение топологии это не причина, а следствие какой-то другой проблемы?

Edited May 8, 2020 by roma33rus

[[anp/hsw]]

1 час назад, roma33rus сказал:

что в одном stp сегменте уже коммутаторов много и они начинают с ума сходить?

По-хорошему у вас их больше десятка со включеным stp быть не должно. Но если все же вдруг, то накрутите STP priority так, чтобы наиболее близкий к ядру коммутатор всегда главным и выбирался.

А также следите, чтобы на портах не было перегруза - BPDU трафик может пропадать наравне с остальным из-за банальной перегрузки порта.

 

[roma33rus]

2 часа назад, [anp/hsw] сказал:

По-хорошему у вас их больше десятка со включеным stp быть не должно. Но если все же вдруг, то накрутите STP priority так, чтобы наиболее близкий к ядру коммутатор всегда главным и выбирался.

А также следите, чтобы на портах не было перегруза - BPDU трафик может пропадать наравне с остальным из-за банальной перегрузки порта.

 

Забыл указать, что у меня rstp, а не обычный stp. И в сети уже давно намного больше 10 устройств, где включен rstp. Ранее все исправно было. И такие всплески нагрузок непостоянны. Все-таки думаю, что перестроение топологии идет из-за перегрузки проца коммутатора. Он же не успевает обработать bpdu и тут начинается. А нагрузку на коммутаторы мы когда-то ловили из-за роутеров длинк, которые рассылали пакеты dhcp v6. Такая же может быть картина? Вопрос только как найти тот узел, который мусорит в сеть?

[[anp/hsw]]

10 часов назад, roma33rus сказал:

Все-таки думаю, что перестроение топологии идет из-за перегрузки проца коммутатора.

Ну так зафильтруйте все лишнее:

http://www.dlink.ru/ru/faq/62/209.html

 

10 часов назад, roma33rus сказал:

Вопрос только как найти тот узел, который мусорит в сеть?

Допустим, вы его нашли и заменили. Через неделю появляется другой. Опять искать будете?

 

[PumpIT]

У нас такое было из-за lldp бывало свичи вешались намертво.

[nemo_lynx]

Почему не хотите ERPS использовать вместо RSTP?

[roma33rus]

В 09.05.2020 в 05:26, [anp/hsw] сказал:

Ну так зафильтруйте все лишнее:

http://www.dlink.ru/ru/faq/62/209.html

 

 

Зафильтровать? Разве коммутатор не умрет от того, если будет фильтровать эти же мусорные пакеты?

 

В 09.05.2020 в 05:26, [anp/hsw] сказал:

Допустим, вы его нашли и заменили. Через неделю появляется другой. Опять искать будете?

 

 

Тут Вы правы конечно. По правильному от такого надо просто защититься.

 

17 часов назад, bkdipnet сказал:

У нас такое было из-за lldp бывало свичи вешались намертво.

 

Так, а вот это интересно. Как с этим боролись? Мы тоже LLDP активно используем.

 

3 часа назад, nemo_lynx сказал:

Почему не хотите ERPS использовать вместо RSTP?

 

Читал про эту фичу. Никогда с ней не работал. Да и страшновато как-то переводить столько коммутаторов разом на erps. Или там все реально сделать плавно, не вырубая везде rstp?

[[anp/hsw]]

1 час назад, roma33rus сказал:

Разве коммутатор не умрет от того, если будет фильтровать эти же мусорные пакеты?

Фильтр - аппаратный, в отличие от обработчика пакетов на более высоком уровне.

 

 

[VolanD666]

3 часа назад, roma33rus сказал:

Читал про эту фичу. Никогда с ней не работал. Да и страшновато как-то переводить столько коммутаторов разом на erps. Или там все реально сделать плавно, не вырубая везде rstp?

+100500 за ERPS. Попробуйте тестовое кольцо, зачем все сразу то переводить?

[roma33rus]

19 часов назад, [anp/hsw] сказал:

Фильтр - аппаратный, в отличие от обработчика пакетов на более высоком уровне.

 

Понял, это хорошо. Получается разрешаем что мы на коммутаторе используем (stp, lldp, snmp) и все остальное запрещаем?

 

17 часов назад, VolanD666 сказал:

+100500 за ERPS. Попробуйте тестовое кольцо, зачем все сразу то переводить?

То есть на сети вполне можно держать и rstp и erps?

[VolanD666]

Только что, roma33rus сказал:

То есть на сети вполне можно держать и rstp и erps?

Ну в принципе да. Почитайте пр оERPS соберите тестовый стенд и придумайте как перевести свою сеть безболезненно.

[roma33rus]

10 минут назад, VolanD666 сказал:

Ну в принципе да. Почитайте пр оERPS соберите тестовый стенд и придумайте как перевести свою сеть безболезненно.

 

Спасибо. Стоит попробовать. Только сначала надо с текущей проблемой разобраться и закрыть ее.

[[anp/hsw]]

50 минут назад, roma33rus сказал:

Получается разрешаем что мы на коммутаторе используем (stp, lldp, snmp) и все остальное запрещаем?

Да, именно так. Хотя это не спасет от мусорного stp-трафика и прочих подобных вещей.

 

[roma33rus]

5 часов назад, [anp/hsw] сказал:

Да, именно так. Хотя это не спасет от мусорного stp-трафика и прочих подобных вещей.

 

Хорошо. попробую.

 

 

Есть вопрос по rstp.  Достаточно ли в топологии rstp указать главному свичу самый наивысший приоритет? Или и региональным только приоритет лучше увеличить? У меня сейчас главному свичу Instance Priority выставлен в 4096, а всем остальным по умолчанию в 32768. Да и вообще может мне таймеры stp подкрутить?

Edited May 13, 2020 by roma33rus

[roma33rus]

Почитал вчера вкратце про ERPS. Эта фича же работает только на кольце? у нас топология дерево и по сети раскидано несколько колец. Будет ли это рентабельно на такой схеме сети? И там идет уже жесткая привязка к аплинк и даунлинк портам?

[[anp/hsw]]

18 часов назад, roma33rus сказал:

Достаточно ли в топологии rstp указать главному свичу самый наивысший приоритет?

В идеале приоритеты у всех должны быть расставлены. В реале достаточно двух - основной и запасной.

В чем вообще вся трагичность ситуации: если в сети начинаются выборы, и у всех коммутаторов одинаковый приоритет, то они начинают мучительно перебирать данные о связности, и затем вносить корректировки, чтобы узнать, кто из них главным будет. Обычно такой выбор получается случайным, и каждое следующее перестроение опять начинает выборы сначала.

В случае же, когда жестко установлены приоритеты main и backup свичей (может быть и больше двух, если там не кольцо, а месиво из линков), то выборы пройдут легко, и перестраивать всю топологию не придется (т.к. и main и backup были известны заранее). Т.е. даже если кольцо порвется в двух местах, и двумя половинками будет подключено к ядру, перевыборов не будет. Перевыборы будут только в сегменте, который останется совсем без связи с центром.

 

[roma33rus]

23 минуты назад, [anp/hsw] сказал:

В идеале приоритеты у всех должны быть расставлены. В реале достаточно двух - основной и запасной.

В чем вообще вся трагичность ситуации: если в сети начинаются выборы, и у всех коммутаторов одинаковый приоритет, то они начинают мучительно перебирать данные о связности, и затем вносить корректировки, чтобы узнать, кто из них главным будет. Обычно такой выбор получается случайным, и каждое следующее перестроение опять начинает выборы сначала.

В случае же, когда жестко установлены приоритеты main и backup свичей (может быть и больше двух, если там не кольцо, а месиво из линков), то выборы пройдут легко, и перестраивать всю топологию не придется (т.к. и main и backup были известны заранее). Т.е. даже если кольцо порвется в двух местах, и двумя половинками будет подключено к ядру, перевыборов не будет. Перевыборы будут только в сегменте, который останется совсем без связи с центром.

 

 

ага. принцип примерно понял. тогда при моей топологии дерево, лучше расставить приоритеты хотя бы основным районым свичам (как Вы сказали, где месиво из линков), что ниже ядра, все правильно? 

[[anp/hsw]]

7 минут назад, roma33rus сказал:

расставить приоритеты хотя бы основным районым свичам

Да, чем ближе к ядру, тем приоритетнее свич должен быть.

 

[roma33rus]

1 час назад, [anp/hsw] сказал:

Да, чем ближе к ядру, тем приоритетнее свич должен быть.

 

 

Спасибо, стоит попробовать.