Выяснились подробности. работа с RRCP включается при включении Loopback detection. Свич начинает отвечать на запросы и одновременно - дропать RRCP-пакеты, которые через него проходят.Думаю, авторам софта не составит труда найти и обезвредить этот баг. Не стоит дожидаться, когда свичами кто-то начнёт управлять. RRCP - протокол очень дырявый и примитивный.

Тоже столкнулись с этой проблемой. Проблема острая. Из-за топологии сети за этими вебсмартами (1100-05, 08) часто находятся Compex PS2216, которые из-за вышестоящих вебсмартов становятся глупыми коробочками.

Вот в чем дело. На этих вебсмартах некорректно реализован Loopback Detection. Он, конечно, работает, но! Во-первых, Ethernet Type 0x8899 вместо 0x9000. Во-вторых, почему-то эти пакеты ходят на ff:ff:ff:ff:ff:ff вместо cf:00:00:00:00:00.
Тип 0x8899 - это протокол RRCP! Вебсмарты при включенном LBD на порту просто отбрасывают любой пакет c 0x8899, считая его пакетом, отправленным другим свитчом с LBD. Самое забавное, вебсмарты действительно отвечают на RRCP Hello, но, кажется, информация в ответе все-таки случайная.

При этом уже на DGS-1100-06 LBD реализован совершенно корректно - и с типом 0x9000, и с маком cf:00:00:00:00:00.

Очень прошу сменить тип пакета Loopback с 0x8899 на стандартный 0x9000, так как это ломает управление свитчей другой фирмы, что не очень хорошая ситуация. D-Link, ответьте на это сообщение, пожалуйста.

На младших веб смартах loopdetect действительно реализован через протокол RRCP, и это не является ошибкой - у протокола есть такой вариант использования.

Окей, а как быть с дропом всех RRCP-шных пакетов, которые должны ходить сквозь?

Если у вас линк между коммутаторами - отключайте на нем loopdetect.

Это не выход, где-нибудь между еще глупый свитч может быть.
Вы намекаете, что не собираетесь это чинить?

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

Свитч дропает RRCP Discover пакеты. Он не должен этого делать, он должен пересылать их дальше, у них мак-адрес назначения ff:ff:ff:ff:ff:ff.