RouterOS bridge mysteries explained

RouterOS General
96

I have an alternative way to help to understand these bridge "mysteries" as well as the bridge's "personalities" and the default "VLAN 1" in RouterOS, that doesn't involve any diagrams or textual definitions, but relies on some "transformations" of the exported config file to a pseudo-config file (cannot be re-imported to the router):

Let's take an example of a configuration based on defconf, where no VLAN configuration has been done, the main bridge is named 'bridge'. We can do the folllowing steps:

  1. Export the config with /export file=config, download config.rsc to computer & open with any text editor.

  2. Remove static lease entries or address list entries if there are too many of them, to reduce the clutter, as they are irrelevant here.

  3. Add this somewhere near the top of the file:

    /interface vlan
add interface=routerPort name=vlan1 vlan-id=1

    Note that I've deliberately use interface=routerPort here instead of interface=bridge. As I wrote above, we are producing a pseudo configuration, not reusable by RouterOS. And the VLAN ID value of 1 is the value that is currently stored as pvid=1 in the definition of the bridge under /interface bridge (although we only see this in WinBox if vlan-filtering=yes on the bridge).

  4. Use the search and replace feature of the editor, and replace all occurrences of interface=bridge with interface=vlan1.

    After doing that, we can see that things like IP address, interface list, DHCP server, firewall, etc... are now associated with vlan1.

  5. Add a pseudo entry line to the section below /interface bridge port:

    add bridge=bridge frame-types=admit-all interface=bridgePort pvid=1

    Note: both frame-types=admit-all and pvid=1 are actually copied from the definition of the bridge interface itself (under /interface bridge), those are the default value if not yet changed or if the bridge currently have vlan-filtering=no.

  6. Add a pseudo configuration to the Bridge VLAN Table, by adding these lines somewhere below in the text file:

    /interface bridge vlan
add bridge=bridge untagged=bridgePort,ether2,ether3,...,etherN vlan-ids=1

    We added this because bridgePort has pvid=1 and frame-types=admit-all from above. Here beside the pseudo port interface bridgePort, we also collect all of the ports present under /interface bridge port that has bridge as parent and has pvid=1 (the default) and frame-types=admit-all (the default) or frame-types=admit-only-untagged-and-priority-tagged and put everything in untagged.

    (Also, this entry (minus the renaming of bridge into bridgePort) is what RouterOS would dynamically add if we turn on vlan-filtering=yes right now on the bridge.)

That's it! Now looking at the produced text file again (that is not a valid RouterOS config anymore), we can clearly see the multiple "personalities" of what being referred as bridge in the original config file:

  • We can see that the configurations under /ip address, /ip dhcp-server, /interface list member, /ipv6 address, /ipv6 nd, /ip upnp interfaces, etc... when they referred to bridge they actually used a vlan1 VLAN interface (same class as other VLAN interfaces), and the VLAN ID of 1 here matches value stored in the pvid field of the bridge definition.

  • We can see that the bridge "has" a hidden member port (bridgePort as named above under /interface bridge port), whose frame-types and pvid settings actually come from the values set on the definition of the bridge itself under /interface bridge.

  • We can see that when we usually add bridge to tagged or untagged of the entries under /interface bridge vlan, we actually add its bridgePort personality, and make the VLAN id available on that "port".

  • The remaining mentions in the text file of the entity named bridge now refer to the managed switch that connects the member ports (including bridgePort).

What not visible in the modified config file, is that there is an invisible hybrid "cable" link with the two ends plugged into bridgePort and routerPort, connecting them. The VLAN interfaces defined under /interface vlan (and attached to routerPort) can only read the frames coming out of the "managed switch" via bridgePort if the VLAN IDs are allowed for egress from that port. Likewise, when the VLAN interfaces produce frames to be sent to the "managed switch" (from routerPort -> bridgePort), only the frames with VLAN IDs acceptable by bridgePort will be allowed to enter the "switch", to be distributed to the other ports.

Here is another example. Assuming we have a configuration with a bridge named BR1, that has vlan-filtering=yes and the two other parameter of BR1 is set to pvid=888 and frame-types=admit-only-vlan-tagged. Let's try to do similar transformations:

  1. Export the config with /export file=config, download config.rsc to computer & open with any text editor.

  2. Remove clutters.

  3. If there are sections underneath /interface vlan, edit the lines, changing interface=BR1 to interface=routerPort-BR1.

  4. Add another line under /interface vlan (this use the 888 value from the pvid of the BR1 bridge definition):

    add interface=routerPort-BR1 name=vlan888-BR1 vlan-id=888

  5. Use the search and replace feature of the editor, and replace all occurrences of interface=BR1 with interface=vlan888-BR1.

  6. Add a pseudo entry line to the section below /interface bridge port, again, the parameters are taken from the BR1 original definition:

    add bridge=BR1 frame-types=admit-only-vlan-tagged interface=bridgePort-BR1 pvid=888

  7. We add no entry for this under /interface bridge vlan, because the port bridgePort-BR1 is declare as a trunk port (frame-types=admit-only-vlan-tagged). So no entry are added based on the PVID value (888).

  8. We do, however, replace all mentions of BR1 in the tagged and untagged field of the entries under /interface bridge vlan with bridgePort-BR1!

That's all. Looking at the resulting config file, we now see what remaining being referred to as BR1 is the "managed switch", that has a bridgePort-BR1 port as member, and the port is probably also listed in the tagged field of some /interface bridge vlan entries.

We also have the routerPort-BR1 port that probably has VLAN interfaces attached on it, including vlan888-BR1. routerPort-BR1 is connected to bridgePort-BR1 with the invisible cable. However, because VLAN ID 888 is not available on bridgePort-BR1 (as tagged or untagged), the interface vlan888-BR1 is effectively disconnected from the "managed switch" and cannot send or receive frames to/from the "switch".

Which means, if we now find another mention of interface=vlan888-BR1 anywhere else in the config file, that would point to a wrong or obsolete entry, and the original entry in the original config file referring to BR1 would also have been wrong/obsolete too.

Also, we see no mentions of "vlan1" in this text file, which means VLAN 1 is not present and not used on this router, unlike with the defconf config above. This point out to VLAN 1 being nothing special at all. It's only "special" in the defconf configuration due to pvid=1 and frame-types=admit-all on the bridge definition.