Cisco VLANs to MikroTik
Why VLANs?
When I first started trying to setup my first MikroTik device, I very quickly ran into issues trying to configure VLANs. Using VLANs is so second-nature to me now coming from a Cisco background. In almost any network you should be using VLANs to segment devices off into logical groupings instead of having large, flat networks. Large, flat networks are simple, and make adding new hosts quicker since you don’t have to spend any time figuring out where to place it. However, with this type of network you will have an extremely difficult time trying to keep hosts from talking to each other, so security becomes a nightmare. Also, if your subnets are large enough you can end up with very large amounts of broadcasts on your network, which eats up bandwidth and resources. This isn’t as noticeable in a traditional campus network when you have wired connections, and fiber links between everything. These kind of issues though, are extremely prevalent in wireless networks, where bandwidth is a very precious commodity. So, if for no other reason than I told you so, use VLANs! You’ll thank me later.
Switches, bridges, and VLANs, OH MY!
Now on to VLANs with MikroTik. I’ve seen a lot of videos and posts on how to setup VLANs on MikroTik, but it never quite clicked until I was able to compare settings to what the equivalent settings are on Cisco. Once I did this, it started to fall into place.
Now, I will say, there are some gotchas with MikroTik VLANs in that, you can’t always configure them the same way on every device. Most of the CRS line of devices have higher quality switch chips in them that allow you to hardware offload switching and VLAN tagging. This allows all VLAN traffic to bypass having to be processed by the CPU, which will cause you huge performance issues when pushing traffic at any kind of scale.
This is how I’ve setup VLANs on the RB4011, and HAP line of devices and it seems to work just fine. Some of these have switch chips, but don’t actually support VLANs, so it’s a bit misleading. There’s a chart here that will give you the details of which switch chips support hardware offload (support VLANs), and which don’t. If they don’t, anything you do with bridges and VLANs will have to be processed by the CPU, and could lower the total throughput on the device.
VLAN Method 1 – Sub-interface
The first way you can setup VLANs is to create sub-interfaces on your physical interfaces. This is the same as in the Cisco world, and used for ROaS (Router on a stick) deployments. Usually these perform okay since the router is routing all traffic between VLANs just like it would if you were using multiple interfaces for each subnet. The limitation here is the physical interface capacity since any traffic sourced from VLAN A, and destined for VLAN B, will need to “trombone” into the router CPU, and back out the same interface. If you don’t have this type of traffic pattern, this is usually the simplest VLAN method.
You will open your interface list and select the + drop down, then select VLAN, enter the name for the sub-interface, the VLAN ID, and parent interface, and you’re done. You can then put your IP address on this new sub-interface just like you would on a Cisco device.
This method is the equivalent to this config in Cisco:
interface GigabitEthernet0/8.77
description sub-interface
ip address x.x.x.x x.x.x.x
no shutdownVLAN Method 2 – Switch chip (In the switch menu, in the wonderbar)
Used mostly in the CRS3XXX series MikroTik devices, I don’t have a good way to get screenshots of this as I don’t have a device like this currently accessible. Though I feel this method pretty straightforward. You can set the VLANs on each port just like you would assume. Select the interface, set the vlan, enable VLAN filtering. You’ll do this in the “`/interface bridge“` config section. Setting the PVID (Port VLAN ID), is like setting the interface to an access port in that VLAN. All incoming, untagged traffic will be tagged for the configured VLAN, as the traffic leaves the physical port, bound for the bridge (into the router). You will want to untag access ports (usually this is done dynamically with the PVID), and tag trunk ports. This is because traffic coming back to a physical interface, and heading out to the device, will need to VLAN tag stripped or the device won’t know what to do with the packet, and discard it. Trunk ports are tagged, as they expect tagged traffic coming in and will forward it on to the other ports in the device in that VLAN. This is pretty similar to how Cisco does port configuration for VLANs. All this is taken care of in the back-end in Cisco so you just don’t see all the bits.
VLAN Method 3 – VLANs in a Bridge
Sometimes you need/want to use something like an RB4011 as a home router, but you also want to utilize multiple interfaces to connect devices, and for them to be in a single VLAN. Ask me how I know 😉 For this you’ll need to use software bridges, without hardware offload. This is where I started getting really confused for the longest time. I’ll try and clear things up. Basically, software bridging is like using a virtual cable in the CPU of the router to connect multiple physical interfaces. Once you do this, it opens up a lot of possibilities, but be careful. This is where you start shooting yourself in the foot and killing performance.
Here’s the basic conversion chart:
- PVID on Physical Interface == Access port in that VLAN (adds tag on ingress to untagged traffic received on an interface)
- Bridge tagged == Add to tagged ports to allow that VLAN through (“trunk allowed vlans”)
- Bridge untagged == Adds tag to ingress traffic on these ports (“native vlan”)
- Bridge Port == SVI with PVID being the VLAN it’s in.
Here’s an example setup I have. You start with adding a new bridge, then add your ports to the bridge, with the PVID set to the vlan you want them in. Once this is done, create your VLANs tab, and select your tagged and untagged interfaces. Once all that is set, go back into the bridge config and turn on VLAN filtering. If you did something wrong you’ll lose access to the router so always do this last, and I usually leave at least 1 port out of the bridge just in case, so I can go back and use mac telnet to get back in and turn off VLAN Filtering until I can figure out what I have wrong.
This would be a similar config in Cisco:
Interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 2,200,500,1000 Interface GigabitEthernet0/3 switchport mode access switchport access vlan 200 Interface GigabitEthernet0/9 switchport mode access switchport access vlan 200 Interface GigabitEthernet0/10 switchport mode access switchport access vlan 200
Wrap Up
Hopefully this helps clear up some of your confusion like it did mine. Maybe these aren’t all the 100% best way to do things, but they seem to work well for me at this point. Most of the time, it’s using the right tool for the job. If you plan on using more switching, get a switch, like the CRS3XX series. If you are doing mostly routing, get a router, like an RB2011,3011, or 4011, etc… This will help you not have to sacrifice performance just to get what you need to get done.
Also, see https://www.sisulink.com/post/management-vlan-mikrotik for information on how to configure management vlans.
Quick Note
Do not try and combine method 2 and 3, ask me how I know! Things like kind of work once in a while, but for the most part they will not, and you will be pulling your hair out!