Community discussions

MikroTik App
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 19099
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

WIFI + BRIDGE + VLANS (access,trunk,hybrid)

Sat Mar 11, 2023 5:32 pm

The basic question, can you send vlan tagged frames like a trunk port approach over WLAN.
All I know is sending untagged data over WLAN.
Begs the question I suppose as well about hybrid!!

@bpwl can you tag a WLAN??

typical MT setup - access port
/interface bridge port
add bridge=bridge interface=WLAN1 pvid=5
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=WLAN1 vlan-ids=5

Possible?
trunk port
/interface bridge port
add bridge=bridge interface=WLAN1
/interface bridge vlan
add bridge=bridge tagged=bridge,WLAN1 vlan-ids=5
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 19099
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: WIFI + BRIDGE + VLANS (access,trunk,hybrid)

Sat Mar 11, 2023 5:33 pm

ANSWER

What happens with the WLAN1 wireless settings ..... when set to

(case 1) If "Vlan mode = use tag", "VLAN ID = 5" , the packets from the bridge will be filtered on VLAN ID, will be tagged when sent to the bridge, untagged when sent to wifi
WLAN1 now acts a a VLAN aware switch, where the wifi side is an access port for PVID=5, and the bridge side is a trunk port
(*) !

(case 2) If "Vlan mode = no tag", "VLAN ID = 1" , no VLAN filtering done, the packet tags will not be touched when sent out to wifi, or when received from wifi
WLAN1 now acts as a dump switch, totally unaware of VLANs, and just forwards everything as is.

Your Access port
case 1: WLAN wifi will send packets it receives as tagged with the correct VLAN ID from the bridge as untagged wifi , and delivers wifi received untagged as VLAN tagged to the bridge : not as expected for a bridge access port
case 2: the VLAN 5 packets will be untagged by the bridge (access port) and as such sent and received as untagged by WLAN wifi (as is / untouched / dumb / transparent )

Your Trunk port
case 1: WLAN wifi will send and receive VLAN tagged packets from and to the bridge with the correct VLAN ID, and wifi send or receive them as untagged wifi.
case 2: the VLAN packets if delivered as VLAN tagged by the bridge are sent and received untouched as VLAN tagged wifi by WLAN (VLAN over wifi is no problem, even hybrid)

(*) access lists overrule the VLAN ID and VLAN Mode "use tag" or "no tag" setting per connection , if set in the access list rule !!! I expect RADIUS attributes to do similar things.

case 1 : WLAN1 bridge side is tagged, wifi side is untagged
case 2 : WLAN1 unaware of VLAN, just forwards as is

Double VLAN tags to be studied. (VLAN tunneling, Q-in-Q, Tag stacking, ..... ) .... pfffff
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 19099
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: WIFI + BRIDGE + VLANS (access,trunk,hybrid)

Sat Mar 11, 2023 5:34 pm

Your answer was confusing
I DONT USE wifi settings to apply any VLAN etc...

Therefore the response made no sense to me. :-(
I apply vlans through interface bridge port and bridge vlan settings only.

After re-reading I understand that CASE 2 is exactly what I am asking and based on vlanid=1 on the wifi settings as default as being equivalent to what I normally do.

+++++++++++++++++++++++++++++++++

Therefore, the standard wlan setup with vlans and bridge that I have seen is your case 2.
case 2) If "Vlan mode = no tag", "VLAN ID = 1" , no VLAN filtering done, the packet tags will not be touched when sent out to wifi, or when received from wifi
WLAN1 now acts as a dump switch, totally unaware of VLANs, and just forwards everything as is.

Your Access port as follows = THE NORM
case 2: the VLAN 5 packets will be untagged by the bridge (access port) and as such sent and received as untagged by WLAN wifi (as is / untouched / dumb / transparent )

Note: Exactly we are feeding dumb devices !

Your Trunk port = THE NEW and the reason for this thread.
case 2: the VLAN packets if delivered as VLAN tagged by the bridge are sent and received untouched as VLAN tagged wifi by WLAN (VLAN over wifi is no problem, even hybrid)

Note: Excellent so this is like a standard trunk port as you noted above the WIFI settings dont touch vlans and thus its like a bridge port (neutral).
Note: Useful for feeding smart devices over wifi that can read vlan tags!!


Thus for a hybrid port. The assumption as you alluded, by assigning a pvid on the bridge WLAN port and tagged vlans on /interface bridge vlans will allow a hybrid situation over WIFI. Transparent in a way.
++++++++++++++++++++++++++++++

