VLAN switch fallback or secure

RouterOS General
1

router: RB2011 , ROs 6.40.9

Got a VLAN setup on Ether 6 connecting to an unmanaged Alloy switch, and the setting has automatically chosen fallback as the setting in the /switch/port/vlan mode.
This all works fine for devices that have their VLAN ID set correctly, but I wanted to lock the ether6 interface so that rogue devices plugged in wont pick up DHCP from other subnets on the router, i.e. it only allows correctly configured VLAN ID devices through the interface.

in looking for answer on setting this correctly, I came across this article http://forum.mikrotik.com/t/vlan-not-working-with-switch-chip/116125/1
which suggests setting the interface switch port to vlan mode “secure” for when I eventually upgrade to RoS 6.41.

From my understanding the article it seems to suggest switch becomes obselete after 6.41 to be replaced by vlan-filtering on the bridges. I would rather choose correctly now for future upgrades not to impact my setup later when I forget this point.

So my question is: should I be setting this ether6 switch port vlan mode to secure in order to be future compliant, as well as locking out rogue devices inbound to the interface.

2

Cureent ROS versions allow dealing with VLANs in two ways: nww way using bridge vlan-filtering and old way with switch chip settings. You can (for now, no ETA) safely continue to use old way after upgrading to current ROS. AFAIK switch chip setup is not translated to bridge vlan-filtering (yet) on upgrade.

And setting vlan-mode to secure has nothing to do with ROS version either, so go ahead and do it.

3

unfortunately this hasnt worked, in fact setting the port to “secure” effectively disconnected all the phones going through it. I used torch to observe the traffic and could see only rx traffic and no tx.

the switch is an Alloy unmanaged, but works with VLAN and the VLAN ID tagging is coded into the Cisco Phones, as well as being set on the router.

I had to switch the setting back to “fallback” and they all started working ok immediately.

any ideas why this would be? the phones communicate out to a cloud PBX for authentication and voip traffic.

4

You can post relevant part of configuration (e.g. /interface export) and we can have a look.

5

The setting of /interface ethernet switch port vlan-mode to secure restricts the VLANs allowed on that port to those for which the port is placed on the ports list of the corresponding /interface ethernet switch vlan row. So to permit only VLANs 3,17,29 on port ether6, you have to configure

/interface ethernet switch vlan
add vlan-id=3 ports=ether6
add vlan-id=17 ports=ether6
add vlan-id=29 ports=ether6

/interface ethernet switch port
set ether6 vlan-header=leave-as-is default-vlan-id=auto vlan-mode=secure

Or you may use the bridge with vlan-filtering=yes as introduced in 6.41 and ignore the switch menu completely, in the hope that one day the vlan filtering will become executed by the switch chip under control of the bridge configuration menu.

6

When I set the switch port to secure and observed traffic on the interface, nothing was passing across the interface except discovery packets and when observing the interface tx and rx levels tx remained at 0 while rx had small activity, oddly there was some signalled traffic on the interface graph for both directions but it didnt show up on Torch for the interface, so literally nothing was moving across the interface that Torch could observe. The phones pickup DHCP ip address from the DHCP pool on the Vlan60 interface. Once I set it back to fallback, then I could see the vlan tagged (60) traffic on the interface when running Torch. Here is my snipped export of /interface,

incidently the VLAN60 traffic goes out its own seperate public ip address but I don’t expect that to matter in this issue.

# oct/12/2018 08:35:59 by RouterOS 6.40.9
# software id = F79J-8IIS
# model = 2011UiAS-2HnD
# serial number = 
/interface ethernet
set [ find default-name=ether1 ] comment="WAN Link" name=ether1-gateway
set [ find default-name=ether6 ] comment="[VLAN60] - 192.168.60.0/24" name=ether6-TRUNK-local
/interface vlan
add interface=ether6-TRUNK-local name=vlan60 vlan-id=60
/interface ethernet switch port
set 6 default-vlan-id=60 vlan-mode=fallback
7

aha, just spotted this! it actually eluded me on the first read because the wording suggests I had already done this since I set the port on the switch to the vlan id 60, but I just checked the webfig of the router, and can see that there is nothing set in the /Switch/Vlan section. So this may be the cause. Seems like an odd additional step to have to take, given the other settings all seem to cover this already, but I will schedule another change and see if it works. On whatever instructions I found online for this I do not believe this step was mentioned.

8

It is hardware, so you cannot expect things to be linked together in such a sophisticated way. The default-vlan-id value is used solely when deciding whether to tag/untag the frame on ingress/egress, but it doesn’t automatically modify the contents of the vlan<->port map which is consulted at a different stage of the frame’s journey through the chip.

And yes, I agree that it is not really clear from the manual: under VLAN Table, there is a sentence saying that Basically the table contains entries that map specific vlan tag ids to a group of one or more ports, but the existence of /interface ethernet switch vlan configuration subtree is not mentioned there and you have to discover it below in the examples.

9

