Overview

Routing filters have been a hot topic lately in the world of RouterOSv7. The first implementation of routing filters in ROSv7 was difficult to work with and documented in the two articles below:

MikroTik – RouterOSv7 first look – Dynamic routing with IPv6 and OSPFv3/BGP

MikroTik RouterOS – v7.0.3 stable (chateau) and status of general release


MikroTik then made some changes and opened up discussion to get feedback. I did a lot of work and testing using ROS 7.1beta7 which never made it to public release and was close to publishing the results when 7.1rc1 came out so this post will use that version.

RouterOSv7.1rc1 syntax example

Here is an example of the latest syntax in ROSv7.1rc1

CLI

### MikroTik RouterOS 7.1rc1 ###

/routing filter rule
add chain=dead.beef.101 rule="if (dst==200:dead:beef:101::/64) {accept}"
add chain=dead.beef.102 rule="if (dst==200:dead:beef:102::/64) {accept}"
add chain=dead.beef.agg rule="if (dst in 200:dead:beef::/48) {accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.101) {set bgp-local-pref 300; accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.102) {accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.agg && dst-len<128) {set bgp-local-pref 150; accept}"

Winbox

And the corresponding routes received (for the v7 filter rules)

Comparable syntax in ROSv6 (note: recursive routing is not supported in IPv6 so the iBGP routes used to test v7rc1 would not be possible)

### MikroTik RouterOS 6.48.10 (long-term) ###

/routing filter
add action=accept chain=dead.beef.101 prefix=200:dead:beef:101::/64
add action=accept chain=dead.beef.102 prefix=200:dead:beef:102::/64
add action=accept chain=dead.beef.agg prefix=200:dead:beef::/48
add action=accept chain=bgp-out-v6 match-chain=dead.beef.101 set-bgp-local-pref=300
add action=accept chain=bgp-out-v6 match-chain=dead.beef.102 
add action=accept chain=bgp-out-v6 match-chain=dead.beef.agg prefix-length=48-128 set-bgp-local-pref=150

Challenges and Feedback

• Coding vs. Network CLI – The single biggest resistance to the new style of filtering is the string format is hard to work with. It requires knowledge of the match and action statements as well as how to write an expression to correctly parse them. Network engineers are not software engineers and route filtering (much like firewalling) has the capacity to be complex and require many lines of config – which means the format should align with v6 route filters and/or firewall rules.
  

• Tab complete – The lack of tab complete is a big gap. Network engineers, admins and technicians expect to be able to tab complete when creating a config. This is rumored to be in the works and hopefully it will make it into later release candidates.
  
  
• Using context sensitive help with “?” – There are a couple issues with context sensitive help in ROS 7.1rc1. The first issue is using the F1 key for help in any part of ROSv7 (not just filtering) instead of the ‘?’. This should at least be an option that can be set.
  
  The second issue is the lack of context sensitive help for the routing filters – if an engineer is unsure of the syntax, it’s currently not possible to get help from the command line.
  
  This has been a fundamental part of CLI based network operating systems for over 30 years. It needs to be added back.
  
  
  Conclusions
  
  One thing is clear, everyone I discussed it with on Facebook, Reddit, MikroTik Forums and with clients and engineers on my team did not like the new format.
  
  It’s worth noting that MikroTik equipment is often used in remote locations where it isn’t practical to pull up the help docs and engineers in the field rely on the ability to use tab-complete and context sensitive help to finish configuration tasks. This is a critical feature for a network operating system to have.
  
  To MikroTik – please consider implementing the filters so that at a minimum, the features in ROSv6 (like tab-complete, context sensitive help and a non-coding syntax) are maintained while allowing for new functionality.
  

Examples of filtering in other well-known operating systems

Here are some examples of the same filtering rules in different network operating systems for comparison. All of them support tab-complete and context sensitive help.

Free Range Routing is probably one of my favorites because it’s open and is being actively developed. JunOS is very popular from a filtering standpoint because the OS is easy to work with programatically.

Cisco is included because they are pervasive but isn’t at the top of my list because the syntax isn’t anything special and IOS-XR equipment tends to be incredibly expensive even though bugs are still commonplace – so it’s not a great value.

