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

Juniper to MikroTik – BGP commands

About the Juniper to MikroTik series

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 CommandMikroTik Command
show bgp summaryrouting bgp peer print brief
show bgp neighborrouting bgp peer print status
show route advertising-protocol bgp 172.31.254.2routing bgp advertisements print peer=peer_name
show route receive-protocol bgp 172.31.254.2ip route print where received-from=peer_name
show route protocol bgpip route print where bgp=yes
clear bgp neighbor 172.31.254.2 soft-inboundrouting bgp peer refresh peer_name
clear bgp neighbor 172.31.254.2 softrouting 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


https://iparchitechs.com/contact

Examples of the commands above


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

[[email protected]] > routing bgp peer print brief

[email protected]> 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. 

[[email protected]] > routing bgp peer print status

[email protected]> 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. 

[[email protected]] > routing bgp advertisements print peer=PEER-1

[email protected]> 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. 

[[email protected]] > ip route print where received-from=PEER-1

[email protected]> 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. 

[[email protected]] > ip route print where bgp=yes

[email protected]> 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.