VLAN Truck, объединение немаркированных пакетов.

Кстати, MikroTik, в этой ветке KernelTrap есть полезная информация: http://kerneltrap.org/mailarchive/linux-netdev/2010/7/18/6281280. Aaron out.

Решался ли кто-нибудь с этой проблемой? У меня та же самая ситуация. С моим Cisco-коммутатором без проблем назначаю немаркированные пакеты в VLAN по умолчанию на транке, но с RouterBoard никак не получается сделать то же самое.

Спасибо за ответ, но в моей ситуации это не сработает. Посмотрите мой другой пост: http://forum.mikrotik.com/t/vlan-issue-between-two-routers/41585/1 Я не использую коммутатор. Я просто привел его как пример того, что я хотел бы видеть.

Попробовал ли ты как-нибудь соединить интерфейс на нижнем уровне, а потом использовать правило брандмауэра на мосту, чтобы убрать всю помеченную трафику? Просто идея, я особо не смотрел на фильтры мостов, чтобы понять, можно ли их убедить это сделать. Может, получится что-нибудь сделать в связке с mangle/marking. Если у тебя Routerboard с чипом коммутатора, смотрел ли ты там, есть ли какие-нибудь полезные опции? (Ответил здесь, так как касаюсь именно темы:).

ЗАПРОС НА РЕАЛИЗАЦИЮ функции для MikroTik: разрешить создание VLAN с vlan-id=0 и, если такой VLAN-интерфейс подключен (и активен) на интерфейсе, направлять весь входящий НЕОТМЕЧЕННЫЙ или НУЛЕВО-ОТМЕЧЕННЫЙ трафик на VLAN-интерфейс с vlan-id=0. Для трафика, выходящего через VLAN-интерфейсы с vlan-id=0, добавить новый пункт конфигурации priority-tag=yes|no, чтобы указать, следует ли выводить кадр с нулевой отметкой (т.е. 4-байтный тег VLAN с VLAN ID нуль – принадлежит НИ ОДНОЙ VLAN, поэтому тег служит только для указания приоритета), или (если “no”) выводить кадр БЕЗ тега. Это решит все проблемы, упомянутые в этой теме (и упомянутые мной и упомянутые многими другими в других темах), позволив использовать комбинацию помеченного и непомеченного трафика на интерфейсе и предоставив РАБОЧИЙ способ обработки трафика. Спасибо! Aaron out.

Вкладку правил, под разделом Switch, можно использовать, чтобы добавить правило с Match, VLAN, VLAN header not present, которое будет применяться только к пакетам без VLAN-заголовка. Кстати, если установить новый VLAN ID в 0, то это, похоже, значит "удалить". Можно как-то обойти ограничение ввода/вывода, используя поля MAC-адреса источника и назначения (которые могут быть диапазоном), чтобы сопоставлять пакеты, приходящие к/от ваших радиомодемов (вместе с сопоставлением VLAN, на случай, если у ваших клиентов есть какие-то из этих радиомодемов). Например: порты 1,2,3, MAC-адрес источника: xx:yy:zz:00:00:00/00:xx:yy:ff:ff:ff, VLAN header: not present, это значит, что пакет от одного из моих радиомодемов, действие: установить новый VLAN ID 10. Порты 1,2,3, MAC-адрес назначения: xx:yy:zz:00:00:00/00:xx:yy:ff:ff:ff, VLAN ID: 10, это значит, что пакет предназначен для одного из моих радиомодемов, действие: установить новый VLAN ID 0. Где xx:yy:zz – это MAC-адрес(ы) производителя ваших радиомодемов (возможно, потребуется несколько копий правил, если их больше одного и они не смежные). Это работает, только если VLAN 0 действительно означает "неотмеченный/без VLAN". Если так, что входящий VLAN-10 всегда приходит от CPU, а радиомодемы всегда на физических портах, можно, наверное, избавиться от src/dst MAC и просто использовать порты для обозначения входящего/исходящего (например, преобразовать неотмеченное на 1,2,3 в VLAN-10, преобразовать VLAN-10 от CPU в неотмеченное (VLAN-0)). Кстати, если память не изменяет, кажется, есть ограничение на количество правил, которые может обработать коммутатор, и оно может быть связано со сложностью правил, кажется, это было что-то вроде 32 "шага", но я немного заржавел в этом вопросе.