Can't add same vlan to multiple interfaces?

RouterOS General
1

NOTE: This is not a request for help as much as it is commentary or maybe even a request to MT to simplify/normalize the config schema… thanks for reading though!

Trying to wrap my head around ROS L2 and am getting frustrated by the inability to enumerate VLANs per interface rather than enumerating interfaces per VLAN.

[admin@Mikrotik] /interface/bridge/vlan> add bridge=bridge1 vlan-ids=82,250 tagged=ether1
[admin@Mikrotik] /interface/bridge/vlan> add bridge=bridge1 vlan-ids=83,250 tagged=ether2
failure: vlan already added

There are no VLANs on ether2, so how can it already have been added?

I am aware that I can enumerate the interfaces instead, but in a complex environment, that can be VERY tedious to work through… I need and want to be able to see, at a glance, which VLANs are on a particular interface. This is preferred over seeing which interfaces belong to a particular VLAN.

There are use cases for both. Sometimes you need to create a VLAN and need to add multiple interfaces. Other times, you need to turn up an interface and add multiple VLANs. There’s no one right answer, but ROS shouldn’t have an opinion one way or the other.

In the ISP sector, at least in my experience, it’s much more common to turn up an interface than to create a new VLAN. In fact, that’s probably the case in enterprise as well.

If I have a dozen VLANS and need to add a new trunk port, then I have to touch every entry, which means that I have a dozen chances to make a service affecting mistake. On the other hand, if we can enumerate VLANs by interface, then I can only screw up that ONE interface and no other interface is at risk.

3

You were trying to add 250 VLAN several times.

I am aware that I can enumerate the interfaces instead

Yes, from what I know it should work. i.e tagged=ether1,ether2

if I have a dozen VLANS and need to add a new trunk port

You can use scripts to make bulk changes.

4

The nicest approach to handling this that I have found is to use interface lists, e.g. TRUNK_PORTS, and add this as the tagged VLAN member for the appropriate VLANs. This way assigning a new port for trunk usage is easily done just by adding it to the TRUNK_PORTS interface list.

1 Like
5

And, now that you have posted the theory, can you post a practical example (commands) solving the OP problem?

What OP has:

  1. bridge with ether1 and ether2

What he wants:

  1. ether1 tagged on the bridge for both VLANs 82 and 250
  2. ether2 tagged on the bridge for both VLANs 83 and 250

How (EXACTLY) this can be implemented making use of interface lists?

6

[admin@Mikrotik] /interface/bridge/vlan> add bridge=bridge1 vlan-ids=82,250 tagged=ether1
[admin@Mikrotik] /interface/bridge/vlan> add bridge=bridge1 vlan-ids=83,250 tagged=ether2

Instead do:
add bridge=bridge1 vlan-ids=250 tagged=ether1,ether2
add bridge=bridge1 vlan-ids=82 tagged=ether1
add bridge=bridge1 vlan-ids=83 tagged=ether2

Backwards, but it works

7

Here is an example adapted from my RB5009 configuration. You can easily take it from there.

My home network consists of interfaces ether2, ether3, ether4 and ether 5. The VLAN id for the home network is 100. Hosts in the home network are unaware of VLAN handling by the router. All traffic on the home network is untagged.

  1. Create the interface list:
/interface list
add name=HOME

/interface list member
add interface=ether2 list=HOME
add interface=ether3 list=HOME
add interface=ether4 list=HOME
add interface=ether5 list=HOME
  1. Configure the bridge to know about VLAN 100 and how to send traffic to various interfaces. Please note that the bridge itself is also an interface for this purpose. This is needed for the VLAN interface that is created in step 4.
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=HOME vlan-ids=100
  1. Configure the home network interfaces to associate untagged ingress traffic with VLAN 100.
/interface bridge port
add bridge=bridge1 interface=HOME pvid=100
  1. Create the VLAN interface
/interface vlan
add interface=bridge1 name=VLAN100 vlan-id=100
  1. Configure the VLAN interface IP address
/ip address
add address=192.168.178.254/24 interface=VLAN100

The possibility to use interface lists in many places is one of the greatest features of RouterOS 7. Interface lists not only make a configuration better readable, but also help to keep the configuration consistent. Here is an example that illustrates this.

I also have a DMZ network. Suppose I want to move ether5 from the HOME network to the DMZ network. I then simply remove ether5 from the HOME interface list and add it to the DMZ interface list. That’s all. RouterOS ensures that the changes propagate to the bridge port and vlan configurations. Less work, fewer mistakes.

