VLAN Editor

Opening the editor

The editor is the Edit mode switch on the Interfaces card of a device's page, available to operators and administrators. It is switched off until you ask for it, and the card behaves as a read-only faceplate the rest of the time.

Two things take it away. An SNMP-only device has no write path at all, so the switch is not offered on one. And on a device whose RouterOS account belongs to a group without the write policy the switch is there but greyed out, and a request sent anyway is blocked before anything is attempted — the device would reject the change, and the check happens before the manager spends a configuration export on it.

On a board with several bridges you pick which one you are editing. The editor opens on the bridge that already has VLAN filtering on; failing that, on one it could write to; and only then on the first one, so a device whose every bridge is read-only still opens on something real.

Site access applies here as everywhere else: a device in a site you cannot see is refused, whatever your role, and one that does not exist is simply not found.

VLANs and two port roles

The panel has two halves. At the top, the VLANs that should exist — an id and an optional name, added and removed as chips. Below, one row per port, each with a role:

Only the first two put a port into a VLAN, and they are the whole model: there is no third kind of port. The third option is still a change — it writes the port back to carrying no VLAN of its own — and it is offered only for ports that are in the bridge already. The fourth is the one that writes nothing, and a port that is in no bridge at all starts there; give it a role and saving moves it into the bridge along the way. Some ports get no choice at all, and the row says where they belong and what they carry instead: one that belongs to another bridge, one that feeds another bridge through VLAN interfaces of its own, and one RouterOS created for itself.

What the panel reads a port as comes from the port itself rather than from the bridge's VLAN table. Its untagged VLAN is the port's own PVID — but only where the port admits untagged frames at all: a port set to accept tagged frames only has no untagged VLAN, whatever PVID it is carrying. The VLAN table is not the source of truth for that half. RouterOS materialises an untagged row there only while the port has a link, so on a switch sitting on a bench with nothing plugged in the access ports are missing from it entirely.

One VLAN id can also sit in more than one row of that table, and a row's ids can be a list or a range; all of it is read. A row that covers several VLANs at once is left alone rather than rewritten, because editing it here would change the others with it.

There is no native-VLAN option, and that is a decision rather than an omission. A native VLAN needs explaining, and a panel that writes to a live switch has no room to explain it. A port that already carries one — tagged VLANs plus an untagged one somebody configured elsewhere — is recognised, and the row says so. It stays editable, but if your change would stop that untagged traffic, the preview says which port loses what. It is never inferred away quietly: that traffic is real and it was never visible in this editor.

A VLAN chip can also be marked mgmt. That gives the device its own interface in that VLAN, on the bridge, so it can be managed there. It creates the interface and nothing else — no address is moved. Creating an interface is reversible and harmless; moving the address the manager is currently talking through is neither, and belongs in a deliberate step of its own.

Three schemes, one editor

MikroTik hardware does VLANs in more than one way, and the same wish compiles differently depending on the board. The editor picks the scheme itself, and never asks you which kind of device you have — that was the point of having one editor.

The choice is made from two facts, in this order. First, what the device is configured with today: a board already switching on its chip has to keep doing so, because writing a bridge VLAN table alongside would leave two descriptions of the same ports, and they would fight each other. Failing that, what the chip can do: a QCA-8337 with empty switch tables looks unconfigured and the bridge path would apply cleanly, at the cost of an offload that chip cannot keep once a bridge filters.

Which dialect a switch speaks is read from the device — from the fields its own switch-port rows carry — rather than assumed from the chip's name. Two boards can report the same chip and offer different menus.

Where the board switches on a chip whose menus the manager does not recognise, it refuses to write rather than guess. A board with no switch VLAN menus at all is not a special case: it takes the bridge path, and nothing is claimed about its offload either way.

On the chip schemes the CPU port is handled for you: it is a member of every VLAN and its header is left alone, so tagged frames arrive at the router still tagged. Getting that wrong is how a management VLAN disappears.

Why the order matters

The preview shows the commands in the order they will run, and the order is the substance of the feature. On the bridge scheme:

1. Create the bridge with filtering off. If there is no bridge yet. Nothing about forwarding changes.
2. Add the ports to it. Still inert.
3. Write the VLAN table and each port's pvid and frame types. Also inert — a bridge that is not filtering forwards regardless of what its table says.
4. Turn VLAN filtering on. This is the step that starts enforcing anything, and it enforces the whole description at once.

