[M-a-x-Z]

Вопрос сугубо теоретический

 

Бывают два типа петель: между портами STP домена и ЗА портом STP домена.

В первом случае всё просто, протокол STP успешно петлю забарывает (иногда с нюансами, но в целом всё хорошо).

 

Но самое интересное начнётся, если подключить к управляемому порту мыльницу с замкнутыми портами. Никакой STP на это не среагирует, а сеть ляжет. С точки зрения протокола это объяснимо - STP блокирует только несколько портов в один сегмент. Если в бажный сегмент идёт один порт, то ничего с этим не сделать. Но как раз такая ситуация, на практике, попадается гораздо чаще чем то, что несколько соседей соединят свои порты.

 

Я попытался немного систематизировать способы борьбы с этой напастью и вот, что получилось.

- самый логичный способ есть у Eltex (а, наверное, и у дргуих, но мне попался он) spanning-tree loopback-guard - порт блокируется в том случае, если получает обратно тот же BPDU, который именно в этот порт отправил ранее. Любые дргуие BPDU или фильтруются или обрабатываются в логике STP. Это самое красивое и логичное решение из найденных. Но его нет у Cisco. У кошек есть технология guard loop, но она ничего общего с описываемой ситуацией не имеет и вообще про другое.

- можно включить loop guard. Эффект при петле будет хороший. Проблема только в том, что если абонент подключить железку с претензией на управляемость - её тоже отрубит. Добавлять bpdu фильтер нельзя, так как она нейтрализует guard.

- можно врубить шторм-контроль,но параметры надо подбирать под сеть. Тоже может рубить много лишнего

- функция down-when-loop по идее обещает решить проблему, но на практике работает только с FE. От 1000BaseT нос воротит (хотя не очень понятно, почему: уж отражённый сигнал от передаваемого-то можно различить же). В качестве транспорта использует странный Configuration Test Protocol, который Wireshark называет LOOP.

 

 

Соответственно вопрос - не упустил ли я у кошки каких-то механизмов обнаружения петли за одним портом?

Почему они упорно не могут запилить реакцию свитча на свой же BPDU пакет, как это делают некоторые вендоры?

 

Ну и кто чем пользуется от такой напасти?

[NiTr0]

6 минут назад, M-a-x-Z сказал:

Соответственно вопрос - не упустил ли я у кошки каких-то механизмов обнаружения петли за одним портом?

LBD и STP какбы не обязательно пересекаются, и вполне себе существуют независимо друг от друга. в тех же хуавеях к примеру...

[M-a-x-Z]

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

LBD и STP какбы не обязательно пересекаются, и вполне себе существуют независимо друг от друга. в тех же хуавеях к примеру...

Конечно не обязательно. Просто раз уж есть пакеты...

 

Но почему у Cisco вообще нет реализации LBD? Ни отдельной, ни через STP. Или я невнимательно искал?

[dr Tr0jan]

35 minutes ago, M-a-x-Z said:

Почему они упорно не могут запилить реакцию свитча на свой же BPDU пакет, как это делают некоторые вендоры?

BPDU Guard чем не реакция?

spanning-tree portfast bpduguard

 

[M-a-x-Z]

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

BPDU Guard чем не реакция?

spanning-tree portfast bpduguard

 

Уточнил же выше. Если к такому порту подключить вместо DES1008, например, DES2108 - порт будет залочен даже без наличия петли. Просто за сам факт подключения управляемого устройства.

 

BPDU Guard - это не совсем механизм защиты от петель.

[dr Tr0jan]

3 minutes ago, M-a-x-Z said:

Если к такому порту подключить вместо DES1008, например, DES2108 - порт будет залочен даже без наличия петли. Просто за сам факт подключения управляемого устройства.

Это с какого перепуга 2108 будет возвращать BPDU взад? У меня полдюжины таких балалаек подключено к bpdu-guard портам, никаких проблем с ними нет. Порт не лочится.

Edited February 11, 2019 by dr Tr0jan

[M-a-x-Z]

2 часа назад, dr Tr0jan сказал:

Это с какого перепуга 2108 будет возвращать BPDU взад? У меня полдюжины таких балалаек подключено к bpdu-guard портам, никаких проблем с ними нет. Порт не лочится.

 

А он сам его (свой) не генерит? Ну тогда любой другой свитч, который их генерит)))

Гуарду ведь глубоко фиолетово - свой это бпду вернулся или чужой пришёл.

[dr Tr0jan]

@M-a-x-Z, т.е. ты не управляешь 2108 и хочешь выявлять петли в чужом STP-домене? Причину проблемы, которая тебе неподвластна.

