Здравствуйте!

В ходе включения ERPS, устроили петлю в кольце из 3-х устройств. Это была ошибка, один из VLAN был не защищен, тот, в котором IP адреса управления этих свитчей.

Свитчи DGS-3200-24, DGS-3200-16, DES-3528

Однако, последствия странные:

Не смотря на настройки storm-comtrol на смежных портах всех свитчей в кольце, они стали недоступны по управлению. Значение storm-comtrol - 10240 Kbps (для DGS и 1024 pps для DES, кстати, это не ошибка, что измеряются в разном?) Включен для broadcast, unknown unicast.
Процессор не выдерживает такое кол-во пакетов? До какого значения рекомендуется снизить, или как его защитить?
И в логи ничего про traffic-control не писало, хотя настроено Traffic Log Settings = enable.

Да, multicast фильтра не было, мог IPv6 пакет туда попасть.

Но самое главное другое - 3200-24 под воздействием этой петли устроил петлю во всех других VLANах, через него проходящих. Эти VLAN не были проложены по пути устноенной петли.
Связь по этим VLAN практически прекратилась (более 95% дропов пакетов).

Факт прыганья MACов в них был виден на Cisco, подключенной к этому свитчу по etherchannel.
Циска показывала, что они прыгали между составляющими etherchannel.

Получается, что прчина в том, что etherchannel развалился с обоих сторон и с обоих сторон стал представлять из себя пару раздельных портов , и образовалась петля!
Про Cisco я знаю, что в случае отключения LACP с другой стороны, она, увы, так себя ведет.

А вот почему DGS-3200-24 уронил LACP?
Из за высокой нагрузки на процессор?
И неужели он тоже при поломке LACP не блокирует порты, а включает из как независимо свитчуемые?

В общем, ситуация получилась очень неприятная, хочется узнать, как от такого можно защититься.

3200-24 входил в режим Safeguard, остальные, почему-то, нет.
Кроме этого, ничего интересного в его логах нет. Как будто и петли не было.

Ещё вопрос - как включить traffic control на портах, входящих в etherchannel. Не получается. А, возможно, помогло бы в подобны случаях.

Уберечься от такой ситуации можно верно настроив ERPS.
Также замечу, что служебные пакеты ERPS - это мультикаст, от которого у вас не был включен traffic control.

Ну а с рассыпанием etherchannel что можно сделать?
Чтобы петля в одном VLAN затрагивала другие - это просто жуть.



ERPS ведь не должен их рассылать во VLAN,с ним не связанных? Только в A-RPS. А этот VLAN должен ведь идти по кольцу и ERPS сам контролирует распространение пакетов там. Не так ли?

Кстати, вообще рекомендуется ли использовать ERPS, или он не оттестирован? (в веб-интерфейсе его вообще нет).

Сейчас у вас в чем, собственно, проблема? У вас ERPS не работает или при его работе служебные пакеты сыпятся в другие vlan? Опишите, пожалуйста, какой функционал у вас не работает или работает неправильно по вашему мнению, с конфигами коммутаторов и описанием этой неправильной работы по пунктам, чтобы ситуацию можно было протестировать на стенде и выдать какое-то резюме.

На каком основании опять удаляют мои сообщения? Что я нарушил.

Я даю свою оценку фукнции ERPS, traffic control.....

Добрый день!

Куда можно выслать данные (с учетом их конфиденциальности) ?

Проблеме вот в чем:
(От ERPS и прочего можно абстрагироваться)

При создании петли в одном из VLAN (в котором также IP управления коммутаторами), начинается петля в других VLAN.
Возможно, из за перехода port-channel (не участвующего в пути первоначальной петли) в независимые два порта (что само по себе опасная "фича").
Так как в логах ничего нет, реальную причину этого назвать сложно.

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

Я вам рекомендую настроить loopdetect для того, чтобы петель у вас не было. То, что от очень высокой загрузки cpu у вас разваливается lacp и, как следствие, начинает штормить другие vlan - не первопричина. Причина в том, что у вас не отловилась петля - и именно эту проблему вам нужно решать правильными настройками loopdetect и протоколов, которые от образования петель защищают.

Спасибо!
Самое интересное, что на port-channel, где возникли вторичные петли, был включен loopback detection (LD). Почему же он не помог?

На тех, где первичная петля возникла -да, не был настроен.

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

Мы планируем попробовать ERPS. Стоит ли с ним включать также LD?

Что касается нагрузки на CPU.
Судя по тому, что safeguard переходит в EXHAUSTED состояние даже от логина по SSH (порог настроен 75%), есть опасение, что разваливание port-channel может произойти и по другим причинам.

А есть ли защита от этого? (блокировать порты, которые выходят из port-channel).

Ещё хочется использовать storm-control, но он не включается на агрегатах, описал в отдельной теме viewtopic.php?f=2&t=157403

Без комментариев.



На магистральных портах используйте RSTP или ERPS в зависимости от топологии.
Сейчас, конечно, функционал LBD доводится до версии 4.04 с возможностью обнаружения петель между портами разных коммутаторов, но это тема отдельного обсуждения.

Еще раз напишу то, что уже десятки раз писалось на этом форуме: на клиентских портах включается lbd, на магистральных - rstp, erps и другие протоколы защиты магистрали

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



Я это знаю, показалось, что loopdetect в этой теме был предложен для всех портов. Видимо, имелся в виду в более широком смысле.

Спасибо.

Может уважаемый народ посоветовать рекомендуемый CPU ACL для защиты control plane ?
Есть ощущение, что петля так повлияла именно из за того, что она в VLAN управления, и на CPU свитча выливалось слишком много запросов.

Правила ACL limit по идее должны помочь.