Conclusion by staying with the status quo ( not touching wifi settings), the WLAN port will act in the same manner as a physical bridge port!!
 
User avatar
anav
Forum Guru
Forum Guru
Topic Author
Posts: 19099
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: WIFI + BRIDGE + VLANS (access,trunk,hybrid)

Sat Mar 11, 2023 5:51 pm

I want to better understand Case1, in case their is a scenario where it may make sense to use it.
However I cannot wrap my head around Case 1, if you do assign vlan-id=5, vlan-mode=use tag!

More specifically what do you then do on the /interface bridge port settings and /interface bridge vlan settings for access port or trunk port scenarios???
By the way it almost sounds like your stating DONT use vlan-id and vlan mode in wifi because traffic is non-standard and will be different from expectations.

A couple of practical example may help to illustrate....
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11433
Joined: Thu Mar 03, 2016 10:23 pm

Re: WIFI + BRIDGE + VLANS (access,trunk,hybrid)

Sat Mar 11, 2023 6:15 pm

I want to better understand Case1, in case their is a scenario where it may make sense to use it.
However I cannot wrap my head around Case 1, if you do assign vlan-id=5, vlan-mode=use tag!

More specifically what do you then do on the /interface bridge port settings and /interface bridge vlan settings for access port or trunk port scenarios???

If wifi driver is configured to tag/untag on its own, then wifi as bridge port has to be configured as tagged member of same VLAN. Because frames, passed from wifi driver to bridge will be tagged already. And wifi driver expects packets, passing from bridge to wifi driver, to be tagged.
/interface wireless
set [ find name=wlan1 ] vlan-mode=use-tag vlan-id=666
/interface bridge port
add bridge=bridge interface=wlan1 frame-types=admit-only-vlan-tagged ingress-filtering=yes
/interface bridge vlan
# assuming VID 666 is being introduced to bridge
add bridge=bridge tagged=bridge,wlan1 vlan-ids=666

I don't see use case for wifi driver to do tagging/untagging if wifi interface is port of vlan-enabled bridge. Further more, if one uses capsman with local forwarding, it's easier for capsman to add wireless interface as access port to bridge (on cap device) - it only has to add bridge port with appropriate PVID set, port will be added as untagged member to corresponding VLAN automatically (or so is my understanding). Probably it's similar with local forwarding disabled, only in this case capsman has a tad better control over bridge setup as the bridge being used is on same device as capsman.

The use case for wifi driver to do tagging/untagging was before 6.42 where bridge was a dumb one and all tagging/unragging had to be done by drivers/hardware running member ports (e.g. switch chip or wifi driver or vlan interface). Legacy driver kept the possibility to do tagging/untagging (because dropping this code could introduce some bugs, removing old code can do that).
In wifiwave2 driver it's possible to set vlan-id (under datapath) and since it is then shown in export and it's possible to unset it, I guess setting it is same as setting both vlan-id to some value and vlan-mode to use-tag in the legacy wireless interface. I'm sure you'll try and see if you can tell me I'm wrong :wink:
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 2983
Joined: Mon Apr 08, 2019 1:16 am

Re: WIFI + BRIDGE + VLANS (access,trunk,hybrid)

Sat Mar 11, 2023 11:21 pm

Indeed the "old" way of using VLAN was handling VLAN in the Switch (menu) and handling VLAN in the WLAN driver. Sometimes but not always was also a (VLAN unaware) bridge used per VLAN, to handle them in a separated way.

Then came the VLAN bridge model. Where the bridge was doing the tag/untag and VLAN filter function. The Switch had no extra VLAN settings anymore , as those could conflict with the bridge introduced settings in the switch chip with bridge HW offloading.

The new model is/was not perfect. The switch hardware in many devices could not handle all VLAN functions in HW offloading. If you still wanted the HW offloaded performance gain, then the VLAN settings had to be done in the Switch, not in the Bridge. And because WLAN is not connected to the Switch, also the WLAN had to handle the VLAN tag/untag. (iow: return to the old model)