[NiTr0]

 

4 часа назад, M-a-x-Z сказал:

Но почему у Cisco вообще нет реализации LBD?

есть, но похоже только на тех что были в девичестве линксисами

https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-250-series-smart-switches/smb5794-enable-loopback-detection-on-a-switch.html

а так - детектятся петли по сторм контрол. оно мож и правильнее (гарантированно погасит порт при любом флуде, а не только петле)

 

1 час назад, dr Tr0jan сказал:

т.е. ты не управляешь 2108 и хочешь выявлять петли в чужом STP-домене?

некоторые абонентские роутеры зачем-то шлют STP. зачем - для меня загадка, но такое есть.

 

 

[s.lobanov]

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

некоторые абонентские роутеры зачем-то шлют STP. зачем - для меня загадка, но такое есть.

да скорее всего при интеграции кода для работы со свитч-чипом, не выпилили stp, который, могу быть включенным по дефолту в коде вендора

[NiTr0]

4 минуты назад, s.lobanov сказал:

да скорее всего при интеграции кода для работы со свитч-чипом, не выпилили stp, который, могу быть включенным по дефолту в коде вендора

навряд свиччип тут причем, там от интеграции только конфигуратор вланов юзерспейсный в основном. да и стп - оно не свиччипом шлется, свиччипы там тупые (а то и вообще интегрированные)

[M-a-x-Z]

 

4 часа назад, dr Tr0jan сказал:

@M-a-x-Z, т.е. ты не управляешь 2108 и хочешь выявлять петли в чужом STP-домене? Причину проблемы, которая тебе неподвластна.

Да, я же сразу пояснил что хочу отсекать запетлёванные сегменты, не управляемые основным деревом. И ничего особенного в этом нет. Многие умеют LBD. Да и алгоритм такого поведения простецкий. Даже у самой циски он был для FE. А теперь нет.

 

 

2 часа назад, NiTr0 сказал:

есть, но похоже только на тех что были в девичестве линксисами 

Вот оно чё, Михалыч.... оттуда и элтекс это умеет. Фреймворк от Marvell. Вдвойне обидно, что они смогли LBD, а первичная циска нет.

[dr Tr0jan]

8 hours ago, NiTr0 said:

а так - детектятся петли по сторм контрол. оно мож и правильнее (гарантированно погасит порт при любом флуде, а не только петле)

Тоже так считаю. Но это моё мнение, как энтерпрайса. У меня клиенты чаще абстрактно флудят, нежели лупятся.

У ISP может быть всё по другому.

[[anp/hsw]]

20 часов назад, M-a-x-Z сказал:

В качестве транспорта использует странный Configuration Test Protocol, который Wireshark называет LOOP.

CTP никакой не странный, он входит в стандарт ethernet, создан был как L2-ping, (с возможностью пинговать самого себя через петлю).

Большинство LBD работающего на свичах, работают именно на CTP. Им можно пользоваться также для обнаружений петель между 2 и больше портами, не прибегая к обработке STP (и как минимум некоторые длинки 3xxx серии это умели).

 

 

12 часов назад, M-a-x-Z сказал:

Да, я же сразу пояснил что хочу отсекать запетлёванные сегменты, не управляемые основным деревом. И ничего особенного в этом нет. Многие умеют LBD. Да и алгоритм такого поведения простецкий. Даже у самой циски он был для FE. А теперь нет.

Зафильтруйте STP и блокируйте по счетчикам флуда. Чем меньше устройств в STP-домене, тем меньше проблем.

 

[M-a-x-Z]

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

CTP никакой не странный, он входит в стандарт ethernet, создан был как L2-ping, (с возможностью пинговать самого себя через петлю).

Большинство LBD работающего на свичах, работают именно на CTP. Им можно пользоваться также для обнаружений петель между 2 и больше портами, не прибегая к обработке STP (и как минимум некоторые длинки 3xxx серии это умели).

 

 

Зафильтруйте STP и блокируйте по счетчикам флуда. Чем меньше устройств в STP-домене, тем меньше проблем.

 

Странным я его назвал потому, что WireShark его в одном поле идентифицирует как CTP, а в другом - уже как LOOP. Ну и не понятно, почему он оказался несовместим с 1000BaseT. Точнее LBD на его базе по версии Cisco.

 

" Зафильтруйте STP и блокируйте по счетчикам флуда. " - так, по сути, и сделано. По счётчикам флуда только пару раз прибило Acronois, который, оказывается, бродкаст уважает. Хотя реализация LBD от Eltex и недо-кошки, ИМХО надёжнее.