Free Range Routing (https://frrouting.org)

### Free Range Routing v6.0.2 ###

ipv6 prefix-list dead.beef.101 seq 10 permit 200:dead:beef:101::/64
ipv6 prefix-list dead.beef.102 seq 10 permit 200:dead:beef:102::/64
ipv6 prefix-list dead.beef.agg seq 10 permit 200:dead:beef::/48 le 128
!
route-map bgp-out-v6 permit 10
 match ipv6 address prefix-list dead.beef.101
 set local-preference 300
!
route-map bgp-out-v6 permit 20
 match ipv6 address prefix-list dead.beef.102
!
route-map bgp-out-v6 permit 30
 match ipv6 address prefix-list dead.beef.agg
 set local-preference 150
### Free Range Routing v6.x ###!

Juniper Networks JunOS (https://junipernetworks.com)

### Juniper JunOS 18.x ###

policy-options {
    prefix-list dead.beef.101 {
        200:dead:beef:101::/64;
    }
    prefix-list dead.beef.102 {
        200:dead:beef:102::/64;
    }
    prefix-list dead.beef.agg {
        200:dead:beef::/48;
    }
    policy-statement bgp-out-v6 {
        term dead.beef.101 {
            from {
                prefix-list dead.beef.101;
            }
            then {
                local-preference 300;
                accept;
            }
        }
        term dead.beef.102 {
            from {
                prefix-list dead.beef.102;
            }
            then accept;
        }
        term dead.beef.agg {
            from {
                prefix-list-filter dead.beef.agg orlonger;
            }
            then {
                local-preference 150;
                accept;
            }
        }
    }
}

Cisco Networks IOS XR (https://cisco.com)

### Cisco IOS-XR x.x ###

prefix-set dead.beef.101
  200:dead:beef:101::/64
end-set
!
prefix-set dead.beef.102
  200:dead:beef:102::/64
end-set
!
prefix-set dead.beef.agg
  200:dead:beef::/48 le 128
end-set
!
route-policy bgp-out-v6
  if destination in dead.beef.101 then
    set local-preference 300
    pass
  elseif destination in dead.beef.102 then
    pass
  elseif destination in dead.beef.agg then
    set local-preference 150
    pass
  endif
end-policy

If you don’t already use it, the MIkroTik v7 BETA forum (forum.mikrotik.com) is a fantastic source of information

When will stable be released?

This is the million dollar question. Technically, it already has been for one hardware platform…

!! Spoiler Alert – There is *already* a stable release of ROSv7 – v7.0.3!!

The Chateau 5G router originally shipped with a beta version of ROSv7 but was quietly moved to a stable version that’s developed specifically for that platform.

Because of the way MikroTik’s code repo works, this version can’t easily be added to the main download page and support provides the software:

ROSv7.0.3 Stable Download (!!! Chateau Only – will brick other hardware !!!)

https://box.mikrotik.com/f/7e3cad5779804d0b878d/?dl=1

It’s worth repeating MikroTik’s warning about using this on any platform other than the Chateau

What’s holding up v7 from being released?

If you’ve been around MikroTik for a while, then you know that version 7 has been in the works for a long time to add new functionality and address limitations of the older Linux kernel in ROSv6.

MikroTik recently added a detailed update on where the development roadmap is at and what the challenges are:

What does this mean?

• Routing filters need to be rewritten to simplify the syntax and operation – there were a lot of complaints with the original syntax.
• Routing protocols like OSPF and BGP have been unstable in beta1 through beta6 and need some work to stabilize them.
  

What’s the issue with routing filters?

The original v7 routing filters were very complicated to work with and had esoteric terms for operations like ‘subsumes’ and required ‘rule’ and ‘select-rule’ config to actually reference the filter in the routing process.

Previous filter syntax:

I wrote an article in late 2020 on IPv6 with BGP/OSPF using beta2 and captured a few screenshots that aren’t in the online docs anymore.

More details are in the article here:

MikroTik – RouterOSv7 first look – Dynamic routing with IPv6 and OSPFv3/BGP – StubArea51.net

New syntax?

If the current filter documentation represents the newer style, there are several differences in the format. The more complicated language like ‘subsumes’ is gone and only one filter rule is required to use the filter in the routing process – the ‘select-rule’ syntax is gone.

The new filter syntax appears to have made it onto help.mikrotik.com under /routing/filter but this may change in the coming weeks.

Example:

Similar to the OSPF example above, this is the example listed under the filter section for the new format.

The options below represent the matching order and the possible readable and set parameters.

Accepted Syntax:

if ( [matchers] ) { [actions] } else { [actions] }

[matchers]:
[prop readable] [bool operator] [prop readable]

[actions]:
[action] [prop writeable] [value]

Accepted parameters:

[num prop readable]
dst-len
bgp-path-len
bgp-input-local-as
bgp-input-remote-as
bgp-output-local-as
bgp-output-remote-as
ospf-metric
ospf-tag
rip-metric
rip-tag

[num prop writable]
distance
scope
scope-target
bgp-weigth
bgp-med
bgp-out-med
bgp-local-pref
bgp-igp-metric
bgp-path-peer-prepend
bgp-path-prepend
ospf-ext-metric
ospf-ext-tag
rip-ext-metric 
rip-ext-tag 

[flag prop readable]
active
bgp-attomic-aggregate
bgp-communities-empty
bgp-communities-ext-empty
bgp-communities-large-empty
bgp-network
ospf-dn

[flag prop writable]
ospf-ext-dn
blackhole
use-te-nexthop

[predicate]
bgp-communities|bgp-communities-ext|bgp-communities-large
    equal|any|includes|subset
	{inline set}	
    equal-set|any-set|includes-set|subset-set
	{set name}
    any-regexp|subset-regexp
	{regexp}
comment
    text|find|regexp
	{string}
chain
    {chain name}
vrf
    {vrf}
rtab
    {rtab}
gw-interface
    {interface}
gw-check
    none|arp|icmp|bfd|bfd-mh	
afi
    ipv4|ipv6|l2vpn|l2vpn-cisco|vpnv4|vpnv6
	,...
protocol
    connected|static|bgp|ospf|rip|dhcp|fantasy|modem|vpn
	,...
bpg-origin
    igp|egp|incomplete
	,...
bgp-as-path
    {regexp}
rpki
    valid|invalid|unknown
ospf-type
    intra|inter|ext1|ext2|nssa1|nssa2
ospf-ext-type
    type1|type2
[num prop readable]
    in
	{int..int}|{int-int}
    ==|!=|<=|>=|<|>
	{int}
[prfx prop readable]
    !=|==|in
	{address 46/}
[flag prop readable]


[block]
if ([predicate] &&/|| ...) { [block] } [ else {[block]} ]
accept|reject|return
jump {chain name}
unset
    pref-src|bgp-med|bgp-out-med|bgp-local-pref
bgp-communities|bgp-communities-ext|bgp-communities-large
    append|replace|filter-in|filter-not-in
	{inline community set}
    append-set|replace-set|filter-in-set|filter-not-in-set
	{set name}
    filter-in-regexp|filter-not-in-regexp
	{regexp}
    delete
	wk|other <-- for communities
	    ,...
	rt|soo|other <-- for ext-communities
	    ,...
	all <-- for large-communities
rpki-verify 
    {rpki group name}
comment
    set|append
	{string}
set
    [num prop writable]
	[num prop readable]|[num prop writable]
	+/-	
	    [num prop readable]|[num prop writable]
    gw
	interface
	    {interface}
	{address 46i}
    gw-check
	none|arp|icmp|bfd|bfd-mh	
    pref-src
	{address 46}
    bgp-origin
	igp|egp|incomplete
    ospf-ext-fwd
	{address 46}
    ospf-ext-type
	type1|type2



[num prop readable]
    in
        {int..int}|{int-int}
    ==|!=|<=|>=|<|>
        {int}
        [num prop readable]

What are the problems with routing protocols?

The routing stack has been completely re-written for ROSv7 from what we are told. This takes some time.

When I was last out in Silicon Valley, I met with a company that just emerged from stealth and had designed a new Network OS. They spent 3 years in stealth working on nothing but the OS with no actual product being sold – just coding and development.

So it’s not surprising this process has taken a while.

Stabilizing protocol issues

There are a number of bugs we’ve seen in the early versions of ROSv7 beta for routing protocols that are being worked through. Things like OSPF checksum, interface templates, high cpu when areas are disabled/enabled….etc.

Now that we know routing protocols are a priority and the new filter syntax is taking shape, I would expect to see some improvement across the next 2 to 3 beta releases to get routing protocols stable with simple configs.

L3 Switching

From talking to a lot of people that write code for Network OSes and work on the interaction with the ASIC, this is one of the hardest areas to get right – pushing routes from the RIB down into the HW FIB.

MikroTik hired new developers to meet this challenge:

MikroTik has updated the L3 HW doc pages to provide a roadmap of features and functionality for the beta series.

It appears that Jumbo MTU is the next major feature to be added for L3 HW in ROSv7.1beta7

When will ROSv7 move to release candidate and then stable?

When asked about the state of ROSv7, my typical answer has been that we’ll see a stable version in mid 2022 based on the pace of development.

I think that’s still a fair answer based on the pace of development.

It seems like the routing protocols and filters we need a few more beta versions to get working and then they’ll move to release candidates – my estimate is to look for the RCs towards the end of 2021.

Hopefully this has been helpful…i’ll probably write another summary on the state of ROSv7 once more progress has been made.

In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly.  Juniper is a popular option for service providers/data centers and is widely deployed across the world. 

This is a continuation of the Rosetta stone for network operating systems series.  In this article we will be covering multi-protocol label switching (MPLS) using label distribution protocol (LDP). We are sticking with LDP as MikroTik does not have wide support for RSVP-TE.

You can find the first two articles of the series here:

Juniper to MikroTik – BGP commands

Juniper to MikroTik – OSPF commands

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. 

Using EVE-NG for testing

We conducted utilized EVE-NG for all of the testing with the topology seen below.

Examples of the commands above

This first command will show you some basic information about your MPLS LDP neighbors. On juniper you can add the keyword detail to the end for additional information on the neighbors.

[admin@MikroTik-R3] > mpls ldp neighbor print

root@JUNOS-R2> show ldp neighbor

This command will list all of the interfaces that are currently enabled for LDP.

[admin@MikroTik-R3] > mpls ldp interface print

root@JUNOS-R2> show ldp interface

Use this command to display the MPLS forwarding table which shows what labels are assigned, the interface used and the next-hop. It will also tell you the action taken such as pop, swap, or push.

[admin@MikroTik-R3] > mpls forwarding-table print

root@JUNOS-R2> show route forwarding-table family mpls

The next two commands will be combined since juniper only has one command to be equivalent to mikrotiks output. This is will show the advertised and received labels for all of the prefixes known to LDP as well as the label associated with it and where it was learned from. On JunOS you will notice label 3. This is juiper’s method to signal implicit null and request label popping by the downstream router.

[admin@MikroTik-R3] > mpls remote-bindings print

[admin@MikroTik-R3] > mpls local-bindings print

root@JUNOS-R2> show ldp database

This last command will show the label ranges and what they are used for.

[admin@MikroTik-R3] > mpls print

root@JUNOS-R2> show mpls label usage

Configurations

root@JUNOS-R1# show | display set
set version 18.2R1.9
set system root-authentication encrypted-password "$6$iCt/DOMc$lQFrIQdrjot1m0lIY5A2eUaOmat87oAqbNZWd/3KPij2QWTlBQEyYlVbb1/emd2N9VKN6NL0olk.kJK7mLcgM0"
set system host-name JUNOS-R1
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system processes dhcp-service traceoptions file dhcp_logfile
set system processes dhcp-service traceoptions file size 10m
set system processes dhcp-service traceoptions level all
set system processes dhcp-service traceoptions flag packet
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.1/29
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces fxp0 unit 0 family inet dhcp vendor-id Juniper-vmx-VM6015C6C2F2
set interfaces lo0 unit 0 family inet address 10.1.1.1/32
set routing-options router-id 10.1.1.1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ldp interface ge-0/0/0.0

root@JUNOS-R2# show | display set
set version 18.2R1.9
set system root-authentication encrypted-password "$6$x.MmgodX$XG1D3lCYPC8VpIhE8NXxdRJaoZS8sYB2PB0v50POrrx6Mi.nhnTB/41NGFk1zL8RDQBdR/lCPG2NazFDYgzNf/"
set system host-name JUNOS-R2
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system processes dhcp-service traceoptions file dhcp_logfile
set system processes dhcp-service traceoptions file size 10m
set system processes dhcp-service traceoptions level all
set system processes dhcp-service traceoptions flag packet
set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.2/29
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.9/29
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces fxp0 unit 0 family inet dhcp vendor-id Juniper-vmx-VM6015C6C3B3
set interfaces lo0 unit 0 family inet address 10.1.1.2/32
set routing-options router-id 10.1.1.2
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ldp interface ge-0/0/0.0
set protocols ldp interface ge-0/0/1.0

[admin@MikroTik-R3] > export
# jan/31/2021 20:52:19 by RouterOS 6.46.8
# software id =
#
#
#
/interface bridge
add name=Loopback0
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=203.0.113.10/29 interface=ether1 network=203.0.113.8
add address=10.1.1.3 interface=Loopback0 network=10.1.1.3
add address=203.0.113.17/29 interface=ether2 network=203.0.113.16
/ip dhcp-client
add disabled=no interface=ether2
add disabled=no interface=ether1
/mpls ldp
set enabled=yes lsr-id=10.1.1.3
/mpls ldp interface
add interface=ether1
add interface=ether2
/routing ospf network
add area=backbone network=203.0.113.8/29
add area=backbone network=10.1.1.3/32
add area=backbone network=203.0.113.16/29
/system identity
set name=MikroTik-R3

[admin@MikroTik-R4] > export
# jan/31/2021 21:06:10 by RouterOS 6.46.8
# software id =
#
#
#
/interface bridge
add name=Loopback0
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=203.0.113.18/29 interface=ether1 network=203.0.113.16
add address=10.1.1.4 interface=Loopback0 network=10.1.1.4
/ip dhcp-client
add disabled=no interface=ether2
add disabled=no interface=ether1
/mpls ldp
set enabled=yes lsr-id=10.1.1.4
/mpls ldp interface
add interface=ether1
/routing ospf network
add area=backbone network=203.0.113.16/29
add area=backbone network=10.1.1.4/32
/system identity
set name=MikroTik-R4

Thanks for joining us for this series and check back soon for more posts.

In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly.  Juniper is a popular option for service providers/data centers and is widely deployed across the world. 

This is a continuation of the Rosetta stone for network operating systems series.  In this portion of the series we will be covering Open Shortest Path First, OSPF, version 2 which is a popular interior gateway protocol (IGP).

You can find the first article of the series Juniper to Mikrotik – BGP Commands here.

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. 

Using EVE-NG for testing

We conducted all testing on EVE-NG utilizing the topology seen below.

Examples of the commands above

This first command will show you all of the routers you have an OSPF neighbor adjacency with.

[admin@MIKROTIK-OSPF] > routing ospf neighbor print

root@JUNOS-OSPF> show ospf neighbor

This next command lists all of the interface enabled for OSPF as well as some basic information such as cost, priority, and network type. Juniper displays slightly different information such as area, DR info, and number of neighbors. Juniper does not have the concept of a network statement so interfaces explicitly configured for OSPF will appear here. You can optionally add the detail command on JunOS for more information.

[admin@MIKROTIK-OSPF] > routing ospf interface print

root@JUNOS-OSPF> show ospf interface

This command will list all of the details regarding the OSPF instances running on the router.

[admin@MIKROTIK-OSPF] > routing ospf instance print

root@JUNOS-OSPF> show ospf overview brief

This command lists all of the OSPF LSAs as well as some details about them.

[admin@MIKROTIK-OSPF] > routing ospf lsa print

root@JUNOS-OSPF> show ospf database

This next command will show all of the OSPF routes in the routing table.

[admin@MIKROTIK-OSPF] > ip route print where ospf=yes

root@JUNOS-OSPF> show route protocol ospf

This next set of commands will show you the area-border-routers or autonomous-system-boundary routers. We injected a connected route into OSPF to generate a type-5 LSA for an external route.

[admin@MIKROTIK-OSPF] > routing ospf area-border-router print

[admin@MIKROTIK-OSPF] > routing ospf as-border-router print

root@JUNOS-OSPF> show ospf route abr

root@JUNOS-OSPF> show ospf route asbr

Mikrotik OSPF configuration

/interface bridge
add name=Loopback0
add name=Loopback1
add name=Loopback2
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/routing ospf area
add area-id=0.0.0.51 name=Area51
/routing ospf instance
set [ find default=yes ] redistribute-connected=as-type-1 router-id=203.0.113.2
/ip address
add address=203.0.113.2 interface=Loopback0 network=203.0.113.2
add address=203.0.113.3 interface=Loopback1 network=203.0.113.3
add address=203.0.113.4 interface=Loopback2 network=203.0.113.4
add address=203.0.113.130/29 interface=ether1 network=203.0.113.128
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1
/routing ospf interface
add dead-interval=4s hello-interval=1s interface=ether1 network-type=point-to-point
/routing ospf network
add area=backbone network=203.0.113.2/32
add area=backbone network=203.0.113.128/29
add area=Area51 network=203.0.113.3/32
/system identity
set name=MIKROTIK-OSPF

Juniper OSPF configuration

set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.129/29
set interfaces lo0 unit 0 family inet address 203.0.113.1/32
set routing-options router-id 203.0.113.1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 hello-interval 1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 dead-interval 4
set protocols ospf area 0.0.0.0 interface lo0.0 passive

More Juniper to MikroTik articles are on the way!

This article covered some of basic and common OSPF commands. Check back in the future for examples of more advanced features and capabilities. Also stay tuned for our upcoming Juniper to MikroTik MPLS command translation.

In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly.  Juniper is a popular option for service providers/data centers and is widely deployed across the world. 

This is a continuation of the Rosetta stone for network operating systems series.  We’ll be working through several protocols over series of posts to help you quickly move between different environments. 

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. 

Using EVE-NG for testing

We conducted all of this testing utilizing EVE-NG and the topology seen below. 

Juniper Command	MikroTik Command
show bgp summary	routing bgp peer print brief
show bgp neighbor	routing bgp peer print status
show route advertising-protocol bgp 172.31.254.2	routing bgp advertisements print peer=peer_name
show route receive-protocol bgp 172.31.254.2	ip route print where received-from=peer_name
show route protocol bgp	ip route print where bgp=yes
clear bgp neighbor 172.31.254.2 soft-inbound	routing bgp peer refresh peer_name
clear bgp neighbor 172.31.254.2 soft	routing bgp peer resend peer_name
set routing-options autonomous-system 1	/routing bgp instance set default as=2
set protocols bgp group EBGP type external set protocols bgp group EBGP peer-as 2 set protocols bgp group EBGP neighbor 172.31.254.2	/routing bgp peer add name=PEER-1 remote-address=172.31.254.1 remote-as=1
set policy-options policy-statement REDIS-CONNECTED term 1 from protocol direct set policy-options policy-statement REDIS-CONNECTED term 1 then accept set protocols bgp group EBGP export REDIS-CONNECTED	/routing bgp network add network=100.89.88.0/24 add network=100.89.87.0/24 add network=100.89.86.0/24
set routing-options static route 0.0.0.0/0 discard set protocols bgp group EBGP export SEND-DEFAULT set policy-options policy-statement SEND-DEFAULT term 1 from protocol static set policy-options policy-statement SEND-DEFAULT term 1 from route-filter 0.0.0.0/0 exact set policy-options policy-statement SEND-DEFAULT term 1 then accept	/routing bgp peer add default-originate-always name=PEER-1 remote-address=172.31.254.1 remote-as=1

Examples of the commands above

This is a quick way to get a list of the peers/ASN and their status

[admin@MIKROTIK-BGP] > routing bgp peer print brief

root@JUNOS-BGP> show bgp summary

This next command will show you more information about a peer.  In this case we did not specify the peer as there is only one.  On a peering router with multiple peers it is recommended to look only at specific peer information to not be overwhelmed with irrelevant information. 

[admin@MIKROTIK-BGP] > routing bgp peer print status

root@JUNOS-BGP> show bgp neighbor

The next command allows you to see the prefixes that are sent to your peer as well as the next-hop associated with it. 

[admin@MIKROTIK-BGP] > routing bgp advertisements print peer=PEER-1

root@JUNOS-BGP> show route advertising-protocol bgp 172.31.254.2

This next one will show you what routes were received from the peer and the next-hop you will advertise. 

[admin@MIKROTIK-BGP] > ip route print where received-from=PEER-1

root@JUNOS-BGP> show route receive-protocol bgp 172.31.254.2

Here we will see the BGP prefixes that are in the routing table – both active and not.  On junOS you will see the count for hidden routes in the output but you will not see the hidden entries.  This will require the use of “show route protocol bgp hidden” to see the hidden entries.  On mikrotik you will see this type of route in the route table as inactive. 

[admin@MIKROTIK-BGP] > ip route print where bgp=yes

root@JUNOS-BGP> show route protocol bgp

Configure BGP instance, peering, and originate a default route. 

Here is a very basic BGP peering configuration to establish a peer, advertise a few routes, and originate a default route. 

Let’s look at some of the differences in the configuration. 

It’s worth noting that everything in CAPS was manually defined . 

On junOS there is no concept of the “network” command that you might see in MikroTik or Cisco.

To accomplish the same functionality in this example I used a policy-statement named REDIS-CONNECTED that matched any connected route for redistribution. 

This is then applied as an export statement into the EBGP peer group.  Likewise, there is not a construct for “default-originate”.  In order to accomplish the same functionality, we created a static route to discard and exported this to the EBGP peer.

MikroTik BGP Configuration

/routing bgp instance
set default as=2
/routing bgp network
add network=100.89.88.0/24
add network=100.89.87.0/24
add network=100.89.86.0/24
/routing bgp peer
add default-originate=always name=PEER-1 remote-address=172.31.254.1 remote-as=1

Juniper BGP Configuration

set interfaces lo0 unit 0 family inet address 100.99.98.1/24
set interfaces lo0 unit 0 family inet address 100.99.97.1/24
set interfaces lo0 unit 0 family inet address 100.99.96.1/24
set routing-options static route 0.0.0.0/0 discard
set routing-options autonomous-system 1
set protocols bgp group EBGP type external
set protocols bgp group EBGP export REDIS-CONNECTED
set protocols bgp group EBGP export SEND-DEFAULT
set protocols bgp group EBGP peer-as 2
set protocols bgp group EBGP neighbor 172.31.254.2
set policy-options policy-statement REDIS-CONNECTED term 1 from protocol direct
set policy-options policy-statement REDIS-CONNECTED term 1 then accept
set policy-options policy-statement SEND-DEFAULT term 1 from protocol static
set policy-options policy-statement SEND-DEFAULT term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement SEND-DEFAULT term 1 then accept

More to come

There are so many commands to consider for BGP, we probably could have added close to 100, but we decided to list the commands we use most often to start with and will be adding to the list of BGP commands as well as other like OSPF, MPLS, and VLANs in future posts. 

Overview

One of the long awaited benefits of RouterOS version 7 is a new routing protocol stack that enables new capabilities and fixes limitations in RouterOSv6 caused by the use of a very old Linux kernel.

The new routing stack in v7 has created quite a buzz in the MikroTik community as lab tests have shown that it’s significantly more efficient in processing large numbers of BGP routes.

The ability to use MikroTik’s new generation of CCR routers with ARM64 to quickly process BGP routes is a blog post all to itself and we’ll tackle that in the future – however, the information below provides a quick look into the performance comparison between ROS v6 and v7.

The new routing stack also paves the way to add a number of features that have been needed for a long time like RPKI and large community support.

Using a lab based on EVE-NG, we’ll take a look at configuration changes and iBGP using the IPv6 AFI with OSPFv3 as the IGP for loopback/next hop reachability. Prior to 7.1beta2, this has been nonfunctional for years due to routing recursion limitations.

v7 Routing Protocol Status

For the most up to date information about features and capabilities in v7, MikroTik created a page that tracks feature status across the different beta releases

https://help.mikrotik.com/docs/display/ROS/v7+Routing+Protocol+Status

Lab design

ROS Version: 7.1beta2 (7.1beta3 was released just before I published this – at some point i’ll update with testing on beta3)
Network Modeling: EVE-NG Pro

OSPFv3

One of the biggest changes in OSPF for both version 2 (IPv4) and version 3 (IPv6) is the consolidation of menus into a single location for OSPF configuration.

In ROSv7, all configuration occurs under /routing/ospf/ and instances can be created for v2 or v3.

Change from ROSv6: OSPF Menu options have changed in ROSv7, this is partly due to combining OPSFv2 and OSPFv3 into a single configuration framework.

OSPF command options in ROSv6 for OSPFv2 and OSPFv3

OSPF command options in ROSv7 for both versions of OSPF

Change from ROSv6: There is a new flag in the IPv6 routing table for ECMP and no flag for RIP

When looking at the new output for the routing table, a few things stand out. ECMP has a new flag using the “+” symbol to denote two or more equal paths.

ECMP in IPv6 is a feature limitation that RouterOSv6 had and this will make it easier to deploy IPv6 networks with MikroTik.

RIP or Routing Internet Protocol is missing from the routing flags. It’s unclear at this point whether RIPv2 or RIP-NG will make it into RouterOSv7 since it’s not used very often anymore in prod networks.

Correcting issues with recursive routing in IPv6.

Being able to use recursive routing for advertising loopbacks and using iBGP with IPv6 has been a limitation of ROSv6 for a long time due to the older linux kernel in use.

Now that ROSv7 has added the initial support for OSPF and BGP, we are able to test IPv6 routing recursion.

Here is a test from PE-1 to PE-2 (2001:db8:101::12) using iBGP

It works!

Change from ROSv6: Using filters in OSPF

One of the first major challenges I had to solve when working with ROSv7 was figuring out why every route available became advertised into OSPF.

At first it looked like a bug, but when I dug deeper, I came across this snippet in the new MikroTik help docs

ROSv7 Basic Routing Examples – RouterOS – MikroTik Documentation

As it turns out, the default behavior is to advertise all routes in the absence of an outbound filter.

The next challenge was figuring out the new filtering syntax.

/routing filter rule
add chain=OSPF-permit-only-configured
/routing filter select-rule
add chain=OSPF-permit-only-configured_select do-where=\
OSPF-permit-only-configured

In order to use a rule in ROSv7, the “/routing filter select-rule” command must be used and reference the filter rule or no action will be taken.

In the example above, only interfaces that have been configured for OSPF will be advertised.

OSPF Config

Here is a summary of the OSPF configuration from the PE-1 router

/routing ospf instance
add name=IPv6 out-filter=OSPF-permit-only-configured_select router-id=\
100.127.0.11 version=3
/routing ospf area
add area-id=0.0.0.0 instance=IPv6 name=area-0
/routing filter rule
add chain=OSPF-permit-only-configured
/routing filter select-rule
add chain=OSPF-permit-only-configured_select do-where=\
OSPF-permit-only-configured
/routing ospf interface
add area=area-0 network=ether1 network-type=point-to-point
add area=area-0 network=ether2 network-type=point-to-point
add area=area-0 network=lo-ospf network-type=broadcast

BGP

As with OSPF, BGP saw a change in menu structure.

In ROSv7, BGP configuration has been revamped and is much closer to the style of configuration that Cisco/Juniper use with config elements that can be nested and reused.

Considering all the work that’s being done to improve full table convergence time on ROSv7, this change is a step in the right direction to allow MikroTik to compete with larger network vendors in the area of peering and transit.

Change from ROSv6: BGP Menu options have changed in ROSv7 to accommodate new features like Templates and RPKI

BGP command options in ROSv6

BGP command options in ROSv7

New Feature: BGP Roles

This is a new capability in BGP as of July 2020 and MikroTik was one of the first to have it implemented.

draft-ietf-idr-bgp-open-policy-13 – Route Leak Prevention using Roles in Update and Open messages

The main goal is to classify peerings into different roles that prevent inadvertent route leaks by adopting some basic filtering policies as a component of the role assignment.

Acceptable pairings are:

Here is an example of role types in ROSv7

This is an overview of how the roles deal with route advertisements and filtering.

New Feature: BGP Templates

BGP Templates allow specific settings for a peer connection to be reused in the connection configuration.

This saves quite a bit of time when deploying a large number of iBGP peerings, transit peerings, IX peerings, etc

Options available to set in templates

Here is a BGP template as configured in the lab for this post. The template is referenced by the connection config (aka peer config)

/routing bgp template
add address-families=ipv6 as=8675309 instance=bgp name=ASN-8675309

/routing bgp connection
add local.address=2001:db8:127::11 .role=ibgp-rr-client remote.address=\
2001:db8:127::1 .as=8675309 template=ASN-8675309

New Feature: iBGP ECMP for IPv6

ECMP has been working in ROSv6 for a ling time, but due to kernel limitations, it hasn’t been available in IPv6 due to the problems in routing recursion and making iBGP operational.

Now that routing recursion is fixed for IPv6, ECMP is possible.

ECMP capable IPV6 routes in BGP noted by the new “+” symbol in the routing table for ECMP.

Here is an example of a traceroute to the same prefix that’s using two different paths with ECMP.

BGP Configuration

Here is an overview of the BGP configuration for PE-1

/routing instance
add id=100.127.0.11 name=bgp
/routing bgp template
add address-families=ipv6 as=8675309 instance=bgp name=ASN-8675309
/routing bgp connection
add local.address=2001:db8:127::11 .role=ibgp-rr-client remote.address=\
2001:db8:127::1 .as=8675309 template=ASN-8675309

Lab configurations

All Lab configs for ROSv7 are listed below (tested in 7.1beta2)

PE-1

/interface bridge
add name=lo-bgp
add name=lo-ospf
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip vrf
add list=all name=main
/routing instance
add id=100.127.0.11 name=bgp
/routing bgp template
add address-families=ipv6 as=8675309 instance=bgp name=ASN-8675309
/routing ospf instance
add name=IPv6 out-filter=OSPF-permit-only-configured_select router-id=\
    100.127.0.11 version=3
/routing ospf area
add area-id=0.0.0.0 instance=IPv6 name=area-0
/ip dhcp-client
add disabled=no interface=ether1
/ipv6 address
add address=2001:db8:126:1::2/126 advertise=no interface=ether1
add address=2001:db8:127::11/128 advertise=no interface=lo-ospf
add address=2001:db8:101::11/128 advertise=no interface=lo-bgp
add address=2001:db8:126:3::2/126 advertise=no interface=ether2
add address=2001:db8:a1a::1 interface=ether4
/routing bgp connection
add local.address=2001:db8:127::11 .role=ibgp-rr-client remote.address=\
    2001:db8:127::1 .as=8675309 template=ASN-8675309
/routing filter rule
add chain=OSPF-permit-only-configured
/routing filter select-rule
add chain=OSPF-permit-only-configured_select do-where=\
    OSPF-permit-only-configured
/routing ospf interface
add area=area-0 network=ether1 network-type=point-to-point
add area=area-0 network=ether2 network-type=point-to-point
add area=area-0 network=lo-ospf network-type=broadcast
/system identity
set name=PE-1

CORE-1

/interface bridge
add name=lo-bgp
add name=lo-ospf
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip vrf
add list=all name=main
/routing instance
add id=100.127.0.1 name=bgp
/routing bgp template
add address-families=ipv6 as=8675309 instance=bgp name=ASN-8675309
/routing ospf instance
add name=IPv6 router-id=100.127.0.1 version=3
/routing ospf area
add area-id=0.0.0.0 instance=IPv6 name=area-0
/ip dhcp-client
add disabled=no interface=ether1
/ipv6 address
add address=2001:db8:126:1::1/126 advertise=no interface=ether1
add address=2001:db8:127::1/128 advertise=no interface=lo-ospf
add address=2001:db8:126:2::1/126 advertise=no interface=ether2
add address=2001:db8:126:3::1/126 advertise=no interface=ether3
add address=2001:db8:101::1/128 advertise=no interface=lo-bgp
add address=2001:db8:126:4::1/126 advertise=no interface=ether4
/routing bgp connection
add listen=yes local.address=2001:db8:127::1 .role=ibgp-rr remote.address=\
    2001:db8:127::11 template=ASN-8675309
add listen=yes local.address=2001:db8:127::1 .role=ibgp-rr remote.address=\
    2001:db8:127::12 template=ASN-8675309
/routing filter rule
add chain=OSPFv3-in match-prfx-value=dst<equal>2001:db8:101::/128
add chain=OSPFv3-in match-prfx-value=dst<equal>2001:db8:101::/128
/routing ospf interface
add area=area-0 network=ether1 network-type=point-to-point
add area=area-0 network=ether2 network-type=point-to-point
add area=area-0 network=ether3 network-type=point-to-point
add area=area-0 network=lo-ospf network-type=broadcast
add area=area-0 network=ether4 network-type=point-to-point
/system identity
set name=CORE-1

PE-2

/interface bridge
add name=lo-bgp
add name=lo-ospf
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip vrf
add list=all name=main
/routing instance
add id=100.127.0.12 name=bgp
/routing bgp template
add address-families=ipv6 as=8675309 instance=bgp name=ASN-8675309
/routing ospf instance
add name=IPv6 out-filter=OSPF-permit-only-configured_select router-id=\
    100.127.0.12 version=3
/routing ospf area
add area-id=0.0.0.0 instance=IPv6 name=area-0
/ip dhcp-client
add disabled=no interface=ether1
/ipv6 address
add address=2001:db8:126:2::2/126 advertise=no interface=ether1
add address=2001:db8:127::12/128 advertise=no interface=lo-ospf
add address=2001:db8:101::12/128 advertise=no interface=lo-bgp
add address=2001:db8:a1b::1 interface=ether4
add address=2001:db8:126:4::2/126 advertise=no interface=ether2
/routing bgp connection
add local.address=2001:db8:127::12 .role=ibgp-rr-client remote.address=\
    2001:db8:127::1 .as=8675309 template=ASN-8675309
/routing filter rule
add chain=OSPF-permit-only-configured
/routing filter select-rule
add chain=OSPF-permit-only-configured_select do-where=\
    OSPF-permit-only-configured
/routing ospf interface
add area=area-0 network=ether1 network-type=point-to-point
add area=area-0 network=lo-ospf network-type=broadcast
add area=area-0 network=ether2 network-type=point-to-point
/system identity
set name=PE-2

VxLAN support added in 7.0beta5

MikroTik announced VxLAN support on Valentine’s Day (Feb 14th) of 2020.

This is a significant feature addition for RouterOSv7 as it will pave the way for a number of other additions like EVPN in BGP.

It will also give MikroTik the ability to appeal to enterprises and data centers that might need cost-effective VxLAN capable devices.

Service Providers are also moving towards VxLAN as a future replacement for VPLS so this is helpful for that market as well.

Download the OVA here:
https://download.mikrotik.com/routeros/7.0beta5/chr-7.0beta5.ova

Implementation

The initial release of VxLAN is based on unicast and multicast to deliver Layer 2 frames.

As there is no EVPN support, the VTEPs must be manually configured for each endpoint in a full mesh configuration.

The VxLAN interface can then be bridged to a physical ethernet port or VLAN interface to deliver the traffic to the end host.

Lab Example

Here is an overview lab in EVE-NG with a basic setup using 3 linux servers on the same 10.1.1.0/24 subnet which is carried as an overlay by VxLAN.

VxLAN reachability for VTEPs is acheived with OSPFv2 and loopback addresses.

VNI: 100
Multicast Group: 239.0.0.1

Lab Validation

In the following packet capture, traffic to UDP port 8472 can be seen between two endpoints.

The ICMP ping test between server 1 (10.1.1.1) and server 2 (10.1.1.2) is also visible

Pings between Server 1 and Servers 2 & 3

Configurations

R1

/interface bridge
 add name=Bridge-VxLAN-VNI-100
 add name=Lo0
 /interface vxlan
 add group=239.0.0.1 interface=ether1 mtu=1400 name=VxLAN-VNI-100 port=8472 vni=100
 /routing ospf instance
 add name=ospf-instance-1 router-id=100.127.1.1 version=2
 /routing ospf area
 add area-id=0.0.0.0 instance=ospf-instance-1 name=ospf-area-1
 /interface bridge port
 add bridge=Bridge-VxLAN-VNI-100 interface=ether8
 add bridge=Bridge-VxLAN-VNI-100 interface=VxLAN-VNI-100
 /interface vxlan vteps
 add interface=VxLAN-VNI-100 remote-ip=100.127.1.2
 add interface=VxLAN-VNI-100 remote-ip=100.127.1.3
 /ip address
 add address=100.127.1.1 interface=Lo0 network=100.127.1.1
 add address=100.126.0.1/29 interface=ether1 network=100.126.0.0
 /routing ospf interface
 add area=ospf-area-1 instance-id=0 network=100.126.0.0/29
 add area=ospf-area-1 instance-id=0 network=100.127.1.1
 /system identity
 set name=MikroTik-R1

R2

/interface bridge
 add name=Bridge-VxLAN-VNI-100
 add name=Lo0
 /interface vxlan
 add group=239.0.0.1 interface=ether1 mtu=1400 name=VxLAN-VNI-100 port=8472    vni=100
 /routing ospf instance
 add name=ospf-instance-1 router-id=100.127.1.2 version=2
 /routing ospf area
 add area-id=0.0.0.0 instance=ospf-instance-1 name=ospf-area-1
 /interface bridge port
 add bridge=Bridge-VxLAN-VNI-100 interface=ether8
 add bridge=Bridge-VxLAN-VNI-100 interface=VxLAN-VNI-100
 /interface vxlan vteps
 add interface=VxLAN-VNI-100 remote-ip=100.127.1.1
 add interface=VxLAN-VNI-100 remote-ip=100.127.1.3
 /ip address
 add address=100.127.1.2 interface=Lo0 network=100.127.1.2
 add address=100.126.0.2/29 interface=ether1 network=100.126.0.0
 /routing ospf interface
 add area=ospf-area-1 instance-id=0 network=100.126.0.0/29
 add area=ospf-area-1 instance-id=0 network=100.127.1.2
 /system identity
 set name=MikroTik-R2

R3

 /interface bridge
 add name=Bridge-VxLAN-VNI-100
 add name=Lo0
 /interface vxlan
 add group=239.0.0.1 interface=ether1 mtu=1400 name=VxLAN-VNI-100 port=8472 
     vni=100
 /routing ospf instance
 add name=ospf-instance-1 router-id=100.127.1.3 version=2
 /routing ospf area
 add area-id=0.0.0.0 instance=ospf-instance-1 name=ospf-area-1
 /interface bridge port
 add bridge=Bridge-VxLAN-VNI-100 interface=ether8
 add bridge=Bridge-VxLAN-VNI-100 interface=VxLAN-VNI-100
 /interface vxlan vteps
 add interface=VxLAN-VNI-100 remote-ip=100.127.1.1
 add interface=VxLAN-VNI-100 remote-ip=100.127.1.2
 /ip address
 add address=100.127.1.3 interface=Lo0 network=100.127.1.3
 add address=100.126.0.3/29 interface=ether1 network=100.126.0.0
 /routing ospf interface
 add area=ospf-area-1 instance-id=0 network=100.126.0.0/29
 add area=ospf-area-1 instance-id=0 network=100.127.1.3
 /system identity
 set name=MikroTik-R3

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

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

[admin@MikroTik] > /interface bridge port add bridge=bridge1 interface=sfp-sfpplus1 pvid=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.

[admin@MikroTik] > /interface bridge vlan add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=200

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

[admin@MikroTik] >

/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=172.16.1.254/24 interface=vlan200 network=172.16.1.0

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.

[admin@MikroTik] > /interface bridge add fast-forward=no name=bridge1 priority=0 protocol-mode=mstp region-name=main vlan-filtering=yes

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)

[admin@MikroTik] > /interface bridge port set 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.

[admin@MikroTik] >
/interface bonding
add mode=802.3ad name=Po1 slaves=sfp-sfpplus1,sfp-sfpplus3 \
transmit-hash-policy=layer-2-and-3

/interface bridge vlan
add bridge=bridge1 tagged=Po1,bridge1 vlan-ids=200

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

[admin@IPA-LAB-CRS-317] > interface bridge host print
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external 
 #       MAC-ADDRESS        VID ON-INTERFACE      BRIDGE     AGE                 
 0   DL  64:D1:54:F0:0E:46      Po1               bridge1   
 1   DL  64:D1:54:F0:0E:47      sfp-sfpplus2      bridge1   
 2   D E 04:FE:7F:5C:5D:9C    1 Po1               bridge1   
 3   DL  64:D1:54:F0:0E:46    1 Po1               bridge1   
 4   D   00:0C:42:B2:A6:3D  200 sfp-sfpplus2      bridge1    52s                 
 5   D E 4C:5E:0C:23:DF:50  200 Po1               bridge1   
 6   DL  64:D1:54:F0:0E:46  200 bridge1           bridge1   
 7   DL  64:D1:54:F0:0E:47  200 sfp-sfpplus2      bridge1

View the MAC table for VLAN 200 in the switch

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

[admin@IPA-LAB-CRS-317] > interface bridge host print where vid=200
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external 
 #       MAC-ADDRESS        VID ON-INTERFACE           BRIDGE           AGE                 
 0   D   00:0C:42:B2:A6:3D  200 sfp-sfpplus2           bridge1          51s                 
 1   D E 4C:5E:0C:23:DF:50  200 Po1                    bridge1         
 2   DL  64:D1:54:F0:0E:46  200 bridge1                bridge1         
 3   DL  64:D1:54:F0:0E:47  200 sfp-sfpplus2           bridge1

View the MAC table for bonding interface Po1 in the switch

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

[admin@IPA-LAB-CRS-317] > interface bridge host print where interface=Po1         
Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external 
 #       MAC-ADDRESS        VID ON-INTERFACE           BRIDGE           AGE                 
 0   DL  64:D1:54:F0:0E:46      Po1                    bridge1         
 1   D E 04:FE:7F:5C:5D:9C    1 Po1                    bridge1         
 2   DL  64:D1:54:F0:0E:46    1 Po1                    bridge1         
 3   D E 4C:5E:0C:23:DF:50  200 Po1                    bridge1

View the current VLANs configured in the switch 

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

[admin@IPA-LAB-CRS-317] > interface bridge vlan print
Flags: X - disabled, D - dynamic 
 #   BRIDGE              VLAN-IDS  CURRENT-TAGGED              CURRENT-UNTAGGED             
 0   bridge1             200       bridge1                     sfp-sfpplus2                 
                                   Po1                        
 1 D bridge1             1                                     bridge1                      
                                                               Po1

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

[admin@IPA-LAB-CRS-317] >  interface bridge monitor
numbers: 0
                    state: enabled
      current-mac-address: 64:D1:54:F0:0E:46
              root-bridge: yes
           root-bridge-id: 0.64:D1:54:F0:0E:46
  regional-root-bridge-id: 0.64:D1:54:F0:0E:46
           root-path-cost: 0
                root-port: none
               port-count: 2
    designated-port-count: 2
        mst-config-digest: ac36177f50283cd4b83821d8ab26de62

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.

[admin@IPA-LAB-CRS-317] > interface bonding print detail
Flags: X - disabled, R - running 
 0  R name="Po1" mtu=1500 mac-address=64:D1:54:F0:0E:46 arp=enabled arp-timeout=auto 
      slaves=sfp-sfpplus1,sfp-sfpplus3 mode=802.3ad primary=none link-monitoring=mii 
      arp-interval=100ms arp-ip-targets="" mii-interval=100ms down-delay=0ms up-delay=0ms 
      lacp-rate=30secs transmit-hash-policy=layer-2-and-3 min-links=0

One of the hardest things to do quickly in network engineering, is learn a new syntax for a NOS. Especially if you have a tight deadline and need to stand up equipment you’ve never worked with before. The command structure for RouterOS can be cumbersome if you are used to the Cisco CLI.

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 routers.

This is the third post in a series that creates a Rosetta stone between IOS and RouterOS. We plan to tackle  other command comparisons like VLANs, QoS and basic operations to make it easier for network engineers trained in Cisco IOS to successfully implement Mikrotik / RouterOS devices.

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”

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.

Using  EVE-NG 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. Don’t get me wrong, I like GNS3, but the web interface of EVE-NG makes it really easy to keep all the horsepower for complex labs at a central location and then VPN in to work on labs as needed.

Network for Basic mpls commands

Examples of the MikroTik RouterOS commands from the table above

[admin@MikroTik] > mpls ldp neighbor print

This command will show LDP neighbors and detail on whether they are Dynamic, Targeted, Operational or using VPLS

[admin@MikroTik] > mpls ldp interface print

This command will list the interfaces that LDP is enabled on

[admin@MikroTik] > mpls forwarding-table print

Use this command to display the MPLS forwarding table which shows what labels are assigned, the interface used and the next hop.

[admin@MikroTik] > mpls remote-bindings print

This is a quick way to show remote bindings which displays the labels desired and used by the next hop routers for each prefix.

[admin@MikroTik] > mpls local-bindings print

This is a quick way to show local bindings which displays the labels desired and used by the local router – in this case R3.

[admin@MikroTik] > mpls print

This is a quick way to show basic mpls settings for RouterOS which includes the label range and whether or not to propagate TTL which affects what a traceroute looks like over an MPLS network.

[admin@MikroTik] > mpls ldp print

This is a quick way to show mpls ldp settings for Router-OS including whether or not LDP is enabled.

Configurations

R1

Cisco-R1#sh run
Building configuration...

Current configuration : 3062 bytes
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cisco-R1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
ethernet lmi ce
!
!
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 203.0.113.1 255.255.255.248
 duplex auto
 speed auto
 media-type rj45
 mpls ip
!
interface GigabitEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/2
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/3
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 10.1.1.1 0.0.0.0 area 0
 network 203.0.113.0 0.0.0.7 area 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
mpls ldp router-id Loopback0
!
control-plane
!
banner exec ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS  *
* education. IOSv is provided as-is and is not supported by Cisco's      *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any       *
* purposes is expressly prohibited except as otherwise authorized by     *
* Cisco in writing.                                                      *
**************************************************************************^C
banner incoming ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS  *
* education. IOSv is provided as-is and is not supported by Cisco's      *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any       *
* purposes is expressly prohibited except as otherwise authorized by     *
* Cisco in writing.                                                      *
**************************************************************************^C
banner login ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS  *
* education. IOSv is provided as-is and is not supported by Cisco's      *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any       *
* purposes is expressly prohibited except as otherwise authorized by     *
* Cisco in writing.                                                      *
**************************************************************************^C
!
line con 0
line aux 0
line vty 0 4
 login
 transport input none
!
no scheduler allocate
!
end

R2

Cisco-R2#sh run
Building configuration...

Current configuration : 3122 bytes
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Cisco-R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
ethernet lmi ce
!
!
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
!
!
!
!
!
!
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
 ip address 10.1.1.2 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.248
 duplex auto
 speed auto
 media-type rj45
 mpls ip
!
interface GigabitEthernet0/1
 ip address 203.0.113.9 255.255.255.248
 duplex auto
 speed auto
 media-type rj45
 mpls ip
!
interface GigabitEthernet0/2
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/3
 no ip address
 shutdown
 duplex auto
 speed auto
 media-type rj45
!
router ospf 1
 network 10.1.1.2 0.0.0.0 area 0
 network 203.0.113.0 0.0.0.7 area 0
 network 203.0.113.8 0.0.0.7 area 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
mpls ldp router-id Loopback0
!
control-plane
!
banner exec ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS  *
* education. IOSv is provided as-is and is not supported by Cisco's      *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any       *
* purposes is expressly prohibited except as otherwise authorized by     *
* Cisco in writing.                                                      *
**************************************************************************^C
banner incoming ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS  *
* education. IOSv is provided as-is and is not supported by Cisco's      *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any       *
* purposes is expressly prohibited except as otherwise authorized by     *
* Cisco in writing.                                                      *
**************************************************************************^C
banner login ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS  *
* education. IOSv is provided as-is and is not supported by Cisco's      *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any       *
* purposes is expressly prohibited except as otherwise authorized by     *
* Cisco in writing.                                                      *
**************************************************************************^C
!
line con 0
line aux 0
line vty 0 4
 login
 transport input none
!
no scheduler allocate
!
end

R3

[admin@MikroTik-R3] > export
# may/03/2018 16:34:51 by RouterOS 6.38.7
# software id =
#
/interface bridge
add name=Loopback0
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=203.0.113.10/29 interface=ether1 network=203.0.113.8
add address=10.1.1.3 interface=Loopback0 network=10.1.1.3
add address=203.0.113.17/29 interface=ether2 network=203.0.113.16
/ip dhcp-client
add disabled=no interface=ether1
/mpls ldp
set enabled=yes lsr-id=10.1.1.3
/mpls ldp interface
add interface=ether1
add interface=ether2
/routing ospf network
add area=backbone network=203.0.113.8/29
add area=backbone network=10.1.1.3/32
add area=backbone network=203.0.113.16/29
/system identity
set name=MikroTik-R3

R4

[admin@MikroTik-R4] > export
# may/03/2018 16:35:28 by RouterOS 6.38.7
# software id =
#
/interface bridge
add name=Loopback0
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip address
add address=203.0.113.18/29 interface=ether1 network=203.0.113.16
add address=10.1.1.4 interface=Loopback0 network=10.1.1.4
/ip dhcp-client
add disabled=no interface=ether1
/mpls ldp
set enabled=yes lsr-id=10.1.1.4
/mpls ldp interface
add interface=ether1
/routing ospf network
add area=backbone network=203.0.113.16/29
add area=backbone network=10.1.1.4/32
/system identity
set name=MikroTik-R4

Virtual Private LAN Service or VPLS is a Layer 2 overlay or tunnel that allows for the encapsulation of ethernet frames (with or without VLAN tags) over an MPLS network.

https://tools.ietf.org/html/rfc4762

VPLS is often found in Telco networks that rely on PPPoE to create centralized BRAS deployments by bringing all of the end users to a common point via L2.

MikroTik VPLS example (https://wiki.mikrotik.com/wiki/Transparently_Bridge_two_Networks_using_MPLS)

Background

The idea for this post came out of a working session (at the bar of course) at WISPAmerica 2018 in Birmingham, Alabama.

There was a discussion about how to create redundancy for VPLS tunnels on multiple routers. I started working on this in EVE-NG as we were talking about it.

The goal is creating highly available endpoints for VPLS when using them to deploy a public subnet that can be delivered to any tower in the WISP. The same idea works for wireline networks as well.

Use Case

As IPv4 becomes harder to get, ISPs like WISPs, without large blocks of public space find it difficult to deploy them in smaller subnets. The idea behind breaking up a /23 or /24 for example, is that every tower has public IP addresses available.

However, the problem with this approach is that some subnets may not be used if there isn’t much demand for a dedicated public IP by customers.

What makes VPLS attractive in this scenario is that the public subnet (a /24 in this example) can be placed at the data center as an intact prefix.

VPLS tunnels then allow for individual IP addresses to exist at any tower in the network which provides flexibility and conserves IPv4 space by not subnetting the block into /29 /28 /27 at the tower level.

Lab Network

Deployment

In this lab, the VPLS tunnels terminate in two different data centers as well as at a tower router to create an L2 segment for 203.0.113.0/24. VRRP is then run between the two data center VPLS routers so that the gateway of 203.0.113.1 can failover to the other DC if needed.

Failover

Here is an example of the convergence time when we manually fail R1 and the gateway flips over to R2 in the other DC. The yellow highlight marks the point where R1 has failed and R2 VRRP has become master.

Configurations

R1-vpls-agg

/interface bridge
add name=Lo0
add name=vpls1-1
/interface vrrp
add interface=vpls1-1 name=vpls1-1-vrrp priority=200
/interface vpls
add disabled=no l2mtu=1500 mac-address=02:2C:0B:61:64:CB name=vpls1 remote-peer=1.1.1.2 vpls-id=1:1
add disabled=no l2mtu=1500 mac-address=02:7C:8C:C9:CE:8E name=vpls2 remote-peer=1.1.1.3 vpls-id=1:1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=vpls1-1 interface=vpls1
add bridge=vpls1-1 interface=vpls2
/ip address
add address=1.1.1.1 interface=Lo0 network=1.1.1.1
add address=10.1.1.1/24 interface=ether1 network=10.1.1.0
add address=203.0.113.2/24 interface=vpls1-1 network=203.0.113.0
add address=203.0.113.1/24 interface=vpls1-1-vrrp network=203.0.113.0
/ip dhcp-client
add disabled=no interface=ether1
/mpls ldp
set enabled=yes lsr-id=1.1.1.1 transport-address=1.1.1.1
/mpls ldp interface
add interface=ether1
/routing ospf network
add area=backbone network=10.1.1.0/24
add area=backbone network=1.1.1.1/32
/system identity
set name=R1-vpls-agg

R2-vpls-agg

/interface bridge
add name=Lo0
add name=vpls1-1
/interface vrrp
add interface=vpls1-1 name=vpls1-1-vrrp
/interface vpls
add disabled=no l2mtu=1500 mac-address=02:C3:4C:31:FB:C9 name=vpls1 remote-peer=1.1.1.1 vpls-id=1:1
add disabled=no l2mtu=1500 mac-address=02:02:34:C0:A3:3C name=vpls2 remote-peer=1.1.1.3 vpls-id=1:1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=vpls1-1 interface=vpls1
add bridge=vpls1-1 interface=vpls2
/ip address
add address=10.1.1.2/24 interface=ether1 network=10.1.1.0
add address=1.1.1.2 interface=Lo0 network=1.1.1.2
add address=203.0.113.3/24 interface=vpls1-1 network=203.0.113.0
add address=203.0.113.1/24 interface=vpls1-1-vrrp network=203.0.113.0
/ip dhcp-client
add disabled=no interface=ether1
/mpls ldp
set enabled=yes lsr-id=1.1.1.2 transport-address=1.1.1.2
/mpls ldp interface
add interface=ether1
/routing ospf network
add area=backbone network=10.1.1.0/24
add area=backbone network=1.1.1.2/32
/system identity
set name=R2-vpls-agg

R3-Tower-1

/interface bridge
add name=Lo0
add name=vpls-1-1
/interface vpls
add disabled=no l2mtu=1500 mac-address=02:CB:47:7A:92:0B name=vpls1 remote-peer=1.1.1.1 vpls-id=1:1
add disabled=no l2mtu=1500 mac-address=02:E3:C5:5B:EC:BF name=vpls2 remote-peer=1.1.1.2 vpls-id=1:1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=vpls-1-1 interface=ether1
add bridge=vpls-1-1 interface=vpls1
add bridge=vpls-1-1 interface=vpls2
/ip address
add address=10.1.1.3/24 interface=ether2 network=10.1.1.0
add address=1.1.1.3 interface=Lo0 network=1.1.1.3
/ip dhcp-client
add disabled=no interface=ether1
/mpls ldp
set enabled=yes lsr-id=1.1.1.3 transport-address=1.1.1.3
/mpls ldp interface
add interface=ether2
/routing ospf network
add area=backbone network=10.1.1.0/24
add area=backbone network=1.1.1.3/32
/system identity
set name=R3-tower-vpls

If you’ve been in networking for a while, there’s a good chance you started with Cisco gear and so it is helpful to draw comparisons between the commands, especially if you are trying to build a network with a MikroTik and Cisco router.

This is the second post in a series that creates a Rosetta stone essentially between IOS and RouterOS. We plan to tackle  other command comparisons like MPLS, VLANs and basic operations to make it easier for network engineers trained in Cisco IOS to successfully implement Mikrotik / RouterOS devices.

Click here for the first article in this series – “Cisco to MikroTik BGP 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.

Using  EVE-NG for testing

In the last article, we used GNS3 to emulate both Cisco IOS and RouterOS so we could compare the different commands and ensure the translation was as close as possible. For this article, we decided to use EVE-NG as it’s becoming more and more popular for network emulation.

Network for Basic commands

Cisco command	MikroTik Command
show ip ospf neighbor	routing ospf neighbor print
show ip ospf interface	routing ospf interface print
show ip ospf 1	routing ospf instance print detail
show ip ospf database	routing ospf lsa print
show ip route ospf	ip route print where ospf=yes
show ip ospf rib	routing ospf route print
show ip ospf border-routers	routing ospf area-border-router print
show ip ospf border-routers	routing ospf as-border-router print
Cisco(config)#router ospf 1	/routing ospf instance
Cisco(config-router)#router-id 203.0.113.1	/routing ospf instance set 0 router-id=203.0.113.2
Cisco(config-router)#network 203.0.113.1 0.0.0.0 area 0	/routing ospf network add area=backbone network=203.0.113.2/32
Cisco(config-router)#network 203.0.113.128 0.0.0.7 area 0	/routing ospf network add area=backbone network=203.0.113.128/29
Cisco(config-router)#interface GigabitEthernet0/0 Cisco(config-if)# ip ospf network point-to-point Cisco(config-if)# ip ospf dead-interval 4 Cisco(config-if)# ip ospf hello-interval 1	/routing ospf interface add dead-interval=4s hello-interval=1s interface=ether1 network-type=point-to-point

Examples of the MikroTik RouterOS commands from the table above

[admin@MikroTik] > routing ospf neighbor print

This is a quick way to show all the OSPF neighbors the router is adjacent to.

[admin@MikroTik] > routing ospf interface print

This command lists all of the interfaces configured for OSPF, costs, authentication and whether or not the interface is passive. Unlike Cisco, MikroTik’s default behavior is to dynamically create an OPSF interface when a network statement is added which is what the ‘D’ flag stands for.

[admin@MikroTik] > routing ospf instance print detail

This command lists the details for all OSPF instances on the router including: router-id, redistribution settings, default metrics and filters applied in and out.

[admin@MikroTik] > routing ospf lsa print

This command lists all OPSF LSAs along with sequence number, originator and age.

[admin@MikroTik] > ip route print where ospf=yes

This command allows you to list all of the OSPF routes in the routing table. Unlike Cisco, RouterOS will list routes that aren’t active in the routing table instead of just in the RIB like Cisco.

[admin@MikroTik] > routing ospf route print

This is a quick way to show the routes that OSPF is aware of on the router, the state of the route, cost and the gateway/interface.

[admin@MikroTik] > routing ospf area-border-router print

Using this command will print all of the ABRs and areas the router is aware of.

[admin@MikroTik] > routing ospf as-border-router print

This command will list all ASBRs for the router.

[admin@MikroTik] > routing ospf export

Here is an example of a basic MikroTik OSPF config with a few options turned on like a standard area defined as well as redistribution of connected routes.

More Cisco to MikroTik articles are on the way!

This article covers most of the common OSPF commands. Some of the more advanced config and commands including OSPF flitering, Virtual and Sham Links will be tackled in a separate article. MPLS and VLANs are also on the list. Stay tuned for more!