Побег из Vlan. Баг? Хак?! Фича… Или о пользе чтения документации

Доброго времени суток, коллеги.

Снова рискую огрести минусов за капитанство, но все же считаю нижеприведенную инфу полезной. В конце-концов капитанство — не самая низшая ступень. Что бы говорить трюизмы, надо их как минимум знать. И если в быту и в рамках банальной эрудиции это может любой за исключением детей сильно-младшего дошкольного возраста (за летом придет осень), то в сфере профессиональной до этого еще надо дорасти. Так что гуру под кат могут не смотреть. Ну если только повеселиться, это можно…

Пришлось однажды вашему покорному наблюдать картину, которая дала ему почувствовать то самое — даже капитанство не светит, ибо ничего непонятно.
Понадобилось на один пользовательский, давно не использовавшийся линк повесить один хитрый девайс. Наследство дел давно минувших дней — отсутствие документации, каких-либо пометок на розетках и все такое, ну, вы понимаете. Не беда. Подключим девайс, глянем fdb в ядре на предмет mac-адреса, найдем свич доступа, на нем посмотрим все ту же fdb, определим порт и все как надо настроим. Mac известен, девайс подключен, трафик для learning девайс точно обеспечит и «дотянуться» до ядра он должен — ищем.

В ядре (catalyst 35xx)

sh mac address-table | i xxxx.xxxx.xxxx

Но странное дело, mac светится сразу в нескольких Vlan плюсом к тому, в котором как бы должен. Да, на девайсе они действительно подняты (tagged), но порт на свиче доступа (AT-85xx) настроен как untagged. И как tagged он ни в один Vlan не входит. Автор интуитивно (и очень зря, мануалы надо читать!) ожидал от такого «чистого» untagged порта поведения, аналогичного в cisco, когда

switchport mode access
switchport access vlan xxx

Но, как я уже заметил — зря. Дальнейшие изыскания с тестовой машинкой показали, что тэгированный трафик на untagged порт спокойно принимается (при наличии соотв. Vlan-а на свиче, ессно) и форвардится (назад ессно нет).
Занеся на тестовой машине в arp-таблицу статическую запись для некоего IP из управляющего Vlan и подняв его на сетевой как tagged спокойно удалось нафлудить туда чем-то бОльшим, чем arp-запросами. Это плохо.
Ситуацию прояснил мануал. Оказывается, это совершенно нормальное поведение свича, которое может быть отключено командой

set switch infiltering=yes

Правда, в мануале было написано (если я не попутал), что по дефолту команда эта есть и наблюдаемое на практике поведение должно быть отключено. Но не суть. Кстати, через веб-гуи команда недоступна (вот она, причина невежества).

И как оказалось, реальная дефолтовая настройка свича более соответсвует стандарту 802.1Q, чем информация о дефолтовом значении параметра из мануала.

standards.ieee.org/getieee802/download/802.1Q-2005.pdf ^[1]

c. 48

8.6.2 Ingress
Each Port may support an Enable Ingress Filtering parameter. A frame received on a Port that is not in the member set (8.8.9) associated with the VID shall be discarded if this parameter is set. The default value for this parameter is reset, i.e., Disable Ingress Filtering, for all Ports. Any Port that supports setting this parameter shall also support resetting it. The parameter may be configured by the management operations defined in Clause 12.

Автор: casperrr