Hi.
I have many vlan in my network, and before V7.17 i was able to assign range of VLans on specyfic interface, which was very clean and convenient, especially when I had to add a new port with many tagged vlans After upgrade to v7.17 when I want to do the same I get an error

Couldn't add New Bridge VLAN- vlan already added (6)

Do you have any way to do it better in version > 7.17 than adding (well over 100) x vlans and then going through each vlan separately and adding a new tagged port on each one?

You have been thinking of your Bridge VLAN table as a table with interfaces as "Primary Key". Try to rethink that and use the VLAN IDs as Keys and "pivot" the table:


There should be no rows with duplicated vlan ids, just like a DB table cannot have duplicated primary key values.

If the VLAN table is a DB table, then the interfaces are BOOL columns (one flag for each interface). Each row belongs to one VLAN ID, that's why the VLAN ID is the primary key columns. There are normally fewer possible columns (a few dozen interfaces max) than rows (over 4000 possible VLAN IDs) so it's more logical to organize it that way. The fact that you can also specify vlan-ids=id-range is syntactic sugar to help reduce the number of repeated "rows".

This is not a solution because the vlan groups are different depending on the port, switch, and situation. Which means that I would have to have them saved individually. Or there would be dozens of them.
And now imagine that you suddenly have to connect most of the tagged vlans to some port of a new switch, where you have hundreds of individual vlans or dozens of vlan groups.
It becomes a huge mess. Yes, if you have few vlans it is convenient, but if there are many of them, even for debugging purposes it is much easier to see what vlans are on a given port than to browse all the vlans to see if a given port is on the list.

I am not saying that my situation is more frequent or more important. Before version 7.17 you could do it both ways and it was great. If someone had few vlans, they would add ports to the vlan, if they had many, they could add vlans to ports. And since there is no such option, maybe you have some elegant way to deal with the problem of adding a port to hundreds of vlans.

I will add one more thing that was invaluable for me. If I had many switches connected to each other and on each such port I gave a range of 1-2000 vlans, even though in reality I was using several hundred, then when a new vlan arrived (of course in the range of 1-2000) I did not have to do anything on those switches, it simply worked. And now I have to either create 2000 entries for each vlan by default (it looks very sloppy), or when a new vlan arrives I have to suddenly configure it on all the switches along the way.

What I described is how you configure the VLAN table in most switch-GUIs, including MikroTik SwOS, you have the VLAN as Row ID and you turn on the checkboxes/flags which are the ports for the indvidual rows:



Same with Aruba:



Or Draytek:



Or TP-Link (look at the table at the bottom of the screenshot)



That is because the normal workflow is that you have a new network to add, let's say "Library", you create a new VLAN with a new VLAN ID, let's say 25, you add that VLAN ID as a new row to the VLAN table, then decide which ports the VLAN will be made available to, tagged or untagged (you check the checkboxes, in the WinBox/RouterOS you fill the tagged and untagged attribute).

Later you decide that "Library" should no longer be available on port ether10, then you just need to uncheck that checkbox on the VLAN ID 25, or in WinBox remove ether10 from tagged attribute of that row.

You organize and manage your networks (the VLANs) and work on them as entity, not some individual port of some device.

I will add one more thing that was invaluable for me. If I had many switches connected to each other and on each such port I gave a range of 1-2000 vlans, even though in reality I was using several hundred, then when a new vlan arrived (of course in the range of 1-2000) I did not have to do anything on those switches, it simply worked. And now I have to either create 2000 entries for each vlan by default (it looks very sloppy), or when a new vlan arrives I have to suddenly configure it on all the switches along the way

You said that yourself, there can be thousands of VLANs. When you manage data as table you don't want your table to have thousands of columns. It's the number of rows that should grow or shrink and in order of magnitudes larger than the number of columns. When a new VLAN appears, you add a new row and fill the attributes of that row (tagged/untagged). Just like when you add a new department or customer to a database, you add a new row, fill attributes (name, location, etc...) and never add a new column.

