MikroTik – RouterOSv7 first look – feedback on routing filters

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.

https://forum.mikrotik.com/viewtopic.php?f=1&t=175201#p867750


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


http://iparchitechs.com/contact



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.

FRRouting · GitHub

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 ###!

File:Juniper Networks logo.svg - Wikimedia Commons

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 Systems - Wikipedia

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

MikroTik – RouterOSv7 first look – MLAG on CRS 3xx switches

What is MLAG?

Multi-Chassis Link Aggregation Group or MLAG is an idea that’s been around for a while.

It allows for the ability to form LACP channels across multiple physical switches.

Wikipedia shows a few different topology examples here


Vendor implementations are proprietary but the idea of MLAG was first mentioned in 802.1AX-2008 in 2008.

It first started to become popular in data center networking in the late 2000s

What makes the addition of MLAG to MikroTik’s RouterOS feature set notable is that it lowers the barrier to entry for this particular feature.

CRS 3xx switches are very inexpensive (starting at $149 USD) and may very well be the lowest cost MLAG capable hardware available on the market.

Contact Us | IP ArchiTechs | Network Consulting Firm


Introduced in 7.1beta6

MLAG has been asked for by the MikroTik community a number of times and the most active feature request thread started here in 2020:

new feature request MLAG!!! – MikroTik

MikroTik added several version 7 beta releases in 2021 and included MLAG for all CRS 3xx series switches in 7.1beta6 on May 18th, 2021.

Overview of protocol requirements

MLAG is fairly consistent across vendors with the need for a link between physical devices that manages the MLAG groups. In MikroTik, these are called peer ports which facilitate the ICCP.

Here are a few terms for MikroTik MLAG:

ICCP (Inter Chassis Control Protocol). – Responsible for determining active/secondary switches and maintaining and updating the bridge table between physical switches.

Peer port – An interface that will be used as a peer port. Both peer devices use inter-chassis communication over the peer ports to establish MLAG and update the host table. The Peer port should be isolated on a different untagged VLAN using a pvid setting. The Peer port can be configured as a bonding interface.

System-id – The lowest MAC address between both peer bridges will be used as the system-id. This system-id is used for (R)STP bridge identifier.

Active-role – The peer with the lowest bridge MAC address will be acting as a primary device. The primary device is responsible for sending the correct LACP system ID on all MLAG ports.

mlag-id – An integer from 0 to 4294967295, it is used to set the MLAG ID for bonding interfaces. The same MLAG ID should be used on both peer devices to successfully create a single MLAG.

MikroTik’s requirements for ICCP and MLAG are:

  • RouterOS ICCP does not require an IP configuration
  • It should be isolated from the rest of the network using a dedicated untagged VLAN
  • Peer ports can also be configured as LACP bonding interfaces
  • MLAG requires enabled STP or RSTP protocol.


In order to present a single MAC address for the L2 spanning tree topology, ICCP functions on top of the peer ports to manage the MLAG/LACP system-id.

The system-id is used as the MAC address presented to the LACP client for RSTP/MSTP bridge identification.

reference for images and MLAG definitions: Multi-chassis Link Aggregation Group – RouterOS – MikroTik Documentation


Lab Example

In order to test the new MLAG functionality, we decided to setup a lab with CRS326-24S+2Q switches and CCR2004-1G-12S+2XS routers.

Below is the lab physical and logical topology.

Configuring an MLAG Group

Configure Bond and MLAG ID on CSW-01

/interface bonding
add mlag-id=100 mode=802.3ad name=Po1 slaves=sfp-sfpplus1


Configure Bond and MLAG ID on CSW-02

/interface bonding
add mlag-id=100 mode=802.3ad name=Po1 slaves=sfp-sfpplus1


* Apply each configuration step below on both switches to complete mlag setup and mlag-id 100. *


Configure the bridge and enable VLAN filtering. Add MLAG bonded interfaces and peer port to the bridge.

/interface bridge
add name=Bridge-MLAG vlan-filtering=yes
/interface bridge port
add bridge=Bridge-MLAG interface=Po1
add bridge=Bridge-MLAG interface=qsfpplus1-1 pvid=777


