Подскажите пожалуйста, связана ли как-то функция Forward BPDU (при ОТКЛЮЧЕННОМ STP протоколе, допустим, на свитче DES-3526) и возможность форвардинга BPDU?

Просто заметил следующее - если порт убрать из egress vlan 1, то на нем перестают форвадиться BPDU от соседнего коммутатора, если на данном коммутаторе STP выключен, но включены Forward BPDU глобально и на соответствующем порту. Если этот порт сделать egress в vlan 1 - пакеты форвадятся.

На этом порту только VLAN default или есть ещё какие-то!? И когда Вы этот порт делаете как tagged, то он находится как untagged в другом VLAN-е!?

_________________
С уважением,
Бигаров Руслан.

На этом порту есть egress tagged default VLAN и VLAN для управления свитчем. Untagged VLAN на этом порту никаких нет.

Причем если этот порт убирать из другого VLAN-а (для управления свитчем), и оставить только в default VLAN-е - BPDU Forwarding на этом порту работает. Если же этот порт убрать из default VLAN-а (и оставить, допустим, в VLAN-е для управления свитчем) - BPDU Forwarding работать прекращает.

Поэтому возникло впечатление, что BPDU Forwarding на порту работает только если default VLAN является egress на этом порту.

Пакетики bpdu не завязаны на VLAN-ы и ходят без tag 802.1q, поэтому нужно добавлять какой-нибудь VLAN как untagged на магистральные порты.

_________________
С уважением,
Бигаров Руслан.

Спасибо, буду пробовать разные варианты. Вообще насколько я протестировал, чтобы корректно работала функция Forward BPDU, возможны 2 варианта - либо все порты, в которых она должна работать, включить Egress tagged/untagged в default VLAN, либо эти порты включить в Egress untagged в любой другой VLAN.

Еще вопрос - пытаюсь победить проблему, когда свитч (3526 в данном случае) зависает, если начинает на определенном порту получать собственные BPDU. Допустим, если на свитче включить RSTP протокол, и на порту, в который уходят RSTP-пакеты от данного свитча, далее подключен обычный неуправляемый свитч, на котором соединены между собой два порта - неуправляемый свитч начинает дублировать RSTP-пакеты, полученные от 3526, и отсылать их обратно к нему. При этом видимо нагрузка процессора на 3526 достигает 100%, т.к. удаленно к нему не подключиться.

Возникла мысль настроить ACL (CPU Interface Filtering), таким образом, чтобы на определенном 3526 фильтровались BPDU-пакеты, полученные от MAC-адреса самого коммутатора. По идее, при этом свитч должен перестать захлебываться собственными BPDU, и перестать зависать (возможно даже сработает LBD при этом).

