Mikrotik switches and routerboards are incredible value and, equipped with the very powerful RouterOS, remarkably capable however I’ve never found RouterOS the most intuitive to configure. I’ve personally found doing the simple things, such as setting up VLANs with trunk and access ports, really confusing.

With that in mind, here’s a quick run down on how to do just that in the CLI.

Some useful commands:

• add – adds a config item
• remove – removes a config item by index number – e.g. remove 3
• set – sets a variable on an existing config item – e.g. set 3 pvid=99
• export – lists the config at the current context
• print – lists properties of the current context including the index of each config item

I have always found RouterOS config to be confusing but it’s actually very readable once you understand the principle of operation. It’s broken down into contexts in a logical structure. Here we’re configuring a layer 2 switch so doing almost everything within the bridge context /interface bridge. This is where layer2 config lives. The contexts are navigated a bit like a file structure with / being the root. Make use of the print and export commands to understand what config exists.

A default configuration will probably have been applied that defines a bridge with all ports added and a default IP address assigned to the bridge for initial remote config. To change a variable of an existing config line use the set command. You need to know the index number, starting at 0. To get this use the print command when in the appropriate context. For example below is the print output from the /interface bridge port context. Based on this, to change the PVID to 99 on port SFP1 use the command: set 3 pvid=99

The Config
This is a simple config with three VLANs: 2 (Management), 3 (IOT), and 10 (WLAN). The management VLAN is untagged on some ports, there is an SVI/VLAN interface with an IP address used for switch management. The other VLANs are tagged. Not all ports are in use and though they are added to the bridge and enabled, there is no VLAN config applied.

The following actions need to be performed:

• Create a bridge – the first bridge will refer to the switch chip (if available) do not create additional bridges as these will be in software, switching traffic through the CPU
• Assign ports to the bridge
• Create VLANs in the bridge & assign to ports as tagged or untagged as required
• Create a VLAN interface for management
• Assign an IP address to the management VLAN interface
• Ensure VLAN filtering is enabled on the bridge
• Set the PVID/native VLAN on ports as required

Create/edit a bridge (note this was done by autoconf and edited with set 0 vlan-filtering=yes)
/interface bridge
add name=bridge protocol-mode=none vlan-filtering=yes

Assign ports – all ports are assigned to the bridge by defconf. You can either edit the existing entry or remove and add with the desired config. Here you can see sfp-sfpplus1 and 4 have been assigned a PVID of 2 – the default PVID=1 does not show in the config.
/interface bridge port
add bridge=bridge comment=2530-downlink interface=ether1
add bridge=bridge comment=defconf interface=sfp-sfpplus2
add bridge=bridge comment=defconf interface=sfp-sfpplus3
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=sfp2
add bridge=bridge comment=defconf interface=sfp3
add bridge=bridge comment=defconf interface=sfp4
add bridge=bridge comment=defconf interface=sfp5
add bridge=bridge comment=router-uplink interface=sfp-sfpplus4 pvid=2
add bridge=bridge comment=truenas interface=sfp-sfpplus1 pvid=2

Create VLANs on the bridge (L2) and assign to ports as tagged/untagged. VLAN is tagged/untagged using a comma separated list of interfaces. Note the management VLAN is tagged to the bridge itself as well as any ports – this makes the VLAN available to the CPU
/interface bridge vlan
add bridge=bridge comment=management tagged=sfp-sfpplus3,ether1,bridge untagged=sfp-sfpplus1,sfp-sfpplus4 vlan-ids=2
add bridge=bridge comment=WLAN tagged=ether1,sfp-sfpplus3,sfp-sfpplus4 vlan-ids=10
add bridge=bridge comment=IOT tagged=ether1,sfp-sfpplus3,sfp-sfpplus4 vlan-ids=3

Create the VLAN interface/SVI – this is the layer3 interface for a VLAN. You need to define this in order to apply an IP address.
/interface vlan
add interface=bridge name=management vlan-id=2

Apply an IP address to the management VLAN interface. If you have a defconf IP address configured on the bridge you will need to remove this.
/ip address
add address=172.20.0.4/24 interface=management network=172.20.0.0

Lastly here’s a bit of general system config setting the hostname, DNS and NTP sync
/ip dns
set servers=172.20.0.1
/ip route
add dst-address=0.0.0.0/0 gateway=172.20.0.1
/system identity
set name=CRS310
/system ntp client
set enabled=yes
/system ntp client servers
add address=0.uk.pool.ntp.org

The one place I got stuck for longer than I’d like to admit was having to set a PVID in a different place to VLAN tagging. With this config structure I initially assumed setting a bridge VLAN as untagged on a bridge port would define that as the PVID for the port – it does not.

