_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...