Configure a VLAN to be used over the MLAG

/interface bridge vlan
add bridge=Bridge-MLAG tagged=Po1 vlan-ids=3000


Set the peer port

/interface bridge mlag
set bridge=Bridge-MLAG peer-port=qsfpplus1-1


Validate the MLAG group


Show the status of the MLAG group, active and secondary ports and verify the system-id the client LACP receives

######## MLAG Switches - 2 x CRS326 ############

[[email protected]] > interface/bridge/mlag/monitor 
       status: connected
    system-id: 48:8F:5A:3A:44:BA
  active-role: primary

[[email protected]] > interface/bridge/mlag/monitor                        
       status: connected
    system-id: 48:8F:5A:3A:44:BA
  active-role: secondary

######## NON-MLAG LACP Router ############

[[email protected]] > /interface bonding monitor Po1
                    mode: 802.3ad
            active-ports: sfp-sfpplus3,sfp-sfpplus4
          inactive-ports: 
          lacp-system-id: 48:8F:5A:00:4F:80
    lacp-system-priority: 65535
  lacp-partner-system-id: 48:8F:5A:3A:44:BA


Configurations

RTR-01

/interface bridge
add name=Lo0
/interface bonding
add mode=802.3ad name=Po1 slaves=sfp-sfpplus3,sfp-sfpplus4 transmit-hash-policy=layer-2-and-3
/interface vlan
add interface=Po1 name=vlan3000 vlan-id=3000
/routing table
add fib name=""
/ip address
add address=100.126.0.1/29 interface=vlan3000 network=100.126.0.0
add address=100.127.0.1 interface=Lo0 network=100.127.0.1
/ipv6 address
add address=200:100:126::1 interface=vlan3000
add address=200:100:127::1/128 advertise=no interface=Lo0
/system identity
set name=RTR-01

RTR-02

/interface bridge
add name=Lo0
/interface bonding
add mode=802.3ad name=Po1 slaves=sfp-sfpplus3,sfp-sfpplus4 transmit-hash-policy=layer-2-and-3
/interface vlan
add interface=Po1 name=vlan3000 vlan-id=3000
/routing table
add fib name=""
/ip address
add address=100.126.0.2/29 interface=vlan3000 network=100.126.0.0
add address=100.127.0.2 interface=Lo0 network=100.127.0.2
/ipv6 address
add address=200:100:126::2 interface=vlan3000
add address=200:100:127::2/128 advertise=no interface=Lo0
/system identity
set name=RTR-02

CSW-01

/interface bridge
add name=Bridge-MLAG vlan-filtering=yes
/interface bonding
add mlag-id=100 mode=802.3ad name=Po1 slaves=sfp-sfpplus1
add mlag-id=101 mode=802.3ad name=Po2 slaves=sfp-sfpplus2
/interface bridge mlag
set bridge=Bridge-MLAG peer-port=qsfpplus1-1
/interface bridge port
add bridge=Bridge-MLAG interface=Po1
add bridge=Bridge-MLAG interface=qsfpplus1-1 pvid=777
add bridge=Bridge-MLAG interface=Po2
/interface bridge vlan
add bridge=Bridge-MLAG tagged=Po1,Po2 vlan-ids=3000
/system identity
set name=CSW-01

CSW-02

/interface bridge
add name=Bridge-MLAG vlan-filtering=yes
/interface bonding
add mlag-id=100 mode=802.3ad name=Po1 slaves=sfp-sfpplus1
add mlag-id=101 mode=802.3ad name=Po2 slaves=sfp-sfpplus2
/interface bridge mlag
set bridge=Bridge-MLAG peer-port=qsfpplus1-1
/interface bridge port
add bridge=Bridge-MLAG interface=Po1
add bridge=Bridge-MLAG interface=qsfpplus1-1 pvid=777
add bridge=Bridge-MLAG interface=Po2
/interface bridge vlan
add bridge=Bridge-MLAG tagged=Po1,Po2 vlan-ids=3000
/system identity
set name=CSW-02