I’m baffled as to what the heck is happening when I seemingly configure the switch menu correctly, yet traffic just does not do what is intended
At the moment most of our PowerBox deployments are configured solely with the Bridge menu, as it’s much simpler to do so. The downside is no hardware offload support when using VLAN’s and Split-Horizon override, hence the throughput is not sufficient when trying to push a few hundred megabit/s. And thus the need to instead use the Switch menu for performance reasons
So lets stick with 1 example for this post
ether1 is directly connected to a customer, is an access port on VLAN10, not allow any other VLAN’s and must be isolated from all ports except ether2
ether2 is an uplink port, all traffic/vlan’s allowed
ether3 goes to a customer but via a radio link, must be isolated from all ports except ether2 but no VLAN filtering should take place
Using bridge menu setup this is really simple
Create a bridge, enable VLAN filtering, add all ports
Set horizon=1 on all ports except ether2
ether1 set PVID=10, frame type=only-untagged, ingress filtering=yes
Go to VLAN menu, create VLAN10 and add all ports as tagged except ether1 (which gets dynamically added via PVID)
Mission accomplished, except crap performance as traffic hits the CPU instead of just the switch chip
So i’m trying to migrate to using the Switch menu and configure as follows
/interface ethernet switch port set ether1 default-vlan-id=10 vlan-mode=fallback vlan-header=always-strip
port isolation, enable forwarding override on ether1/ether3 and specify ether2
VLAN menu create VLAN10 and add all ports
Go back to Bridge menu, disable VLAN filtering
in Bridge Ports menu, remove horizon value, remove all filtering
In Bridge VLAN menu, delete as not needed anymore
Except it just doesn’t work. Ether1 is completely unreachable and no traffic flows unless I remove the VLAN. and isolation between ether1 and 3 doesn’t work
What am I missing? ROS version is 6.48.7
These two lines are telling the opposite. According to your description, ether1 should be tagged for VLAN 10, i.e. pvid not set and frame-types=allow-only-vlan-tagged. Or, in switch chip parlance, default-vlan-id not set and vlan-header=leave-as-is (which is default). Adding such port as vlan member then means that port is tagged.
/interface ethernet switch port set ether1 default-vlan-id=10 > vlan-mode=fallback > vlan-header=always-strip
If you bother with security settings (vlan-header and vlan-mode), then you should set vlan-mode=secure … for all ports.
Warning: Switch chips with a VLAN table support (QCA8337, Atheros8327, Atheros8316, Atheros8227 and Atheros7240) > can override the port isolation configuration when enabling a VLAN lookup > on the switch port (a vlan-mode is set to fallback, check or secure). If additional port isolation is needed between ports on the same VLAN, a switch rule with a new-dst-ports property can be implemented. Other devices without switch rule support cannot overcome this limitation.
I thought it was fairly clear given that I outlined requirements as well as existing bridge mode config
Terminology depends on your perspective. As an ISP the customer is on and remains solely in VLAN10
Ether1 is an access port, untagged traffic only. Will end up on VLAN10 by the time it egresses out ether2. Is clear now?
Point is the bridge mode config works fine. Switch menu config does not. So based on the 2 Configs - bridge config working perfectly. Switch config not - what is wrong?
Well, you changed the wording of “requirements” in the line I was pointing out. Now it seems to be consistent with outlined configuraton.
But the deal breaker is the last quote in my previous post: if you enable VLAN tag manipulation on switch port by setting vlan-mode to anything but disabled, then switch chip port-isolation feature may not work any more. Work-around is mentioned in the manual document I linked.
Which means that what you see is documented and thus title of this thread is, mildly put, misleading.
I think the MikroTik help page is wrong, or has bad wording that isn’t clear
I also think it’s just a complete bug, and things are broken and cannot be implemented as expected
Here is a direct quote from the site
Note: QCA8337 and Atheros8327 switch chips ignore the vlan-header property and uses the default-vlan-id property to determine which ports are access ports. The vlan-header is set to leave-as-is and cannot be changed while the default-vlan-id property should only be used on access ports to tag all ingress traffic.
This to me reads as “QCA8337 will ignore the VLAN header field, don’t bother using it. Just set the default VLAN ID and make sure it also exists in the ‘VLAN’ tab” but this is just wrong. The only way I can get traffic to work on an access port on the correct VLAN is by setting it as ‘always strip’ -and- setting it to ‘add-if-missing’ on the uplink/trunk port
So again..
ether1 is ‘untagged’ on VLAN10
ether2 is an uplink/trunk port (All VLAN’s, as well as native/untagged)
ether3 is a hybrid port (untagged + VLAN10)
If I leave ether2 & ether3 as both ‘leave-as-is’ for the VLAN header field, then all traffic between them works exactly as expected. It’s just a simple switch that flows all traffic regardless. However customer on ether1 is still on native and this is incorrect, needs to be on VLAN10
if I set ether2 to ‘add-if-missing’ then customer on ether1 appears correctly on VLAN10 and traffic flows just fine, customer works. But VLAN10 is now broken for ether3
The only 2 scenario’s I can get working at the moment are…
Uplink port + access ports on VLAN’s other than native. All other trunk/hybrid ports are broken for anything other than untagged traffic
Uplink port + hybrid ports, but all access ports will always be untagged on the uplink
I have a few devices, based on (some sort of) AR8327 (RB951G, hAP ac2) … which is “victim” of the same note you quoted above. And the way the note should be interpreted is, according to my experience, roughly the way it’s phrased … so that vlan-mode setting is ignored. However, my experience is that one can set it according to what it should be … but just for peace of mind (as stated in note, it doesn’t affect the way switch chip does its job). The note is imprecise only in this aspect. However, reading the note as “switch chip will ignore VLAN header” is completely unwarranted.
The way it works for me is:
on access port, set vlan-mode=secure vlan-header=always-strip default-vlan-id=
on trunk port, set vlan-mode=secure vlan-header=leave-as-is default-vlan-id=auto (property vlan-mode is not at default value, the other two are essentially left at default)
I have set this set of properties also on switch1-cpu port and all devices (including the one used as router) can work with necessary VLANs just fine.
on hybrid port, set vlan-mode=secure vlan-header=leave-as-is default-vlan-id= (property vlan-header is left at default value)
In all cases I’m setting ports to proper VLAN membership under /interface/ethernet/switch/vlan. I have different mix of access/hybrid/trunk ports on each of mentioned devices, trunk ports are used for connection towards core switch (which is set for tagged-only traffic) and everything flows smoothly, so access and hybrid ports work as desired.
Note: the warning about port isolation not being guaranteed to work still holds …
What exactly do you have in mind when saying “native/untagged”? The “native” has slightly different meanings when it comes to different vendors, Mikrotik’s parlance doesn’t know this word. Hence when saying “native” in MT world, one has to first define which VID will be used for “native” VLAN … default VID, used all over place, is VID=1 … so when configuring “native” interfaces, one has to think about VLAN 1 as well. The problem is that it’s used as factory default (don’t confuse “factory default” with “default” as selected in QuickSet) and export actually shows difference between factory default setup and actual setup, so it’s necessary to consult either output of export verbose or even print detail to see what’s factory default regarding VLANs.