Cisco to MikroTik – Switching and VLANs



About the Cisco to MikroTik series

One of the most difficult configuration challenges for MikroTik equipment seems to be switching and VLANs in the CRS series. Admittedly, the revamp of VLAN configuration for MikroTik CRS switches in early 2018 made things a lot easier. But, sometimes there is still confusion on how to configure VLANs and IP addresses in VLANs with MikroTik RouterOS operating on a switch.

This will only cover VLAN configuration for CRS 3xx series switches in RouterOS as SwitchOS is not nearly as common in operational deployments.

CRS 1xx/2xx series use an older style of configuration and seem to be on the way out so I’m not 100% sure whether or not i’ll write a similar guide on that series.

If you’ve been in networking for a while, you probably started with learning the Cisco CLI. Therefore, it is helpful to compare the commands if you want to implement a network with a MikroTik and Cisco switches.

This is the fourth post in a series that creates a Rosetta stone between IOS and RouterOS. Here are some of the others:

Click here for the first article in this series – “Cisco to MikroTik BGP command translation”
Click here for the second article in this series – “Cisco to MikroTik OSPF command translation”
Click here for the third article in the series – “Cisco to MikroTik MPLS command translation”

While many commands have almost the exact same information, others are as close as possible. Since there isn’t always an exact match, sometimes you may have to run two or three commands to get the information needed.

Hardware for testing

In the last article, we began using EVE-NG instead of GNS3 to emulate both Cisco IOS and RouterOS so we could compare the different commands and ensure the translation was as close as possible. However in switching, we still have to use real hardware at least in the realm of MikroTik – Cisco has IOSvL2 images that can be used in EVE-NG for switching.

Notes on hardware bridging in the CRS series

Bridging is a very confusing topic within the realm of MikroTik equipment. It is often associated with CPU forwarding and is generally seen as something to be avoided if at all possible.

There are a few reasons for this…

1. Within routers, bridging generally does rely on the CPU for forwarding and the throughput is limited to the size of the CPU.

2. In the previous generation of CRS configuration, bridging was not the best way to configure the switch – using the port master/slave option would trigger hardware forwarding.

After MikroTik revamped the switch config for VLANs in 2018 to utilize the bridge, it more closely resembles the style of configuration for Metro Ethernet Layer 2 as well as vendors like Juniper that use the ‘bridge-domain’ style of config.

Using the bridge for hardware offload of L2 traffic

Note the Hw. Offload verification under this bridge port in the CRS317

It is important to realize that bridging in the CRS, when used for VLAN configuration is actually using the switch ASIC to forward traffic and not the CPU.

In this instance, the bridge is merely used as a familiar configuration tool to tie ports and VLANs together but does in fact allow for the forwarding of traffic in hardware at wirespeed.

Cisco to MikroTik – command translation

Cisco commandMikroTik Command
interface FastEthernet5/0/47
switchport access vlan 100
switchport mode access
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus1 pvid=100
interface GigabitEthernet5/0/4
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200
switchport mode trunk
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=200
interface Vlan200
ip address
/interface vlan
add interface=bridge1 name=vlan200 vlan-id=200
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1,bridge1 vlan-ids=200
/ip address
add address= interface=vlan200 network=
spanning-tree mode mst
/interface bridge
add fast-forward=no name=bridge1 priority=0 protocol-mode=mstp region-name=main vlan-filtering=yes
interface FastEthernet5/0/47
switchport access vlan 200
switchport mode access
spanning-tree portfast
interface bridge port set edge=yes-discover
interface GigabitEthernet5/0/4
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200
switchport mode trunk
channel-group 1 mode active

interface Port-channel1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200
switchport mode trunk
interface bonding
add mode=802.3ad name=Po1 slaves=sfp-sfpplus1,sfp-sfpplus3 \

/interface bridge vlan
add bridge=bridge1 tagged=Po1,bridge1 vlan-ids=200
show mac address-tableinterface bridge host print
show mac address-table vlan 200interface bridge host print where vid=200
show mac address-table interface Gi5/0/4interface bridge host print where interface=sfp-sfpplus1
show interfaces trunk
show vlan
interface bridge vlan print
show spanning-tree
interface bridge monitor
show etherchannel summaryinterface bonding print detail

Examples of the MikroTik RouterOS commands from the table above

Untagged switch port

This command will create an untagged or “access” switch port on VLAN 100

Tagged switch port

This command will create a tagged or “trunk” switch port on VLAN 200. Additional VLANs can be tagged on a port by using the same syntax and adding a new VLAN number.

Layer 3 VLAN Interface

Similar to a Cisco SVI (but dependent on the CPU and not an ASIC) this command will create a layer 3 interface on VLAN 200

Multiple STP

This command will set the bridge loop prevention protocol to Multiple Spanning Tree. As a general observation, MSTP tends to be the most compatible across vendors as some vendors like Cisco use a proprietary version of Rapid STP.

STP Edge port

This is referred to as “portfast” in the Cisco world and allows a port facing a device that isn’t a bridge or a switch to transition immediately to forwarding but if it detects a BPDU, it will revert to normal STP operation. (this is the difference between edge=yes and edge=yes-discover)

LACP Bonding