Some people lost some other features, which are common with other brand AP's. That is dynamic assignment of a VLAN, mostly seen in wifi connections.
(It is also used in secured corporate Windows AD based environments on cabled connections, where a client is first connected to a validation VLAN, and only admitted to the operational VLAN after tests and the required anti-malware updates. (Windows AD does the same also via IPsec) https://www.portnox.com/blog/network-se ... ssignment/ )
Dynamic VLAN assignment can be defined in MT ACL access list entries for WLAN, e.g. based on MAC address, but is also defined via RADIUS for a RADIUS entry.
e.g. The VLAN assigned depends on the RADIUS user and group ID, and the authorisation to connect to certain department systems and LAN. (HR, Finance, Corporate, IT, ...)

In MT we already are lacking ePSK, dPSK and mechanisms alike, to connect to a VLAN depending on the shared secret used,and this for the same device/MAC address.

With the VLAN functionality moved to the bridge, the WLAN driver lost the ability to assign a VLAN to a connection.

Some of us are glad this WLAN functionality came back in the wifiwave2 driver. (currently for the ax hardware only) viewtopic.php?t=191008

So both models (bridge managed VLAN) and (Switch and wifi driver managed VLAN) are usefull solutions.
And having one SSID for each VLAN in the first model is necessary but not optimal.

My case ... 20 holiday houses in one resort, 40 named users (HOST and TENANT are separate multi-device families/users ), 30 AP , would need 40 SSID per band in each AP (2400 beacon broadcasts every 100ms), with full roaming and to fully separate them VLAN based. (Now it is implemented with a limited number of VLAN, because 400 devices is too much for one extended wifi LAN network. And my current RADIUS server has no attributes, and MT Usermanager V5 (ROS7) has only a limited # of sessions for license level <6. FreeRADIUS is only in test)
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 2983
Joined: Mon Apr 08, 2019 1:16 am

Re: WIFI + BRIDGE + VLANS (access,trunk,hybrid)

Sun Mar 12, 2023 11:23 am

A couple of practical example may help to illustrate....
Well again my basic case ... holiday resort.
The VLAN over wifi is used extensively in the wireless (and wired) backbone connections. The client facing AP's (not drawn in this diagram) are using the VLAN ID to untag either in the bridge (static) or in the wifi driver. As the assigned VLAN ID must be userid specific (RADIUS assigned) the bridge static tag/untagging will be removed.

The backbone carries all VLAN's tagged. (this design coming from 4 VLAN's split and untagged by the Powerboxes, now all VLAN go to all endoint AP's, not to client devices)

Backbone network
... nodes are Powerbox Pro ,
interconnected with Cube or wired,
downstream to SXT SA5 ,
then PtMP to SXTsq's ,
going to RB260 ,
going to client facing hAP,wAP and cAP
backbone R.jpg
As clients are allowed to connect to any wAP,cAP or hAP, all VLAN go to all those AP (filtering would be useless) RB260's have no VLAN defined (dumb switch config)
Splitting clients over VLAN helps reduce broadcast, multicast traffic. And broadcast and multicast is horrible traffic for wifi if not tunneled. (basic rate airtime consumption)
Just check what on such a network a client device does when seeking it's home printer, the corporate laptop seeking it's AD server and file-shares, Apple devices with "Bonjour", casting app's like chrome cast, and app's like Skype, Dropbox, Windows upgrade downloads that try to get their data from any other device on the same LAN.
Using same bridge horizon value on the downlinks , and no forwarding in the PtMP SXT SA5 further reduces broadcast and multicast propagation.(depends on what you want to allow)

I just wonder how CAPsMAN would handle VLAN tag/untag for local forwarding. In bridge or WLAN driver ?

Other practical exemple ... anytime you want to have more VLAN's accessable via wifi, but do not want to create the extra SSID overhead.
At home it happens also: many new appliances have cloud access for service or for remote access to the units.
Airco Italian company, bathroom heating German company, sunscreen controller French Company, rainwater pump, expressomachine, doorbell, camera, chrome cast, domotica, ... all via different cloud services. There is one IOT VLAN now for this, but should heating and access control be in the same VLAN ? Better not. One VLAN per vendor or cloud server is the safest but that would be many SSID when VLAN handled by the bridge. And 6 SSID on 5 AP would already send 30 beacons every DTIM period, 300 per second at basic rate. With VLAN handling in the WLAN driver, and using ACL, just one SSID will do for "n" VLAN ("n" could become a large number).
In the city hall network we had many more services, most with wifi connected devices, interactively handled from the servicing offices (access control, heating, ventilation, airco, billboards, solar pannels, water pumps, ticketing system, sun screens, alarm systems, cameras, board room audio/video/voting system, auditorium projection, etc etc ... separation was manadatory ! Large building 35 AP with full wifi overlap.
You do not have the required permissions to view the files attached to this post.

Who is online

Users browsing this forum: Bing [Bot], jerogabe, MaxwellsEq, synchro and 33 guests