still not working. I added the following in and as soon as I enabled it, the traffic doesnt get through interface Ether6, and it is unreachable beyond. (even without changing to secure, it is still set to fallback at this point) Really odd. I must be missing something else. ports 1 to 5 are on switch 1 and port 6 is on switch 2. Is it possible this is something to do with the issue?

/interface ethernet switch vlan
add disabled=yes ports=ether6-TRUNK-local switch=switch2 vlan-id=60
10

If ports carrying same VLAN don’t belong to same switch chip, then you’ll have to use a CPU bridge between them. There are two possibilities: a) create dedicated bridge for particular VLAN or b) use common bridge (which, if configured that way, will transparently carry on VLAN). Which way is better depends on the rest of config you have. In either case you’ll have to admit VLAN 60 through both switchX-cpu “ports”.

11

my WAN is on Ether1, Ether1 is on switch 1 , switch 1 has vlan disabled, switch 1 cpu has vlan disabled
my VLAN60 is on Ether6, Ether6 is on switch 2, switch 2 has vlan on fallback, switch 2 cpu has vlan on fallback

If I have to start changing switch 1 then it is getting into territory where I might lock myself out of the router accidently, so I can’t continue, as I am doing this remotely and wont be going near the site for some months.

The only bridges I have currently are the ones serving the wireless caps, hotspot and the Ether5 they are on.

I am not sure I really grasp why it needs a bridge since the traffic is not getting into the router, it is stopping at the interface, so why would bridging the interface/VLAN make any difference?
It also confuses me since VLAN tagging is supposed to be “removed on ingress and added on egress”, or maybe I misunderstood that bit too.

anyway thanks for your help, but I can’t risk knocking myself off the system so I will have to leave it at that until I visit in a few months and can fiddle with it then.

12

Things like this are best debugged on a system which you’ve got on the table next to you and only then ported to the production device running on another continent. But given that you don’t need to forward frames between switch1 and switch2 at L2, you don’t need to touch switch1’s configuration, so you’re safe.

Normally (switches of all other vendors I know, switch chips), tags are added on ingress and removed on egress, not vice versa. Only mikrotik’s bridge implementation in software can remove tags on ingress and add them on egress because tagless frames are permitted inside the bridge, but that’s one of the anomalies of the Mikrotik world.

When you sniff (not torch) the traffic on ether6 with the item in /interface ethernet switch vlan disabled, can you see the 802.1Q tags with VID=60 on the frames or not?

My wild guess is that you have to set also the switch2-cpu port to fallback mode before enabling the item above, but if it is the case, it actually means that you have to set the fallback mode on all ports of switch2. It was working for me in the past on the 8227 and I do remember I had to fiddle with the CPU port as well.

13

I had to debug it, and as a side effect I have found that there is an issue in at least 6.43.2 (see in gray below).

To use secure mode for tagged frames on etherX in 6.43.2, it is enough to set just two things in the switch chip configuration provided that the /interface vlan is hosted directly on etherX (which is your case):

  • the etherX must be listed in the ports list of /interface ethernet switch vlan row for the vlan-id in question,
  • the vlan-mode of etherX must be set to secure

If you use a port on AR8327 and the connected equipment expects tagged frames from you, the default-vlan-id of etherX must not be set to the VID in question, as the AR8327 would untag frames tagged with that VID on egress. So your default-vlan-id=60 would be a mistake on a port of AR8327, but is harmless in your particular configuration.

If the /interface vlan is hosted on a bridge of which etherX is a member port, also the CPU port of the switch must be listed in the ports list of /interface ethernet switch vlan row for the vlan-id in question (regardless what is the vlan-mode on the CPU port).

So all in all - something may behave differently in 6.40.9 than it does in 6.43.2, and the only way to find out is to try the same configuration on both.

But most important - as you have attached the /interface vlan to ether6 directly, not via a master port, an upgrade to 6.41+ won’t change anything about how it works without vlan filtering on the switch chip. Only master-port configurations are auto-converted to bridge configurations by the upgrade.

So the only advantage of vlan filtering in the switch chip is that frames tagged with other than permitted VIDs are dropped already by the switch chip and never make it to the CPU.



On RB2011, ether1 to ether5 are on AR8327, which can both tag on ingress and untag on egress depending on the default-vlan-id value. And it works, as tested elsewhere.

However, ether6 to ether10 are on AR8227, which tags on ingress depending on the default-vlan-id value, but is unable to untag on egress selectively depending on VID - according to the manual, you can either keep tagged frames tagged and untagged frames untagged (leave-as-is), or you can untag everything (always-strip), or you can even tag tagless frames on egress (add-if-missing) - but I’ve never tested what it really does.

And the issue I’ve found is that always-strip simply doesn’t work at least in 6.43.2 (on hAP ac lite, I have no RB2011 to test on), at least for frames which ingress via the CPU port. Whichever of the three modes of tag handling on egress you configure on the ethernet port, it keeps emitting tagged frames to the wire. I don’t exclude that it is related to the way how the CPU informs the chip through which port it should egress the frame - a proprietary tag is used for this purpose, which doesn’t exist on frames forwarded from one non-CPU port to another.