I believe in the latest software MT provides the ability to create interface lists of vlans so they are automatically handled in the config.....
*bridge - added interface-list support for VLANs;
Starting from RouterOS version 7.17, you can use interface lists for the tagged and untagged properties in the bridge VLAN table. This change allows for more flexible VLAN assignment to ports by simply modifying the interface list members, rather than updating each bridge VLAN entry individually.

If different interface lists are specified for the tagged and untagged settings, and there is overlap between the interface members, the untagged list will take priority. You can check the current interface configuration with current-tagged and current-untagged properties using the print command.

And the Bridge -> Ports table also allows interface list, instead of adding the individual etherX port to the bridge, it's also possible to use interface list. Which means the same interface list can be used to add 6 ports to the bridge all with the same PVID 150 and "admit-only-untagged-and-priority-tagged", and that same interface list can be used to populate the untagged list for the Bridge -> Vlan entry for VLAN ID 150 (however, if we don't do this manually RouterOS will add a dynamic entry for VLAN ID 150 with those ports in the untagged list anyway).

CGGXANNX

why are you trying to convince me that this is a better solution? I wrote that it is a good solution for small numbers of vlans and small networks, but it does not work in more advanced cases. The examples you provided only confirm this because this is basic equipment with limited functions (definition of MikroTik switchOS). Show me someone who will click even 200 vlans in siwtchOS web interface...

If you really want examples where it works (both ways!), you have for example HP1920 (and equivalents), or switches from the full manage family and not smart manage, e.g. Dell

The question in this thread was whether anyone has good ways to deal with this in more advanced cases when there are a lot of these vlans, e.g. 500. And large network like 200+ switches, where adding a new vlan even on 1/3 is not that easy. So please do not clutter the thread with arguments that it is better to add ports to vlans just because, because it does not contribute anything.

I believe in the latest software MT provides the ability to create interface lists of vlans so they are automatically handled in the config.....
*bridge - added interface-list support for VLANs;
Starting from RouterOS version 7.17, you can use interface lists for the tagged and untagged properties in the bridge VLAN table. This change allows for more flexible VLAN assignment to ports by simply modifying the interface list members, rather than updating each bridge VLAN entry individually.

Using the interface list will actually help, but only in a situation where I want to add another port with all the vlans. It won't work if I want to assign an individual smaller vlan range to a port. So this is only a partial solution. And then at the start I first have to create, for example, 2000 vlans (even if I do not use some yet) and assign this interface list to them, which I really do not like because it looks unreadable and inelegant.
Additionally, checking what vlans are on a given port is a failure in this case.

I'm not saying that everyone, but I definitely need information more often on which vlans are on a given port than on which ports a given vlan is.

By the way, I wonder why Mikrotik blocked the option of entering a vlan range (which were repeated) into ports since both methods worked previously.

dev426, you have options, get a diff brand router.

You have been thinking of your Bridge VLAN table as a table with interfaces as "Primary Key". Try to rethink that and use the VLAN IDs as Keys and "pivot" the table:
[...]
The fact that you can also specify vlan-ids=id-range is syntactic sugar to help reduce the number of repeated "rows".

That syntactic sugar is actually want makes automating this so tough! It's actually an array in scripting (thus config) – & even Excel PivotTable have trouble where a "cell" is a list.

@pcunite highlighted the underlying problem here, 2021:
viewtopic.php?t=172732

Which is gap in scripting, since there is not primitive operation to add a value to a list/array attribute like vlan-ids. So these "vlan-ids" LIST make this a very hard problem in config to solve without some "find/insert into attribute" operation.

While I have some scripts here that operate on the "pivoted" view of the bridge, and maybe they help in your case IDK:
viewtopic.php?t=214189#p1123276

And have an initial "TUI" for dealing with bridge (now with 1000+ VLANs, it does not page them, yet), but it VERY difficult to visual what's happening inside /interface/bridge/vlan. So I wrote this to show it like Excel PivotTable: (what that's missing is commands to operate on the "rows" or "columns" of each, it just shows them today)