_prox Опубликовано 28 июня, 2018 Добрый день,скажите пожалуйста для настройки loopback detection,достаточно просто указать правило на порту,или все таки глобально в config тоже нужно прописывать ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Tkachenko Опубликовано 28 июня, 2018 @_prox, loopback-detection в режиме shutdown достаточно настроить на порту. Также, в случае применения режима shutdown, для восстановления линка по таймауту нужно глобально задать его. loopback-detection control-recovery timeout <timeout> ! Interface Ethernet1/0/X loopback-detection specified-vlan <vlan_list> loopback-detection control shutdown ! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_prox Опубликовано 28 июня, 2018 2 минуты назад, Victor Tkachenko сказал: @_prox, loopback-detection достаточно настроить на порту. В случае применения режима shutdown для восстановления линка по таймауту нужно глобально задать его. loopback-detection control-recovery timeout <timeout> ! Interface Ethernet1/0/X loopback-detection specified-vlan <vlan_list> loopback-detection control shutdown ! спасибо большое Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 2 марта, 2020 Купили несколько коммутаторов SNR-S2985G-8T, SNR-S2985G-24T, SNR-S2985G-48T. Собрал стенд. Соединил все 3 коммутатора последовательно по цепочке (Uplink-Downlink-порты). Тестирую функцию loopback-detection. Если соединить 2 пользовательских порта на одном коммутаторе, то петля ловится и порт отключается. А если соединить любой пользовательский порт одного коммутатора с пользовательским портом другого, то петля не ловится, в логе появляются записи: <warnings> DEFAULT[RX Thread]:Port-security flapping has happened on Interface Ethernet1/0/1 and violation mode is restrict, the current unknown source mac addr is xx-xx-xx-xx-xx-xx, vlan id 77! и всё. Подскажите, почему не ловится петля? ПО на всех одинаковое: SoftWare Version 7.0.3.5(R0241.0339) BootRom Version 7.2.40 Настройки следующие: ! SNR-S2985G-8T ! Пользовательские порты Interface Ethernet1/0/1-8 description test user storm-control broadcast 112 storm-control multicast 112 switchport access vlan 77 switchport association multicast-vlan 501 mac-notification all trap ip access-group users_acl in loopback-detection specified-vlan 77 loopback-detection control shutdown switchport port-security switchport port-security maximum 2 switchport port-security violation restrict ! Все Uplink-Downlink порты настроены Interface Ethernet1/0/9-10 switchport mode trunk switchport trunk allowed vlan 77;102;501 ip dhcp disable ip dhcp snooping trust ! SNR-S2985G-24T ! Пользовательские порты Interface Ethernet1/0/1-24 description test user storm-control broadcast 112 storm-control multicast 112 switchport access vlan 77 switchport association multicast-vlan 501 mac-notification all trap ip access-group users_acl in loopback-detection specified-vlan 77 loopback-detection control shutdown switchport port-security switchport port-security maximum 2 switchport port-security violation restrict ! Все Uplink-Downlink порты настроены Interface Ethernet1/0/25-28 switchport mode trunk switchport trunk allowed vlan 77;102;501 ip dhcp disable ip dhcp snooping trust ! SNR-S2985G-48T ! Пользовательские порты Interface Ethernet1/0/1-48 description test user storm-control broadcast 112 storm-control multicast 112 switchport access vlan 77 switchport association multicast-vlan 501 mac-notification all trap ip access-group users_acl in loopback-detection specified-vlan 77 loopback-detection control shutdown switchport port-security switchport port-security maximum 2 switchport port-security violation restrict ! Все Uplink-Downlink порты настроены Interface Ethernet1/0/49-52 switchport mode trunk switchport trunk allowed vlan 77;102;501 ip dhcp disable ip dhcp snooping trust Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 2 марта, 2020 Loop-detection это не про это. Если нужно между несколькими свичами, то это протоколы типа STP, ERPS и т.п. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 2 марта, 2020 2 hours ago, VolanD666 said: Loop-detection это не про это. Если нужно между несколькими свичами, то это протоколы типа STP, ERPS и т.п. Чего это "не про это" ? Еще как "про это". Включать на абонентском порту "STP, ERPS и т.п." - верный путь к проблемам. 2 hours ago, raveren said: <warnings> DEFAULT[RX Thread]:Port-security flapping has happened on Interface Ethernet1/0/1 and violation mode is restrict, the current unknown source mac addr is xx-xx-xx-xx-xx-xx, vlan id 77! Возможно port-security срабатывает раньше, чем loopback-detection Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 2 марта, 2020 2 минуты назад, ShyLion сказал: Включать на абонентском порту А да, не увидел про абонентский порт :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 3 марта, 2020 23 часа назад, ShyLion сказал: Возможно port-security срабатывает раньше, чем loopback-detection Отключал port-security. В логах при этом тишина становится. При аналогичной схеме на D-Link'ах сразу петля срабатывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 3 марта, 2020 Это вопрос по реализации loopback-detection у SNR.... Есть документация где-то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 3 марта, 2020 Есть! На английском : https://data.nag.ru/SNR Switches/Configuration Guide/SNR-S2985G/en/02-Port Configuration.pdf - Chapter 3 На русском языке: https://data.nag.ru/SNR Switches/Configuration Guide/SNR-S2985G/[S2985G и S2965] Руководство по настройке.pdf - 7. Loopback detection 54 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 3 марта, 2020 @raveren Познавательно, но маловато для понимания. 1. Не раскрыто содержание BPDU. 2. Не указано работает ли луп-детектион только на порт или в целом на устройство. СОВЕТ: Попробуйте провести эксперимент прогоняя кольцевой трафик через неуправляемый коммутатор - будет понятно, по крайне мере, по п.2. Можно еще посниферить BPDU. З.Ы. Есть функция контроля только в отдельном влане и закрытие инстанса - это интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 4 марта, 2020 @_prox Доброе утро! Сразу не увидели сообщение, в следующий раз пишите в разделе SNR. Петля не определяется, так как LBD-сообщения от одного коммутатора перехватываются другим (при условии что на обоих портах включен loopback-detection). Функционал создан в первую очередь для защиты от петель на стороне клиента. Если есть цель защититься от петли между коммутаторами - необходимо использовать STP, ERPS и т.д. @sdy_moscow На всякий случай добавлю, что по настройке loopback-detection есть статья. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 4 марта, 2020 4 hours ago, Aleksey Sonkin said: Петля не определяется, так как LBD-сообщения от одного коммутатора перехватываются другим Чет как по мне, так очень спорное решение. Надо бы добавить какую-то опцию, чтобы блокировать при поимке BPDU от другого коммутатора, может с каким-то общим на всех ключем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 4 марта, 2020 @ShyLion Для этого существует spanning-tree bpdu-guard :) loopback-detection используется на последней миле, он не подразумевает того, что за этим портом будет находиться другой коммутатор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 6 марта, 2020 В 04.03.2020 в 12:22, Aleksey Sonkin сказал: @ShyLion Для этого существует spanning-tree bpdu-guard :) loopback-detection используется на последней миле, он не подразумевает того, что за этим портом будет находиться другой коммутатор. А я считаю, что loopback-detection на то и loopback-detection, чтобы отлавливать петли независимо от мили. Если использовать spanning-tree bpdu-guard, то у нас тех. поддержку завалят звонками о том, почему у них сеть не работает. Мы обходимся bpdu-filter, т.к. много пользовательских устройств по разным причинам время от времени присылают BPDU. Кто-то случайно в LAN наш кабель воткнул, кто-то учится настраивать Mikrotik. Пользуясь случаем, прошу изменить логику работы вашей функции. От этого станет только лучше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ALEX_SE Опубликовано 7 марта, 2020 А может логичнее будет сделать что-то типа Restricted TCN? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 10 марта, 2020 Как по мне, на всего оператора выбирается кодовое слово, которое вставляется в BPDU loopguard'а. Таким образом свитч будет знать, что это сообщение от его собрата а не от абонентского СНР свича и нужно блокировать порт. Делов на день работы погромиста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 10 марта, 2020 @ShyLion проще не блокировать прохождение пакетов, которыми обнаружение петли происходит. Там даже логику текущей работы менять не надо будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 10 марта, 2020 у длинков есть lbd per vlan, в снры это не завезли, но вопрос поднимался Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 10 марта, 2020 Это уже что-то из разряда MSTP. На абонентском порту, как мне кажется, излишне. 47 minutes ago, raveren said: @ShyLion проще не блокировать прохождение пакетов, которыми обнаружение петли происходит. Там даже логику текущей работы менять не надо будет. что значит "не блокировать прохождение" ? прохождение куда? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 10 марта, 2020 В 04.03.2020 в 07:17, Aleksey Sonkin сказал: Петля не определяется, так как LBD-сообщения от одного коммутатора перехватываются другим (при условии что на обоих портах включен loopback-detection). Функционал создан в первую очередь для защиты от петель на стороне клиента. Если есть цель защититься от петли между коммутаторами - необходимо использовать STP, ERPS и т.д. @ShyLion прохождение дальше по другим портам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 10 марта, 2020 Зачем loopdetect BPDU проходить внутрь операторской сети? чтобы что? чтобы дойти до свича-автора и положить транк? или порт отправления? эдак нехороший абон сможет чужие порты ложить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 10 марта, 2020 27 минут назад, ShyLion сказал: Зачем loopdetect BPDU проходить внутрь операторской сети? чтобы что? чтобы дойти до свича-автора и положить транк? или порт отправления? эдак нехороший абон сможет чужие порты ложить. Затем, чтобы реально ловить петли! Вы выше почитайте, как D-Link у меня на стенде обнаруживает петлю. Кладётся всегда порт отправителя. На Up/Downlink портах функция LBD отключена. Всё нормально отрабатывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 10 марта, 2020 Я рад за Вас, коллега. Во первых я Ваш стенд не видел, во вторых длинки в моем личном рейтинге на последних местах. По моему скромному мнению негоже служебному траффику нарезать круги по сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShumBor Опубликовано 10 марта, 2020 Я конечно понимаю что абоненты существа не предсказуемые, но блин как он соединит петлей 2 дома (2 подъезда еще можно с соседом через стенку договориться). Это же еще постараться надо... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...