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:
- Export the config with
/export file=config, download config.rsc to computer & open with any text editor.
- Remove static lease entries or address list entries if there are too many of them, to reduce the clutter, as they are irrelevant here.
- 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.