roma33rus Опубликовано 8 мая, 2020 (изменено) · Жалоба Всем привет. Имеется сеть из коммутаторов 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, который фигурирует в логах, это мак самого коммутатора, то есть он сам себя корневым выбирает. Как по умному найти это узкое место? может ли это значит, что где-то линк между коммутаторами барахлит и заставляет перестраиваться топологию, тем самым создавая мусорный трафик? Изменено 8 мая, 2020 пользователем roma33rus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TriKS Опубликовано 8 мая, 2020 · Жалоба 10 минут назад, roma33rus сказал: постоянный перевыбор корневого коммутатора STP Если не используете - отключите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 8 мая, 2020 · Жалоба 2 минуты назад, TriKS сказал: Если не используете - отключите. STP как раз используем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TriKS Опубликовано 8 мая, 2020 (изменено) · Жалоба тогда смотрите, почему идет перестройка STP топологии. Может линк где флапает, может еще что, типа BPDU не пролазят\дропаются. Изменено 8 мая, 2020 пользователем TriKS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 8 мая, 2020 · Жалоба 1 час назад, TriKS сказал: тогда смотрите, почему идет перестройка STP топологии. Может линк где флапает, может еще что, типа BPDU не пролазят\дропаются. Да я путем чтения логов вышел на пару наших STP колец. В этих двух кольцах идет постоянное перестроение, и постоянное изменение STP статуса порта, то на Learning, то на Forwarding. Когда-то было такое, когда линк падал (порт гасился), а сейчас порты не падают. Может просто где-то качество линии плохое и бывают такие коллизии? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 8 мая, 2020 (изменено) · Жалоба И еще нужна критика моих настроек 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 Изменено 8 мая, 2020 пользователем roma33rus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 8 мая, 2020 (изменено) · Жалоба И вообще не может ли быть такое, что в одном stp сегменте уже коммутаторов много и они начинают с ума сходить? Или просто может перестроение топологии это не причина, а следствие какой-то другой проблемы? Изменено 8 мая, 2020 пользователем roma33rus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 8 мая, 2020 · Жалоба 1 час назад, roma33rus сказал: что в одном stp сегменте уже коммутаторов много и они начинают с ума сходить? По-хорошему у вас их больше десятка со включеным stp быть не должно. Но если все же вдруг, то накрутите STP priority так, чтобы наиболее близкий к ядру коммутатор всегда главным и выбирался. А также следите, чтобы на портах не было перегруза - BPDU трафик может пропадать наравне с остальным из-за банальной перегрузки порта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 8 мая, 2020 · Жалоба 2 часа назад, [anp/hsw] сказал: По-хорошему у вас их больше десятка со включеным stp быть не должно. Но если все же вдруг, то накрутите STP priority так, чтобы наиболее близкий к ядру коммутатор всегда главным и выбирался. А также следите, чтобы на портах не было перегруза - BPDU трафик может пропадать наравне с остальным из-за банальной перегрузки порта. Забыл указать, что у меня rstp, а не обычный stp. И в сети уже давно намного больше 10 устройств, где включен rstp. Ранее все исправно было. И такие всплески нагрузок непостоянны. Все-таки думаю, что перестроение топологии идет из-за перегрузки проца коммутатора. Он же не успевает обработать bpdu и тут начинается. А нагрузку на коммутаторы мы когда-то ловили из-за роутеров длинк, которые рассылали пакеты dhcp v6. Такая же может быть картина? Вопрос только как найти тот узел, который мусорит в сеть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 9 мая, 2020 · Жалоба 10 часов назад, roma33rus сказал: Все-таки думаю, что перестроение топологии идет из-за перегрузки проца коммутатора. Ну так зафильтруйте все лишнее: http://www.dlink.ru/ru/faq/62/209.html 10 часов назад, roma33rus сказал: Вопрос только как найти тот узел, который мусорит в сеть? Допустим, вы его нашли и заменили. Через неделю появляется другой. Опять искать будете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
PumpIT Опубликовано 11 мая, 2020 · Жалоба У нас такое было из-за lldp бывало свичи вешались намертво. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nemo_lynx Опубликовано 12 мая, 2020 · Жалоба Почему не хотите ERPS использовать вместо RSTP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 12 мая, 2020 · Жалоба В 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 12 мая, 2020 · Жалоба 1 час назад, roma33rus сказал: Разве коммутатор не умрет от того, если будет фильтровать эти же мусорные пакеты? Фильтр - аппаратный, в отличие от обработчика пакетов на более высоком уровне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 12 мая, 2020 · Жалоба 3 часа назад, roma33rus сказал: Читал про эту фичу. Никогда с ней не работал. Да и страшновато как-то переводить столько коммутаторов разом на erps. Или там все реально сделать плавно, не вырубая везде rstp? +100500 за ERPS. Попробуйте тестовое кольцо, зачем все сразу то переводить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 13 мая, 2020 · Жалоба 19 часов назад, [anp/hsw] сказал: Фильтр - аппаратный, в отличие от обработчика пакетов на более высоком уровне. Понял, это хорошо. Получается разрешаем что мы на коммутаторе используем (stp, lldp, snmp) и все остальное запрещаем? 17 часов назад, VolanD666 сказал: +100500 за ERPS. Попробуйте тестовое кольцо, зачем все сразу то переводить? То есть на сети вполне можно держать и rstp и erps? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 13 мая, 2020 · Жалоба Только что, roma33rus сказал: То есть на сети вполне можно держать и rstp и erps? Ну в принципе да. Почитайте пр оERPS соберите тестовый стенд и придумайте как перевести свою сеть безболезненно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 13 мая, 2020 · Жалоба 10 минут назад, VolanD666 сказал: Ну в принципе да. Почитайте пр оERPS соберите тестовый стенд и придумайте как перевести свою сеть безболезненно. Спасибо. Стоит попробовать. Только сначала надо с текущей проблемой разобраться и закрыть ее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 13 мая, 2020 · Жалоба 50 минут назад, roma33rus сказал: Получается разрешаем что мы на коммутаторе используем (stp, lldp, snmp) и все остальное запрещаем? Да, именно так. Хотя это не спасет от мусорного stp-трафика и прочих подобных вещей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 13 мая, 2020 (изменено) · Жалоба 5 часов назад, [anp/hsw] сказал: Да, именно так. Хотя это не спасет от мусорного stp-трафика и прочих подобных вещей. Хорошо. попробую. Есть вопрос по rstp. Достаточно ли в топологии rstp указать главному свичу самый наивысший приоритет? Или и региональным только приоритет лучше увеличить? У меня сейчас главному свичу Instance Priority выставлен в 4096, а всем остальным по умолчанию в 32768. Да и вообще может мне таймеры stp подкрутить? Изменено 13 мая, 2020 пользователем roma33rus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 14 мая, 2020 · Жалоба Почитал вчера вкратце про ERPS. Эта фича же работает только на кольце? у нас топология дерево и по сети раскидано несколько колец. Будет ли это рентабельно на такой схеме сети? И там идет уже жесткая привязка к аплинк и даунлинк портам? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 14 мая, 2020 · Жалоба 18 часов назад, roma33rus сказал: Достаточно ли в топологии rstp указать главному свичу самый наивысший приоритет? В идеале приоритеты у всех должны быть расставлены. В реале достаточно двух - основной и запасной. В чем вообще вся трагичность ситуации: если в сети начинаются выборы, и у всех коммутаторов одинаковый приоритет, то они начинают мучительно перебирать данные о связности, и затем вносить корректировки, чтобы узнать, кто из них главным будет. Обычно такой выбор получается случайным, и каждое следующее перестроение опять начинает выборы сначала. В случае же, когда жестко установлены приоритеты main и backup свичей (может быть и больше двух, если там не кольцо, а месиво из линков), то выборы пройдут легко, и перестраивать всю топологию не придется (т.к. и main и backup были известны заранее). Т.е. даже если кольцо порвется в двух местах, и двумя половинками будет подключено к ядру, перевыборов не будет. Перевыборы будут только в сегменте, который останется совсем без связи с центром. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 14 мая, 2020 · Жалоба 23 минуты назад, [anp/hsw] сказал: В идеале приоритеты у всех должны быть расставлены. В реале достаточно двух - основной и запасной. В чем вообще вся трагичность ситуации: если в сети начинаются выборы, и у всех коммутаторов одинаковый приоритет, то они начинают мучительно перебирать данные о связности, и затем вносить корректировки, чтобы узнать, кто из них главным будет. Обычно такой выбор получается случайным, и каждое следующее перестроение опять начинает выборы сначала. В случае же, когда жестко установлены приоритеты main и backup свичей (может быть и больше двух, если там не кольцо, а месиво из линков), то выборы пройдут легко, и перестраивать всю топологию не придется (т.к. и main и backup были известны заранее). Т.е. даже если кольцо порвется в двух местах, и двумя половинками будет подключено к ядру, перевыборов не будет. Перевыборы будут только в сегменте, который останется совсем без связи с центром. ага. принцип примерно понял. тогда при моей топологии дерево, лучше расставить приоритеты хотя бы основным районым свичам (как Вы сказали, где месиво из линков), что ниже ядра, все правильно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 14 мая, 2020 · Жалоба 7 минут назад, roma33rus сказал: расставить приоритеты хотя бы основным районым свичам Да, чем ближе к ядру, тем приоритетнее свич должен быть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roma33rus Опубликовано 14 мая, 2020 · Жалоба 1 час назад, [anp/hsw] сказал: Да, чем ближе к ядру, тем приоритетнее свич должен быть. Спасибо, стоит попробовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...