This command will create a bonding interface which is similar to a Port Channel in Cisco’s switches. Two or more physical interfaces can be selected to bond together and then the 802.3ad mode is selected which is LACP. You can also select the hashing policy and ideally it should match what the device on the other end is set for to get the best distribution of traffic and avoid interoperability issues.

View the MAC table of the switch

This print command will show all learned MAC addresses and associated VLANs in the CAM table of the switch

View the MAC table for VLAN 200 in the switch

This print command will show all learned MAC addresses in VLAN 200.

View the MAC table for bonding interface Po1 in the switch

This print command will show all learned MAC addresses on port Po1.

View the current VLANs configured in the switch 

The bridge vlan print command will show all configured VLANs in the switch.

View Bridge Spanning Tree information 

The bridge monitor command will show the configuration details and current state of spanning tree including the root bridge and root port

LACP Bonding information

This command will show the details of the LACP configuration and whether the bonding interface is running which indicates a valid LACP neighbor.

WISP Design – An overview of adding IPv6 to your WISP

The challenge of adding IPv6 to your WISP

IPv6 is one of those technologies that can feel pretty overwhelming, but it doesn’t have to be. Many of the same ideas and concepts learned in IPv4 networking still apply.

This guide is meant to give you an overview of an example IPv6 addressing plan for an entire WISP as well as the config needed in MikroTik to deploy IPv6 from a core router all the way to a subscriber device.


Benefits of adding IPv6

  • Public addressing for all subscribers – reduced need for NAT
  • Regulatory compliance – public addressing that is persistent makes it much easier to be compliant for things like CALEA
  • Reduced complaints from gamers – Xbox and Playstation both have IPv6 networks and prefer IPv6. This reduces complaints from customers who have gaming consoles that have detected an “improper” NAT configuration.
  • Increased security – IPv6, while not impervious to security threats makes it much harder for attackers to scan IPs due to the sheer size of the IP space. If using privacy extensions with SLAAC, it also makes it much harder to target someone online as the IP address seen on the internet changes randomly.
  • Improved real time communications – one way audio and video issues are often caused by NAT. Using end to end connectivity on public addressing improves the reliability of IP voice and video when used on IPv6
  • Web scale content (Netflix, Facebook, Google, etc) is IPv6 enabled which means a large portion of your traffic will shift to native IPv6 once dual stack is enabled.


IPv6 Addressing

One of the things i’ve learned about IPv6 is that addressing plans seem to spark epic debates about the waste of addresses and what size prefix an end subscriber should get.

Although this lab could have easily been done with a /56 at the tower and /53 at each AP, I decided to use RIPEs recommendations from their guide on IPv6 best operational practices.

This is mainly to keep the focus of the article on actually getting IPv6 deployed and not focusing on the addressing.


Dual Stack

For simplicity, the IPv4 config is not shown, but the recommended design for an operational WISP is to implement IPv4 and IPv6 side by side in a Dual Stack configuration.


Lab Overview

The lab is designed to illustrate most of the operational aspects of IPv6 in a WISP using MikroTik CHR routers in EVE-NG. This includes:

  • DHCPv6 and Prefix Delegation (PD)
  • OSPFv3 single area configuration and origination of a default route
  • Subscriber router example with SLAAC

Core Router



In the lab, the core router is shown directly connected to the tower for simplicity, in your WISP, there may be multiple towers between the core and the end of the network.

The concept, however is the same – use /126 addressing to connect towers for OSPFv3.

Note that OSPFv3 still requires a router-id in dotted decimal format, even though the address you put int doesn’t have to actually exist – for consistency however, use the IPv4 loopback of the router for the router id.

The internet connectivity isn’t shown in this lab, but your ISP will give you a /126 address to connect to your border router and either peer with BGP or the provider can route the /32 prefix to you.



Tower Router



The tower router is handling most of the work as it is responsible for DHCPv6 and Prefix Delegation as well as advertising the /48 AP subnets into OSPF

In this lab , the APs are split into separate VLANs (with dual stack, IPv4 would exist on the same VLAN).

The router is configured to hand out /56 prefixes to the end subscriber using a pool of /48 per AP.

Because Prefix Delegation is being utilized, a dynamic static route is created for each /56 the DHCPv6 server hands out which eliminates the need to use a routing protocol.

Prefix Delegation in action

This example shows the prefixes allocated by the router and the dynamic static routes created


Subscriber Routers


For simplicity, MikroTik is used as the Subscriber or CPE router to provide an example of how the /56 prefix is received from the tower router and handed off to devices inside the subscriber’s home.

In this lab, the “WAN” interface or ether1 has a DHCPv6 client configured to receive the prefix from the tower router.

Ether2 or the “LAN” side, which would include a bridge of the the wireless/wired interfaces in a real router is configured with a dynamic /64 from the /56 pool and is set for SLAAC to give devices on this segment an IPv6 address.


DHCPv6 client and subscriber addresses/routes


Config – Subscriber 1

Config – Subscriber 2


Subscriber Device

EVE-NG has a small Linux image that can be used as a host called VPC or virtual PC. This allows us to put a device on ether2 and test end to end reachability back to the core router.

SLAAC addressing example

Ping test back to the core router



Let IPA help you with your IPv6 transition

The team at IP ArchiTechs has decades of experience in networking and specializes in WISP design, troubleshooting and operation. Click on the graphic below to contact IP ArchiTechs and get help with your networking problems.