Помощь с решением по проводке

Во-первых, CAPsMAN — это способ упростить жизнь при настройке множества точек доступа и снизить требования к возможностям транспортной сети. Он не обязателен для обеспечения роуминга и не делает его проще или быстрее. Клиенты могут свободно переключаться между индивидуально настроенными точками доступа с одинаковым SSID с той же лёгкостью (или сложностью), что и между точками доступа, централизованно настроенными через CAPsMAN.

Во-вторых, попробую переформулировать последний пост @tdw и немного его дополнить. При использовании автономных точек доступа или точек доступа с CAPsMAN и включённым local-forwarding=yes, для каждого SSID на пути от точки доступа до центрального роутера требуется отдельный VLAN, чтобы изолировать сети, а значит транспортная сеть должна поддерживать VLAN. Пока не встречал “глупый” коммутатор, который не поддерживал бы VLAN-тегированные кадры (т.е. длиной 1518 байт), но лучше перестраховаться.

Если же local-forwarding=no, кадры с точек доступа отправляются на устройство CAPsMAN инкапсулированными и зашифрованными в UDP с внутренней информацией о беспроводном интерфейсе, к которому они принадлежат. Тогда VLAN-тегирование между точкой доступа и CAPsMAN не требуется, а возможное преобразование SSID в VLAN ID, если вообще нужно, происходит уже на устройстве CAPsMAN. Это значит, что для подключения нескольких точек доступа к CAPsMAN можно использовать простой коммутатор, если позволяет пропускная способность.

Возможно, VLAN и вовсе можно не использовать — если я правильно понял, гостьевой SSID будет L2-прозрачно связан с LAN-портом оборудования провайдера, который обеспечивает гостям DHCP и прочее. Тогда на CAPsMAN можно создать специальный мост, например br-guest, и сделать беспроводные интерфейсы с SSID guest участниками этого моста вместе с Ethernet-портом, подключённым к оборудованию провайдера. А беспроводные интерфейсы с SSID “company” можно включить в другой мост, на котором CAPsMAN будет управлять DHCP, маршрутизацией и прочими вещами.

Что касается замечания @anav по поводу использования Mikrotik cAPs, суть в том, что сейчас несколько конкурентов предлагают точки доступа с большим пропускным способностью, чем устройства Mikrotik, особенно в диапазоне 5 ГГц. Лично я считаю, что это стоит учитывать только если пропускная способность канала настолько большая, что пропускная способность беспроводной сети может стать узким местом. Иначе ни для гостевого WiFi в ресторане, ни для мобильных терминалов персонала для приёма заказов и оплаты это не будет проблемой. Не стоит забывать, что у вас будет несколько точек доступа, и канал uplink будет разделён между ними всем.

Например, две точки доступа с 500 Мбит/с (что Mikrotik легко обеспечивает на 5 ГГц) полностью загрузят канал uplink со скоростью 1 Гбит/с. А вот серьёзной проблемой может стать скорость роуминга — официанты быстро передвигаются между точками доступа. Роуминг контролируется не точками доступа, а самими терминалами, которые следят за уровнем сигнала и переключаются на лучший, если он стабильно доступен.

Но крайне важно, чтобы пересылка данных с/на отдельные беспроводные интерфейсы, подключённые к мосту, не блокировалась каким-то вариантом протокола spanning tree, который срабатывает, когда последний клиент отключается от беспроводного интерфейса и тот становится неактивным. Если на мосту только один Ethernet-порт, можно просто отключить spanning tree, установив protocol-mode в none. Если же нескольких Ethernet-портов больше и spanning tree нужен, то беспроводные порты надо настроить как edge-порты (и, возможно, потребуются ещё какие-то настройки, я недавно видел соответствующую информацию), чтобы при повторном включении беспроводного порта мост сразу начал пересылать данные, не ожидая около 15 секунд BPDUs протокола spanning tree.