cAP AC VLAN Switching - аппаратное ускорение

Всё сводится к вопросу: нужно ли вам, чтобы трафик между ether1 и ether2 был проводной скоростью и без нагрузки на ЦПУ? Если да, то необходимо настраивать всё на уровне switch chip (как уже отметил @robtor). И при этом пользоваться обычным мостом, который не работает с VLAN-тегами. Поскольку драйвер wifi-qcom-ac не занимается VLAN, это значит, что потребуется добавить VLAN-интерфейс и дополнительный мост — по одному на каждую VLAN. Всё это увеличит нагрузку на ЦПУ (которое и так уже управляет wifi-драйвером и обрабатывает каждый бит трафика с радиоканалов). Если же ответ нет, то лучше использовать один мост с поддержкой VLAN, а wifi-интерфейсы просто добавлять туда как нетегированные (access) порты с нужным PVID. Такая настройка гораздо проще (только один мост вместо моста, VLAN-интерфейса и ещё одного моста), значит, и нагрузка на ЦПУ на трафик с радиоканалов будет меньше… но при этом нагрузка на ЦПУ для трафика между ether1 и ether2 увеличится (имейте в виду, что трафик между проводными портами и радиоканалами всегда проходит через ЦПУ, аппаратное ускорение на него никак не влияет). Многие ошибочно думают, что при включённом аппаратном ускорении мост может разгрузить любой порт моста. Нет, он разгружает только трафик между парой портов, которые управляются одним switch chip… а радиоканалы вообще не обрабатываются switch chip.

Речь действительно идёт о первом предложении в моём сообщении, которое вы решили пропустить при цитировании: если по каким-то причинам вы не можете или не хотите запускать bridge как VLAN-aware сущность, то описанная мной конфигурация может быть единственным выходом. В таком варианте настройки нужны несколько мостов, потому что надо «промостить» два порта: нетегированный конец VLAN-интерфейса и беспроводной интерфейс. И bridge это делает. Несознательный VLAN-bridge… ну, не понимает VLAN, то есть, например, не работает с VLAN-тегами. Но с радостью пропустит кадры с VLAN-тегами. Если нужно их как-то обработать, а ни железо (например, switch chip), ни драйвер (например, старый драйвер беспроводного интерфейса) этого не делают, тогда приходится использовать VLAN-интерфейсы и мосты. Как всё связать — зависит от того, что надо сделать (например, добавить VLAN-теги по пути между wifi-интерфейсом и основным мостом).

В вашем примере, где bridge понимает VLAN, именно эта конфигурация управляет тегами:  
/interface bridge port  
add bridge=brLAN frame-types=admit-only-untagged-and-priority-tagged interface=wifiWIRELESS pvid=40  

Если bridge не VLAN-aware, то важная часть конфигурации будет такой:  
/interface bridge  
add bridge=brVLAN40  
/interface vlan  
add name=brLAN40 interface=brLAN vlan-id=40  
/interface bridge port  
add bridge=brVLAN40 interface=brLAN40  
add bridge=brVLAN40 interface=wifiWIRELESS  

(этот код заменяет одну строку из примера выше)  

Таким образом создаётся новый мост brVLAN40, который фактически пропускает нетегированные кадры, в приведённом примере — только между wifi-интерфейсом и нетегированным концом VLAN-интерфейса. Затем VLAN-интерфейс обрабатывает VLAN-теги, чтобы основной мост (который охватывает, например, ethernet-порты) мог пропускать теги, при этом сам мост «не в курсе». Со стороны ether-портов тогда можно настраивать VLANы (на каждый порт) в секциях switch chip. Если несколько портов имеют одинаковый pvid, то в «запутанной» конфигурации их просто добавляют в мост, созданный для пропуска трафика этого VLAN.

Как я уже писал, всё зависит от:  
a) способности моста переложить обработку на железо (если может — тогда лучше не городить всё это, а сделать по-простому)  
и  
b) доли трафика, которая идёт между проводными портами (если объёмы небольшие, не заморачивайтесь, используйте VLAN-aware bridge).  

Когда я делал быструю проверку, hAP ac2 (который не умеет сливать VLAN-функции с моста на switch chip) мог мостить между двумя ether-портами на скорости провода при загрузке CPU около 50% (то есть, наверно, он умеет так же вести пару портов на проводной скорости, ограничение — 2 Гбит/с связка между CPU и switch chip), при этом CPU ресурсы оставались для нормальной работы беспроводной сети. cAP вообще менее проблемный, там всего два ether-порта.  

Но если устройство слабее по CPU, медленнее связь и медленнее вайфай (например, RB951G), то описанный мной метод может заметно улучшить общую производительность устройства (не нужно заморачиваться, если девайс работает с legacy wireless, так как в этом случае поддерживается манипуляция VLAN-тегами, и мои RB951G не используют такую «костыльную» схему).