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 disable it outright. An SNMP-only device has no write path at all. And a device whose RouterOS account belongs to a group without the write policy is blocked before anything is attempted — the device would reject the change anyway, 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.

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:

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 box 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.

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 follow the same shape in their own terms: the tables first, and vlan-mode=secure — the setting that makes a port enforce membership — last.

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, the rollback script and the tests. 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.

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.
• 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 while another bridge does, it says so. 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. Where the board reports no offload information at all, the panel says nothing rather than inferring bad news from a missing flag.