Элтекс

Вот, может кому поможет. Покритикуйте, исправим что не так.

Коротко о loopback-detection (LBD). Свич с заданной периодичностью отправляет в порт с разрешённым LBD специальные пакеты. Если в сети, подключенной к этому порту имеются петли, то эти пакеты возвращаются обратно и в случае обнаружения таких входящих пакетов на интерфейсе система блокирует этот порт или вилан и тем самым защищает вышестоящую сеть от петли. Если включено автоматическое восстановление, то через заданное время система поднимает отключенный порт безусловно, без всяких проверок. И далее всё сначала. Иначе порт или вилан будет заблокирован вплоть вплоть до ручной разблокировки специальной командой с консоли или перезагрузки свича.
Система предназначена для работы поинтерфейсно, то есть в один порт посылает пакеты и на этом же порту ожидает их возврата. Не надо пытаться посылать пакеты в один интерфейс и пытаться словить их на другом интерфейсе, эта система не предназначена для работы в кольцах и тому подобном. Только поинтерфейсная защита вышестоящей сети от петель в нижестоящей, в частности на абонентских портах.
Если используется LBD, то STP лучше отключить, одновременное использовани возможно, но не имеет смысла, поскольку STP срабатывает раньше, чем LDB. Или уж тогда использовать для обнаружения петель STP и не использовать LDB.

Для начала глобально разрешить LBD.
loopback-detection enable
Установить интервал между loopback-пингами
loopback-detection interval 10

Следующие две команды только если нужен контроль по отдельным виланам. Иначе при обнаружении петли будет блокироваться только порт.
loopback-detection vlan-based
Только при работе с виланами - время автоматического восстановления. Для портов задаётся отдельно, см. ниже.
loopback-detection vlan-based recovery-time 60

Рекомендуется включать мультикаст вместо бродкаста, если иначе не работает.
loopback-detection mode multicast-mac-addr

Если нужно, то автоматически включать заблокированные порты ранее через заданное время. Для виланов задаётся отдельно, см. выше.
Включить автоматическую активацию интерфейса после его отключения при обнаружении петли.
errdisable recovery cause loopback-detection
Установить временной интервал для автоматического повторного включения интерфейса после его отключения при обнаружении петли.
errdisable recovery interval 30

Включить LBD на каждом интерфейсе, где он требуется.
loopback-detection enable

С конфигурацией всё.

Разблокировать вручную заблокированный системой интерфейс.
set interface active

Посмотреть статус настройки системы восстановления заблокированных портов
show errdisable recovery

Посмотреть статус интерфейса, находится ли он в заблокированном стостоянии?
show interfaces status GigabitEthernet 1/0/2

Посмотреть статус интерфейса:
show loopback-detection GigabitEthernet 1/0/2

Псомотреть статус всех интерфейсов:
show loopback-detection

Пример сообщений в логах свича при срабатывании LBD и автоматическом восстановлении через 30 секунд.
14:42:00 Informational %LINK-I-Up: gi1/0/2
14:41:30 Warning %LINK-W-Down: gi1/0/2
14:41:30 Warning %LINK-W-PORT_SUSPENDED: Port gi1/0/2 suspended by loopback-detection
14:41:30 Informational %NT_LBD-I-PORT_SUSPENDED: Port gi1/0/2 suspended by Loopback Detection.


Пример части конфига, отвечающей за LBD.
!
loopback-detection enable
loopback-detection mode multicast-mac-addr
loopback-detection interval 10
!
errdisable recovery interval 30
errdisable recovery cause loopback-detection
!
interface gigabitethernet1/0/1
spanning-tree disable
loopback-detection enable
exit
!
end

