День добрый.

Имеем настроенный loopdetect D-Link 3200-26:
enable loopdetect
config loopdetect recover_timer 60 interval 1 mode vlan-based

После появления петли, по таймеру %recover_timer% трафик снова разблокируется, что неправильно.
В течении %interval% мы снова имеем петлю. А ведь этот интервал может быть выбран от 1 до 32767 секунд.
Нужно сначала узнать, пропала ли петля, а потом разлочить трафик на порту.

Прошу рассмотреть возможность исправления алгоритма работы Loopback detection.
Есть подозрение, что и на другом оборудовании D-Link этот алгоритм такой же.
А он должен выглядеть примерно так:

При появлении петли (принятии своего пакета LOOP-DETECT) на порту или в отдельном VLAN, трафик/порт блокируется.
При заблокированном трафике, пакеты LOOP-DETECT отправляются с интервалом %recover_timer%.
Если пакет не пришел обратно, разблокируем трафик.

Это не только обезопасит сеть от шторма, но и снизит нагрузку на CPU во время петли.
И лучше дать возможность выставлять параметр %recover_timer% от 1 секунды, а не от 60 как сейчас - для минимизации потери трафика.


Ниже - выборочно листинг с почти чистого тестового коммутатора.
Софт залит самый свежий.
Проблема проверялась на постоянно закольцованном порту 26, с помощью mirror_Rх, сниффера и генератора трафика, в обоих режимах (vlan-based и port-based).


DES-3200-26:admin#sh sw
Command: show switch

Device Type : DES-3200-26 Fast Ethernet Switch
MAC Address : C8-BE-19-C4-99-00
IP Address : 10.90.90.90 (Manual)
VLAN Name : default
Subnet Mask : 255.0.0.0
Default Gateway : 0.0.0.0
Boot PROM Version : Build 4.00.002
Firmware Version : Build 4.37.B014
Hardware Version : C1
Serial Number : R3DY1C9006768
System Name :
System Location :
System Uptime : 0 days, 0 hours, 3 minutes, 18 seconds
System Contact :
Spanning Tree : Disabled
GVRP : Disabled
IGMP Snooping : Disabled
MLD Snooping : Disabled
VLAN Trunk : Disabled
Telnet : Enabled (TCP 23)
Web : Enabled (TCP 80)
SNMP : Disabled
SSL Status : Disabled
SSH Status : Disabled
802.1X : Disabled
Jumbo Frame : Disabled
CLI Paging : Enabled
MAC Notification : Disabled
Port Mirror : Enabled
SNTP : Disabled
Syslog Global State : Disabled
Single IP Management : Disabled
Password Encryption Status : Disabled

====== вариант 1 vlan-based =================
# LOOP_DETECT

enable loopdetect
config loopdetect recover_timer 60 interval 1 mode vlan-based
config loopdetect log state enable
config loopdetect ports 1 state disable
...
config loopdetect ports 24 state disable
config loopdetect ports 25 state enable
config loopdetect ports 26 state enable
config loopdetect trap none


====== вариант 2 port-based =================
# LOOP_DETECT

enable loopdetect
config loopdetect recover_timer 60 interval 1 mode port-based
config loopdetect log state enable
config loopdetect ports 1 state disable
...
config loopdetect ports 24 state disable
config loopdetect ports 25 state enable
config loopdetect ports 26 state enable
config loopdetect trap none

Интересная идея, но имхо самая большая проблема петли в том, что до возвращения loop-фрейма с проблемного порта могут вернуться и другие фреймы, в т.ч. с адресом шлюза. Коммутатор перестроит свою таблицу коммутации и трафик полетит в проблемный порт. Сразу после этого петля обнаруживается и порт блокируется. Теоретически, поскольку передача продолжается, маки практически мгновенно должны изучиться на правильных портах, но на практике прерывание связи для конечного потребителя может достигать 40 минут. Почему так, для меня непонятно, но я такое видел. По хорошему, сначала надо исследовать и решать эту проблему, иначе корректировка механизма LBD не имеет смысла.

_________________
D-Link Switches: Tips & Tricks

И ещё большой плюс такого решения - не будет огромной массы записей в логе о разблокировке трафика и блокировке, если петля не ушла.
Будем иметь начало аварии, и её фактическое время решения.
Очень удобно, особенно если получаешь оповещения по SMS

Насчет FDB /xcme, спасибо за наводку!/ - максимум что можно сделать в простой L2 сети, это автоматически после блокировки трафика почистить FDB таблицу на этом коммутаторе в порту, где задетектилась петля.
Это будет особенно важно, если до кучи запетлевался Management VLAN. У него отдельный таймер, и управление страдает дольше всех.

А какой смысл на коммутаторе доступа использовать Per-vlan-loop? Мы используем Port-based + recover 0. Пока абонент сам не обратится - мы ничего не делаем.

Сделал петлю - сам себе злобный негодяй. По моему личному мнению - все верно.

ZapaL
Изменение алгоритма работы loopdetect в планах не стоит, тем более, что при погашенном через loopdetect порту никакой трафик не может отправляться в принципе, то есть речь должна идти об изменении алгоритма только для режима vlan based.
Для запроса нового функционала или изменении работы текущего - обращайтесь в ближайшее представительство D-Link.

Если не ставить перманентную блокировку, проблема появляется в обоих режимах.
У других вендоров (например у Alcatel-Lucent) алгоритм loop-detect работает как надо.

В общем, спасибо, пообщаемся с местными товарищами из D-Link.

ZapaL

Сообщите, плс, о чем удалось договориться.

Сергей, вот ответ от поддержки:

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

Спасибо, и очень жаль.