Do it in any other order and there is a window where the ports are bridged but the VLAN table is empty, which drops traffic that used to pass.

The chip dialects are ordered on the same principle, in their own terms. On dialect A the tables and each port's header go first and vlan-mode=secure — the setting that makes a port enforce membership — goes last. Dialect B has no such setting: there the two role tables go first, and the switch VLAN row the ports are classified against goes last, which makes it the moment everything above it takes effect.

The safety net

Saving does not write anything. It produces a plan, and the plan is what you approve.

The preview

Before anything is sent you get three things: what the change does, in sentences; anything worth knowing about it, including ports that lose untagged traffic and what the configuration costs the hardware; and the literal commands, in order. Not a paraphrase — the same list of operations feeds the preview, the write and the rollback script. There is only ever one list, because a preview showing something other than what runs would be worse than no preview at all.

A backup first

A configuration export is taken and stored before the first command. If it fails, the change is cancelled and nothing is written.

A rollback the device performs on its own

Before the first change, the manager installs a rollback script and a scheduler on the device itself. Unless you confirm within three minutes, the device undoes the entire change without being asked.

It is armed before the write, not after, and that ordering is the whole point: the case this exists for is the command that cuts you off, and a device that dies on that command would never receive a scheduler installed afterwards.

Installing it is a precondition in the same way the backup is. If the rollback cannot be put on the device, the change is cancelled and nothing is written — the commands run only once the device is already holding its own undo.

Once the change lands, a banner counts down. Keep it cancels the timer on the device; Roll back now runs the undo immediately instead of waiting it out. The countdown is not a timer in your browser — it lives on the device, so closing the page does not stop it, and neither does the manager restarting.

Verification

After the write the manager reads the device back and plans the same wish again. If that produces no operations at all, the device holds what you asked for. Reading one field back could not cover a change this wide, and the planner is the only thing that already knows what "done" means for every port.

The whole change is recorded in the activity log with the commands that ran, the backup it took and whether the verification passed.

What it refuses to do

Some things come back as errors rather than warnings, and no amount of confirming gets past them. They are all the same category: changes whose result you could not undo, because you would no longer be able to reach the device.

• Cutting off the management VLAN. Where the device is reached through a VLAN interface on the bridge being edited, that VLAN cannot be deleted, cannot have its management flag removed, and cannot be left with no port to arrive on.
• Bridging the interface the manager talks to. Where the address sits on a port kept outside the bridge, that port can be given no role here: moving it in takes its address with it.
• Moving a port between bridges. A port that belongs to another bridge, or one that feeds another bridge through VLAN interfaces of its own, is described rather than offered — giving it a role here would take it, and everything it carries, out of where it is.
• Changing a dynamic bridge port. A port RouterOS created rather than one the bridge was given — typically a Wi-Fi configuration attaching an interface. RouterOS would refuse the change anyway; configure it where it is created.
• Writing to a chip whose menus are not recognised. Named plainly, rather than guessed at.
• Two descriptions of the same ports. A device configured on its switch chip is not given a bridge VLAN table as well.

Where management runs over a different bridge from the one you are editing, the panel says so and none of that bridge's ports can be given a role here.

Configurations it reads but will not write

A bridge whose ports are themselves VLAN interfaces carries its VLANs the way it was done before bridge VLAN filtering existed. That configuration is read and shown — you can see exactly what the device holds — but the editor does not write it, and the bridge is marked read-only in the picker.

The reason is the same as everywhere else on this page: this editor configures the bridge VLAN table, and a device described both ways at once is one nobody can read back afterwards. If the board has another bridge, you can pick it above and edit that one.

One more thing the panel points out while you are in it: if the bridge you are editing carries the hardware-offload flag on none of its ports, it says so, and names another bridge that does carry it where there is one. Most switch chips offload one bridge and run the rest in software — a cost that configuration is already paying, whether or not anything you do here changes it. A bridge whose ports do carry the flag is labelled as offloaded, and where the board reports no offload information at all the panel says nothing rather than inferring bad news from a missing flag.

The flag is the fact, and it is the only one taken: asking a port for hardware offload is a request, and there are boards where every port asks and none of them is given it.