А, например, длинк - умеет ловить закольцовку между портами. В пакете LBD прописан номер порта, с которого отправлен пакет. В случае его получения любым другим портом с настроенным loopdetect, порт блокируется. И не надо писать, что эта система не предназначена. Для чего тогда она? Очень весело, когда где-то подальше, в каком-то помещении кто-то случайно соединит кабели, идущие с разных портов. И как раз защита вышестоящего оборудования и не сработает, приляжет всё, если только не настроен LBD на вышестоящем в сторону элтекса, что очень странное решение. Тему давно создавал на форуме, не знаю исправили ли проблему, как-нибудь протестирую снова.

Добрый день.

А, например, длинк - умеет ловить закольцовку между портами.

Коммутаторы MES всех моделей это тоже всегда умели.

Евгений Т писал(а):Добрый день.

А, например, длинк - умеет ловить закольцовку между портами.

Коммутаторы MES всех моделей это тоже всегда умели.

Вас не понять. То пишите, что LDB не умеет ловить петли между портами, то теперь пишете, что умеет. Вы уж определитесь.

Прошу привести ссылку на тему, где я писал, что lbd не ловит петлю между портами.

Евгений Т писал(а):Прошу привести ссылку на тему, где я писал, что lbd не ловит петлю между портами.

Так вот ниже на этой же первой странице.
viewtopic.php?f=10&t=11917
И до этого раньше в другой теме писали, что такая возможность в разработке только.
Я что-то неправильно понял?

По этой ссылке я не писал, что между портами блокировать линк LBD не будет. Там речь шла про магистральные порты и именно для них я советовал RSTP, отвечая на этот вопрос:

Попытки использовать LBD в магистральных сетях для работы в кольце, например, приводили у меня к непонятным эффектам и не дали ожидаемого. Значит и не нужно пытаться натянуть сову на глобус, а нужно использовать для этого другие механизмы. Я прав?

Резюме:
- LBD блокирует петлю за клиентским портом
- LBD блокирует петлю между клиентскими портами (если у вас не работает, то явно включен RSTP)
- для магистральных портов LBD не подходит. Там используются кольцевые протоколы семейства xSTP/ERPS.

Евгений Т писал(а):Резюме:
- LBD блокирует петлю за клиентским портом
- LBD блокирует петлю между клиентскими портами (если у вас не работает, то явно включен RSTP)
- для магистральных портов LBD не подходит. Там используются кольцевые протоколы семейства xSTP/ERPS.

Какая разница между магистральным и клиентским портом? VLAN нет, плоская сеть. STP отключено везде, BDU везде зафильтрованы, в рамках этого вопроса xSTP вообще не рассматриваем. Каков механизм работы тогда LBD на пальцах, чтобы понятно было человеку без сертификатов Cisco? Если в пределах одного порта, то всё понятно: разрешили на порту LBD , кидаем в порт тестовые пакеты, если получаем назад в этом порту отосланные через него-же тестовые пакеты, то блокируем порт. Правильно? Теперь берём два порта и тьем более, если более двух. Всё резко становится непонятным. Параметр управления LBD на порту только один - либо разрешено либо нет. Нет возможности управлять отдельно только отсылкой или только контролем приёма. Этот параметр управляет чем тогда: отсылкой пакетов, контролем приёма пакетов или и тем и другим одновременно? Если пакет послан из одного порта а словлен на другом порту, то какая будет реакция свича? Положит оба порта, положит только порт отсылки, положит только порт приёма? В тестовых пакетах вообще есть информация о порте, из которого он послан? Короче полная каша. Экспериментально лично мне не удалось понять механизм работы, при всех стараниях не получилось нормально ловить петли между портами, хоть как их назови, хоть магистральные хоть пользовательские. Если можете, то поясните. Я уже спрашивал раньше, но вопрос для меня так и остался невыясненным, поэтому лично я механизмом LBD на ваших свичах не пользуюсь ибо не понимаю.

Какая разница между магистральным и клиентским портом?

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

Если в пределах одного порта, то всё понятно: разрешили на порту LBD , кидаем в порт тестовые пакеты, если получаем назад в этом порту отосланные через него-же тестовые пакеты, то блокируем порт.

