Перейти к содержимому
Калькуляторы

STP и петля

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

 

Бывают два типа петель: между портами 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 пакет, как это делают некоторые вендоры?

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

spanning-tree portfast bpduguard

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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


spanning-tree portfast bpduguard

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем dr Tr0jan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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. зачем - для меня загадка, но такое есть.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

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

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

 

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 hours ago, NiTr0 said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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-домене, тем меньше проблем.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.