1 Like
8

But this still doesn’t answer @jaclaz’s question which was:

Using interface list doesn’t make it more compact in this particular case, and in case of future expansion similar to what the OP wanted (add a few more VLAN to a particular port, let’s say ether2) would involve even more additional steps than without interface list.

9

To me this is not backwards at all. IMHO the vlan-ids= clause in the add command was a mistake by MikroTik. It makes it very easy to err when configuring VLANs and I have seen people pull their hair out trying to understand what they were doing wrong more than once. I’d really welcome it if MikroTik deprecates vlan-ids= in favor of a new vlan-id= clause in a future RouterOS release.

10

I fully agree. It’s also more logical for me to think of the VLAN table as a table with the VLAN ID column as primary keys. And the tagged/untagged ports are BIT/BOOL data columns. There can be > 4000 VLAN ID while the number of ports is orders of magnitude smaller. Just like a database table where the number of possible rows is normally much larger than the number of columns, and the rows are identified by the primary key columns. The rows of the /interface bridge vlan table are identified by the VLAN IDs, thus their keys cannot overlap if the rows are added manually (we ignore the dynamic rows added automatically by RouterOS).

And naming the column vlan-ids is ok, but I normally specify multiple VLAN IDs per row only in the format from-to if needed, and only one single range. I never group them in any listing that requires the comma ,!

11

In RouterOS you add ports to a VLAN (using the tagged= and untagged= clauses), not VLANs to a port. The /interface bridge vlan add command adds VLANs to a bridge, not to bridge ports.

12

I am aware of this :). But we should retrack back to the beginning of the thread/topic:

  • OP, @troy, complained that because overlapping VLAN IDs between the entries in /interface/bridge/vlan is not allowed, which interfere with his usual workflow where he likes to see all VLANs belonging to a particular port listed in ONE place, as well as the workflow where multiple VLANs should be enabled on a particular port. Currently in RouterOS, this requires going to multiple separate entries in /interface/bridge/vlan and adding that port to the tagged section of each of the entries.

  • @lurker888 wrote that the nicest handling to that is to use interface list.

  • @jaclaz asked how would interface list improve anything in OP’s usecase. You can see that ether2 and ether3 share VLAN 250 but each have an additional separate VLAN. If you use interface list in this case, it doesn’t improves anything, and does not make anything more compact.

  • You provided an unrelated configuration example, where all interfaces have the same set of tagged VLANs. Of course, this usecase would suit the interface lists. But now let’s add VLAN99 to ether4 in your config. This change, if done with interface list, involves more steps than just adding an new line with vlan-ids=99 and tagged=ether4 (because you would need to define an additional interface list and assign ether4 as member). Which means interface list is not the solution to OP’s problem!

13

Point taken! More than one, actually…

In that case ether4 would not be member of the HOME interface list. My router actuall has a list name TRUNK that contains the interfaces that carry tagged VLANs to my wifi access points.

Agreed. The OP’s problem is conceptual.

14

Only if you want to make it so, otherwise it seems to me very practical, reworded:
I need two interfaces, ether1 and ether2, part of a bridge, to be tagged respectively as vlan 82 and 83 to be both ALSO tagged as 250.
How to do this?

The proposed solution by savage is not particularly “backwards”, actually I like it, it can be thought as a “top to bottom” or “from wide to narrow” approach:

  1. assign first the VLAN(s) to be tagged to more than one interface to all involved interfaces with a single command
  2. add later to each interface its own "unique VLAN
    but it can also be reverted, unless I am mistaken:

first assign all unique VLAN(s), then assign VLAN(s) that cover multiple ports. :face_with_diagonal_mouth:

Said in yet another way, OP (not working) commands were “interface centric”, while savage’s solution is “VLAN centric”, and it is actually in the order the parameter comes, vlan-ids (notwithstanding the plural) should have only one VLAN, while the tagged contains one or more interfaces.

It is probably not very clear when you re-read the configuration, particularly if a complex one, but if entries are kept in order, it is not that bad.

15

I agree with @CGGXANNX’s points, I’m just not in total agreement with the (implied) conclusions.

I also agree with @jaclaz regarding his conclusion (or statement-thinly-disguised-as-a-question) that interface lists add nothing to OP’s problem as stated. I think everyone can transpose OP’s problem to be vlan-centric and thus give a correct configuration.

