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

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

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

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

Screenshot_1.thumb.jpg.1a2c87d85c87ef1aa51a5ddb84a502fa.jpg

Screenshot_2.thumb.jpg.059e4ef9f0c6c18b0e7685e96ab71758.jpg

Screenshot_3.thumb.jpg.fb4583446fe27c2a947d9ac6d5268b7f.jpg

 

Загрузка 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 by roma33rus

Share this post


Link to post
Share on other sites
10 минут назад, roma33rus сказал:

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

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

Share this post


Link to post
Share on other sites

 

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

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

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

Share this post


Link to post
Share on other sites

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

 

Edited by TriKS

Share this post


Link to post
Share on other sites
1 час назад, TriKS сказал:

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

 

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

Share this post


Link to post
Share on other sites

И еще нужна критика моих настроек 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 by roma33rus

Share this post


Link to post
Share on other sites

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

 

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

Edited by roma33rus

Share this post


Link to post
Share on other sites
1 час назад, roma33rus сказал:

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

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

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

 

Share this post


Link to post
Share on other sites
2 часа назад, [anp/hsw] сказал:

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

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

 

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

Share this post


Link to post
Share on other sites
10 часов назад, roma33rus сказал:

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

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

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

 

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

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

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
В 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?

Share this post


Link to post
Share on other sites
1 час назад, roma33rus сказал:

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

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

 

 

Share this post


Link to post
Share on other sites
3 часа назад, roma33rus сказал:

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

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

Share this post


Link to post
Share on other sites
19 часов назад, [anp/hsw] сказал:

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

 

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

 

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

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

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

Share this post


Link to post
Share on other sites
Только что, roma33rus сказал:

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

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

Share this post


Link to post
Share on other sites
10 минут назад, VolanD666 сказал:

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

 

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

Share this post


Link to post
Share on other sites
50 минут назад, roma33rus сказал:

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

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

 

Share this post


Link to post
Share on other sites
5 часов назад, [anp/hsw] сказал:

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

 

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

 

 

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

Edited by roma33rus

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
18 часов назад, roma33rus сказал:

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

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

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

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

 

Share this post


Link to post
Share on other sites
23 минуты назад, [anp/hsw] сказал:

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

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

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

 

 

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

Share this post


Link to post
Share on other sites
7 минут назад, roma33rus сказал:

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

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

 

Share this post


Link to post
Share on other sites
1 час назад, [anp/hsw] сказал:

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

 

 

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

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