Здравствуйте! Возник вопрос по вышеуказанному коммутатору.
Версия прошивки 2.00.B023

Can not enable LBD on the port as it is STP enabled.

Почему так? С 3200 это можно понять, но на устройве агрегации мне пока что не понятно это. Ведь нужно бывает ловить петли с портов, на которых уже висят кольца.

Потому что STP не работает совместно с loopdetect на портах.
Поведение менять не планируется. Обсуждалось неоднократно.

Я помню обсуждение по поводу 3200, здесь нет вопросов. На клиентских портах loopdetect enable, stp disable. На магистральных наоборот. Все абсолютно логично. Но ведь с агрегацией иначе. Тут уже stp обязательно, так как у нас кольца, и получается агрегация вообще без loopdetect'a? Мотивы не понятны.

Я спрашиваю потому, что не нашел топиков по изменению в механизме lbd на свитчах агрегации и на dgs-3620 в частности.

На 3627 пока что работает (прошивка 2.84). Там тоже планируется менять поведение?

DGS-3420-26SC также работает, неудобно.

удобно на dgs-3100 там lbd присутствует в stp, но это не агрегация.

Представители ДЛинка так и не ответили на два самых интересных вопроса (или ответили где-то, но я не видел):
1. Чем было вызвано такое решение - раньше было вариантов с горкой - и lbd в stp, и сам loopdetect замечательно включался с stp, а теперь либо то, либо то? Есть ли техническое или логическое обоснование решения?
2. Как теперь ловить петли? Как писал vcvitaly - в сегменте возникла петля. Предположим, она возникла так, что на уровне доступа не отловилась. Как ловить ее в агрегации? Как локализовать? Тем более если она возникает рандомно и ненадолго? Полный перебор? Выключил, подождал, покурил?

1. Решение вызвано изменением работы механизма loopdetect
2. Предполагать можно многое. У вас есть конкретные примеры ситуаций? Приведите топологию с указанием, где возникает петля и почему она не поймается на доступе, подумаем, как можно проблему решить.

2. На самом деле, к счастью, пока остается только предполагать более серьезные ситуации. Из реального к примеру: где-то на абонентском порту петля. Лупдетект срабатывает с интервалом 1с. Есть вероятность, что луп зафиксирует коммутатор на агрегации, который еще умеет стп и луп. Однако локализовать проблему сложно - ранее ловились трапы от агрегации по лупдетект, теперь видимо придется ловить с уровня доступа. Открытым также остается вопрос, когда коммутаторы выходят из строя и начинают произвольно петлеваться порты, что также теперь сложно локализовать. Как быть в данном случае, если начал петлевать магистральный порт на доступе и ни на доступе, ни на агрегации не ловится?

Если у вас с "заглючевшего" доступа на порт агрегатора льется непрекращающийся шторм - настраивайте storm control.

Ну если упустить из виду, что в некие не столь давние времена мне опять же представители ДЛинка говорили примерно следующее "мы не рекомендуем включать шторм контроль, особенно на магистральном уровне", то решение в теории может иметь право на жизнь. Но, по моему скромному мнению, может тогда вообще выкинуть лупдетект - ведь есть шторм-контроль?

Дело исключительно ваше.
Клиентские петли механизмом LBD отрабатываются на "ура", так что до агрегации она не дойдет. Тем более что в скором времени на оборудовании планируют внедрять LBD 4.04 который будет ловить петлю и между коммутаторами. На кольцах можно использовать stp или erps - зависит от топологии и оборудования, если имеете оборудование неcкольких вендоров - понятно, что выбор идет в сторону stp.
Здесь уже по-моему начинается обсуждение из серии "хакер и солонка" - на сегодня есть механизмы защиты, которые отрабатывают в подавляющем большинстве случаев. Форс мажоры могут быть - но тут и действовать надо по ситуации, с применением рук и головы, а не спихивать все на оборудование.

Спасибо, поразмыслим.

Offtop: Когда для 3627/3620 ожидается прошивка >=3.0?

По последним данным (прошлая неделя) - конец осени 2012.