I think the problem relates more generally to the common problem of having a switch with - lets say - 10+ ports and 5+ vlans, where we want to so some routine stuff, like

  • add vlan 10 to ether2 as trunked
  • remove all trunks from ether3
  • move the connection (with all its associated vlans) from ether4 to ether5

Just as an aside: we only have to concern ourselves with trunk (or in the hybrid case, the tagged) ports, because untagged assignments are automatically done based on PVID (and frame-type). Also, tagged assignments are done for vlan interfaces added to the bridge. Both of these are nice features.

I used to use the vlan table routinely having more then one item (line) having to same (or partially overlapping) vlan-ids fiels. I was happy: you could group things however you like. I quite often found it useful to have all or most vlan entries with a single vlan-id and a single tagged port.

This came to an end however:

What’s new in 7.17 (2025-Jan-16 10:19):
*) bridge - disallow duplicate static VLAN entries;

For me this is an unwelcome change:

  • The semantics for the old behavior are clear: the vlan entries don’t show definitively which ports are assigned in which roles, but their union is what is in effect. But this shouldn’t really confuse anyone, because for dynamic entries this is that way it still works
  • The functionality is there internally - again, for dynamic entries
  • That dynamic entries are added according to the old semantic clearly shows that modifying existing items on a per-port basis is absolutely unintuitive
  • No built-in methods are established for e.g. “add this port to the list of tagged entries”, “remove this port from the list of tagged entries” and so on. Scripting around this is cumbersome and left to the user. The built-in functionality ends at copy-paste-edit manually.

I was only stating that interface lists allow you to (at least somewhat) return to the old semantics by assigning interface lists as tagged entries, and then adding interface list entries, which can be filtered-added-deleted individually.

Sorry for the usual wall of text.

1 Like
16

@lurker888
No, no, it was only a simple question, though my spider sense did detect something strange, I was actually curious to understand how interface lists could be used as conceptually they would look more “tidy” (and understandable when you re-read a configuration after months).
But - and this is certainly a limit - I only learn (sometimes, something) from examples, creating my own “mental maps” from them (as opposed to attempting to translate theory - often using terminology that simply doesn’t belong to me - to actual commands).

17

@jaclaz: sorry then, it was me reading too much into things.

I still think that the decision made for 7.17 would be better reversed. What is your view on this?

18

I don’t know, my understanding of VLAN’s is still extremely limited, both conceptually and in practical Mikrotik implementation.
A lot of pieces of the puzzle have not (yet) clicked into place.

From the outside, the whole stuff seems to me very complex and the Mikrotik implementation appears to confuse things further (both the “old” way and this new “7.17+” way).

Very likely the only possible way out is to build a “helper” of some kind (excel spreadsheet or script) capable of parsing a VLAN configuration, extract the settings from it and re-group/re-order them in an understandable way.

19

Thanks to all for the discussion… in case it wasn’t clear, this was an observation/rant rather than a request for help. IMO, it’s just an abstraction that’s neither right nor wrong, it’s simply one way to accomplish the task.

I cut my teeth on Cisco, where the VLANs are defined per-interface:

switchport trunk allowed vlans 83-89,250,500

Others cut their teeth on HP, where the interfaces are defined per-VLAN, which is a very backwards way to do things from the perspective of anyone who started out on Cisco.

My position is that it’s much more common to turn up a new interface than a new VLAN, so being able to define the VLANs on a per-interface basis makes much more sense for an ISP, which is Mikrotik’s target customer base. I’d hazard a guess that turning up new interfaces is also more common in the enterprise and even home networks.

Or, consider the case where you want a trunk port (allowed vlans 2-4094) so you don’t have to worry about it anymore:

[admin@mikrotik] /interface/bridge/vlan> add bridge=bridge1 vlan-ids=2-4094 \
    tagged=sfp-sfpplus1
failure: vlan already added

So maybe consider this a feature request… wouldn’t it be great to be able to add a bridge port and define it’s VLANs all at once?

/interface/bridge/port add bridge=bridge1 interface=ether1 pvid=1 tagged=83-89,250,500

Or better yet, do it from the interface dialogue:

/interface/ethernet/set ether1 bridge=bridge1 pvid=1 tagged=83-89,250,500

Neither of those necessarily needs to alter the current behavior, it would simply be an easier way to deal with it.

There’s so much MT could do to normalize the config schema. This is just one area.

20

Hmmm, now it looks more like Mikrotik is breaking your workflow
https://xkcd.com/1172/
:rofl:

21

Nah… doesn’t break a workflow, just makes the workflow more difficult than it needs to be.