Такая же логика и между портами. Если ловим lbd фрейм от своего же коммутатора с любого порта, то блокируем порт. Это вся логика работы.
Порт отправки и является одновременно портом приёма. Это же кольцо между портами. Каждый порт отправляет. Каждый порт принимает. Кто быстрее словил, тот быстрее положил интерфейс.

Экспериментально лично мне не удалось понять механизм работы, при всех стараниях не получилось нормально ловить петли между портами, хоть как их назови, хоть магистральные хоть пользовательские. Если можете, то поясните.

Ответил выше:
- LBD блокирует петлю между клиентскими портами (если у вас не работает, то явно включен RSTP)
Просто 2 порта можно соединить патчкордом, на обоих включить lbd и выключить stp. Сразу петлю lbd зафиксирует.

Неоднократно уже писал: xSTP отключено глобально и отдельно на всех портах. BDU зафильтровано на свиче глобально и отдельно на всех портах. Почему вы всё время подозреваете, что xSTP включен - не понимаю.
LBD loopback-detection - нестандартный протокол, поэтому каждый производитель понимает его как хочет. И он реально у разных производителей работает по разному. Поэтому уточняю.
1. Структура тестового пакета не описана. Можете расписать? Тип фрейма, протокол, источник, назначение? Или это тайна? Это важно, потому, что нужно обеспечить прохождение пакетов через фильтры, которые могут быть по дороге тестовых пакетов.
2. Если включить LBD на порту, то свич начинает периодически передавать в этот порт тестовые пакеты. Если режим LBD не включен на порту, то пакеты в этот порт не посылаются.
3. Если включить LBD на порту, то свич начинает контролировать приход из этого порта тестовых пакетов, переданных из этого же свича с любого порта и в случае обнаружения такого входного пакета на порту отключает этот порт. Если фиксируется приход на несколько портов одновременно, то будет отключено несколько портов одновременно.
4. Свич никак не реагирует на тестовые LBD пакеты, пришедшие от других свичей.
Всё верно?

Неоднократно уже писал: xSTP отключено глобально и отдельно на всех портах. BDU зафильтровано на свиче глобально и отдельно на всех портах. Почему вы всё время подозреваете, что xSTP включен - не понимаю.

Топик называется "Краткая инструкция по loopback-detectiob (LBD)". Когда я пишу про LBD, я не описываю вашу схему. Я описываю типовую схему. Т.е как обычно реализовывают разные провайдеры на сети.

1. Эта информация не может быть секретной, потому что весь фрейм можно посмотреть в вайршарке, просто подключившись к порту коммутатора с настроенным LBD. Там всё написано.
2. Верно.
3. Всё верно кроме последнего. Отключится только 1 порт.
4. Верно.

Евгений Т писал(а):1. Эта информация не может быть секретной, потому что весь фрейм можно посмотреть в вайршарке, просто подключившись к порту коммутатора с настроенным LBD. Там всё написано.

То есть вместо предоставления информации или ссылки с ответом на вопрос вы предлагаете заниматься самостоятельными исследованиями? Или вы сами не знаете структуры тестового пакета LBD ваших коммутаторов?

Евгений Т писал(а):3. Всё верно кроме последнего. Отключится только 1 порт.

Это как? Какой именно порт из получивших ответку на тестовый пакет LBD отключится? И что будет с остальными?

То есть вместо предоставления информации или ссылки с ответом на вопрос вы предлагаете заниматься самостоятельными исследованиями? Или вы сами не знаете структуры тестового пакета LBD ваших коммутаторов?

Дамп в архиве во вложении.

Это как? Какой именно порт из получивших ответку на тестовый пакет LBD отключится? И что будет с остальными?

Поправлю свой предыдущий комментарий. Заблокируются порты, первыми получившие LBD фрейм от других портов-источников. Петля после этого разрывается, и остается незаблокированным один порт.