Как мы и предполагали, дело оказалось в keepalive фреймах. Для обнаружения петель на канальном уровне, Cisco периодически шлёт такие фреймы. Если на порту был принят keepalive с mac-адресом данного порта, то cisco определяет петлю на порту и опускает линк.

Как оказалось, в cisco’вских keepalive фреймах mac-адреса источника и получателя совпадают и равны mac-адресу порта с котрого были отправлены (у dlink, zyxel не так), вот и понятно почему при шлейфах 2 и 3 уровней блокировался порт (опускался линк).

Поэтому решение довольно простое: отфильтровывать фреймы с ethertype 0×9000 (он используется для cisco keepalive). Так что теперь все будет в порядке.

Всё бы ничего, но она (циска) при этом напрочь отключает порт, к которому дивайс подключён. Внимание, вопрос: что не так и как должен вести себя прибор в этом случае?

Ну, если loopback первого уровня, то всё понятно: фреймы, уходящие с порта, возвращаются обратно без изменений. Следовательно, роутер может легко принять решение о зацикливании трафика и блокировать порт.

На самом деле, loopback 1-го уровня не использовался (это мы завтра узнаем ;), а в случае петли второго и третьего уровней пакеты при прохождении через наш дивайс изменяются (mac1<->mac2, ip1<->ip2). Беглое чтение документации на маршрутизатор серии Cisco3400 дало понять, что это особенность реализации протокола STP (Spanning Tree Protocol, см.) в роутерах и свичах от Cisco, которые блокируют порт, на котором обнаружен loopback.

В общем, есть подозрение, что проблема в том, что наш loopback заворачивает BPDU (Bridge Protocol Data Unit), которыми свичи обмениваются в процессе работы как раз для определения «левых» петель.

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

Подробно и доступно алгоритм STP и BPDU описаны в википедии.

Литература: IEEE 802.1D-2004 и документация Cisco.