The complete config:
/interface bridge
add admin-mac=F4:1E:57:7C:3E:F0 auto-mac=no name=bridge protocol-mode=none \
vlan-filtering=yes
/interface vlan
add interface=bridge name=management vlan-id=2
/port
set 0 name=serial0
/interface bridge port
add bridge=bridge comment=2530-downlink interface=ether1
add bridge=bridge comment=defconf interface=sfp-sfpplus2
add bridge=bridge comment=defconf interface=sfp-sfpplus3
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge comment=defconf interface=sfp2
add bridge=bridge comment=defconf interface=sfp3
add bridge=bridge comment=defconf interface=sfp4
add bridge=bridge comment=defconf interface=sfp5
add bridge=bridge comment=router-uplink interface=sfp-sfpplus4 pvid=2
add bridge=bridge comment=truenas interface=sfp-sfpplus1 pvid=2
/interface bridge vlan
add bridge=bridge comment=management tagged=sfp-sfpplus3,ether1,bridge untagged=\
sfp-sfpplus1,sfp-sfpplus4 vlan-ids=2
add bridge=bridge comment=WLAN tagged=ether1,sfp-sfpplus3,sfp-sfpplus4 \
vlan-ids=10
add bridge=bridge comment=IOT tagged=ether1,sfp-sfpplus3,sfp-sfpplus4 \
vlan-ids=3
/ip address
add address=172.20.0.4/24 interface=management network=172.20.0.0
/ip dns
set servers=172.20.0.1
/ip route
add dst-address=0.0.0.0/0 gateway=172.20.0.1
/system clock
set time-zone-name=Europe/London
/system identity
set name=CRS310
/system ntp client
set enabled=yes
/system ntp client servers
add address=0.uk.pool.ntp.org

Put simply not all switches equal. This should be obvious, there’s a reason all vendors have a wide range of options at different prices, but… what happens if you get the wrong kit?

The most obvious metric is the device throughput – how much traffic can be switched or routed by the hardware – you simply want to avoid bottlenecks where possible and that’s straight forward enough. If you have a 10Gb internet connection and plug it into a 1Gb switch port, you now have a 1Gb internet connection. I have seen that done and the ticket raised “why are we not getting the speed we’re paying for”.

What I’m more interested in is table sizes.

Switches have MAC tables and routers have ARP tables (IPv4) and Neighbour tables (IPv6) and, yes, these are often the same physical devices.

The MAC table records the MAC addresses seen on each port and is key to switching traffic efficiently, sending frames only to the appropriate port. The ARP and Neighbour tables match an IP address to a MAC address so incoming packets can be forwarded. If these tables are filled the router may drop traffic for any addresses it doesn’t know.

Put simply the network equipment needs to have sufficiently large table sizes to accommodate the number of network clients. When this is not the case, things stop working and often in unpredictable ways; some clients will work just fine, others won’t work at all. Maybe someone was happily on line at 10am but at 10:11am when they try again, nothing is working.

This is a common problem with cheap gear. The ISP router might let you setup a really large subnet but it may only be able to handle 50 clients at once due to memory limitations. It’s weird to refer to network gear as “prosumer” but there’s plenty of more affordable kit out there that will take the config you want without delivering what you need.

With serious enterprise gear the table sizes are often really big but the devil is in the detail. A switch might have full layer3 support but be weighted towards layer2 tables with a HUGE MAC table supporting hundreds of thousands of MAC addresses but perhaps a much smaller layer3 table of only 16,000 or so. Because you usually want one or the other the switch may allow you to configure which table is larger.

Here’s a little tale from personal experience. Consider a university campus wireless network which could see over 20,000 clients. As part of a general upgrade the routing was moved from an aging Procurve 5400 switch to a Comware 5900. Everything was great until, a couple of weeks later, term started and the client numbers climbed past 16,000 at which point the calls started coming in about the Wi-Fi not working.

That number was very suspicious and very quickly the recent changes were looked at. We found the new 5900 switch had a ARP table limit of 16,384 vs the MAC table limit of 131,072. This was a switch optimsed for layer2 switching in the data centre, lots of VMs and therefore lots of MAC addresses. But the small ARP table made it unsuitable for our use case. We didn’t know this until it became painfully obvious.

Finally a word of warning on IPv6. Table sizes need to be much larger for the same number of clients. With IPv4 each client will have one address. With IPv6 clients will have multiple addresses. IPv6 addresses also take up more space so the same physical memory will handle far fewer IPv6 table entries vs IPv4.

Understanding the capacity of your equipment is just as important as the functionality.