При настройке CPU Interface Filtering обнаружил странную вещь. Если добавлять ACL Packet Content Mask, и указывать в нем Offset 0_15 mask 0xffff0000 и фильтр 0x01800000 (что соответствует первым двум октетам destination MAC-адреса в RSTP-пакетах, посылаемых 3526, проверено tcpdump'ом) - то пакеты, получаемые от ДРУГОГО 3526 по протоколу RSTP перестают влиять на работу RSTP на данном 3526. То есть, по идее, они отсеиваются. (Допустим, если данный 3526 и ДРУГОЙ 3526 были соединены между собой, и ДРУГОЙ 3526 являлся корнем дерева, то при включении CPU Interface Filtering с вышеозначенным ACL - данный 3526 становился корнем дерева, т.е. видимо переставал получать RSTP-пакеты от ДРУГОГО 3526).

Но. Данный ACL почему-то не действует на пакеты, который данный 3526 посылает сам, и получает потом обратно из-за петли на неуправляемом коммутаторе. Хотя пакеты между собой абсолютно одинаковые (опять же, по tcpdump посмотрено), и в начале пакета идет всегда одно и то же: 0x0000: 0180 c200 0000

Вопрос, собственно - почему ACL может не действовать на пакеты от самого 3526, получаемые им обратно из-за петли? Разве эти STP-пакеты не являются такими же, как и пакеты, получаемые от другого 3526?

Уважаемые сотрудники D-Link, помогите пожалуйста с решением этой небольшой, но злобной проблемы

enable loopdetect
config loopdetect recover_timer 180
config loopdetect interval 1
config loopdetect mode port-based
config loopdetect ports 1-24 state enable

И проблема решена.

_________________
С уважением,
Бигаров Руслан.

Хм, действительно, поставил config loopdetect interval 1, возможно дело было именно в интервале (чтобы LBD пакеты посылались чаще, чем BPDU). Теперь срабатывает LBD, совместно с RSTP. Спасибо. Буду дальше тестировать.

Не за что.

_________________
С уважением,
Бигаров Руслан.

Ну вот Только я обрадовался, что всё будет ОК, и на тебе. LBD срабатывает, но после нескольких нормальных срабатываний, почему-то срабатывать перестает, и свитч все-таки захлебывается своими BPDU, как и раньше (с более длительным интервалом LBD пакетов).

Срабатывает LBD похоже два раза (может быть, каждый раз по разному, надо проверять), после чего срабатывать перестает.

Лог свитча:

2144 00002 days 02:36:15 New Root bridge selected (Instance:0, MAC:00-1B-11-B5-C9-77, Priority:32768)
2143 00002 days 02:36:09 New Root bridge selected (Instance:0, MAC:00-1C-F0-9E-E4-C4, Priority:16384)
2142 00002 days 02:30:12 Topology changed (Instance:0, port:2)
2141 00002 days 02:29:46 New Root bridge selected (Instance:0, MAC:00-1B-11-B5-C9-77, Priority:32768)
2140 00002 days 02:29:43 Port 2 LBD port recovered. Loop detection restarted.
2139 00002 days 02:29:43 Port 2 link up, 100Mbps FULL duplex
2138 00002 days 02:26:36 New Root bridge selected (Instance:0, MAC:00-1C-F0-9E-E4-C4, Priority:16384)
2137 00002 days 02:26:36 Port 2 link down
2136 00002 days 02:26:36 Port 2 LBD loop occurred. Port blocked.
2135 00002 days 02:26:16 Topology changed (Instance:0, port:2)
2134 00002 days 02:25:51 New Root bridge selected (Instance:0, MAC:00-1B-11-B5-C9-77, Priority:32768)
2133 00002 days 02:25:46 Port 2 link up, 100Mbps FULL duplex
2132 00002 days 02:25:41 Port 2 LBD port recovered. Loop detection restarted.
2131 00002 days 02:20:41 Port 2 link down
2130 00002 days 02:20:40 Port 2 LBD loop occurred. Port blocked.

При сообщении 2130 - включение кольца на неуправляемом свитче. Видно, что 2 раза LBD сработал, потом после recovery после 2-го раза уже не срабатывает.

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

Интересно также, что свитч на котором плохо срабатывает LBD - у него прошивка 6.00.B37

На свитче с прошивкой 5.01.B52 LBD срабатывает нормально, независимо от interval'а, и неограниченное количество раз (во всяком случае, за 2 часа тестирования с 5-минуными recovery time LBD срабатывал нормально, на свитче же с 6.00.B37 LBD срабатывал только два раза подряд, а потом - переставал работать).

Не знаю, зависит ли это от прошивки. А если на коммутатор поставить более новую прошивку, можно будет потом залить на него более старую? И почему могут так себя вести свитчи с разными прошивками?

Помогите, пожалуйста, уважаемые гуру D-Link'а Может быть, это я глупый, и нужно включить какую-нибудь магическую опцию, после которой мгновенно всё станет идеально.

Уважаемые сотрудники техподдержки D-Link, может быть вышлите мне хотя бы прошивку 5.01.B52 для 3526, чтобы я мог проверить, зависит ли странное срабатывание LBD от прошивки, или нет? Очень прошу. Можно на slava1478 (сабака) mail.ru