Route Selection and Filtering

Route Filtering

Filter Syntax

Routing filter rules use script-like syntax. The following example matches prefixes from subnet 192.168.1.0/24 with a prefix length greater than 24 and increments the default distance by 1. If there is no match, it subtracts the default distance by one.

/routing/filter/rule
  add chain=myChain \
  rule="if (dst in 192.168.1.0/24 && dst-len>24) {set distance +1; accept} else {set distance -1; accept}"

A filter rule may consist of multiple matchers and actions:

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

There are two types of properties:

• Only readable — properties whose values are read-only and cannot be rewritten. They can be used only by matchers.
• Readable/writable — properties whose values are readable and writable. They can be used by filter actions and by matchers.

For numeric properties only, readable properties can be matched by other readable properties or by constant values with boolean operators.

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

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

You do not need a boolean operator if the matcher has only one possible operation.

Example without a boolean operator:

if ( protocol connected ) { accept }

Example with boolean operator:

if ( bgp-med < 30 ) { accept }

With readable flag properties, the matcher does not require a boolean operator or a value.

if ( ospf-dn ) { reject }

Info The default action of the routing filter chain is reject.

Only Readable Properties

Writeable Properties

Commands

Operators

Matcher Operators

Num Prop Operators

Prefix Operators

Info Address lists by design are matching host addresses which means that it will match also /32 prefix that belongs to any range from the address list. The workaround to exclude /32 prefixes from being advertised is to use dst-len if (dst in list_name && dst-len < 32) {}

BGP Community Operators

String Operators

Deleting BGP Communities

Routing filters allow clearing BGP communities by using the delete command. The delete command accepts several parameters based on the type of community:

• communities:
  • wk - Will match and remove well-known communities.
  • other - Will match and remove other communities that are not well known.
  • regexp - regexp pattern to match communities that should be deleted.
  • <community-list name> - Deletes communities from specified community-list.
• ext-communities:
  • rt - Will match and remove RouteTarget.
  • soo - Will match and remove Site-of-Origin.
  • other - Will match and remove other ext communities that are not RT or SOO.
  • regexp - regexp pattern to match ext communities that should be deleted.
  • <community-ext-list name> - Deletes communities from specified community-ext-list.
• large-communities:
  • all - Removes everything.
  • regexp - regexp pattern to match large communities that should be deleted.
  • <community-large-list name> - Deletes large communities from specified community-large-list.

It is possible to specify multiple community types, for example delete all SOOs, other types of ext communities and specific RTs from the community-ext list:

/routing/filter/community-ext-list
add list=myRTList communities="rt:1.1.1.1:222"
/routing/filter/rule
add chain=myChain rule="delete bgp-ext-communities soo,other,myRTList;"

AS-PATH Regexp Matching

An AS path is the sequence of autonomous system numbers (ASNs). For example, the AS path 123 456 789 means the route originated from AS 789 and traversed AS 456 before reaching the destination. To apply routing policies, match specific AS numbers or sets of AS numbers in the AS path by using a regular expression (regexp).

There are two common ways to work with AS path data:

• Convert the whole AS path to a string and let regexp operate on the string (ROS v6 or Cisco style).
• Let regexp operate on each AS path entry as a number (ROS v7, Juniper style).

The first method matches per character. The second method matches per AS number. The second method is faster and uses fewer resources than the string matching approach.

This change requires administrators to use new regexp strategies. Old regexp patterns from RouterOS v6 cannot be copied and pasted directly because they can cause syntax errors or unexpected results.

Take this basic AS path filter rule:

/routing/filter/rule
add chain=myChain rule="if (bgp-as-path .1234.) {accept}"

This regexp pattern matches ASN 1234 anywhere in the middle of the AS path. With old style string matching method, the same pattern matches any AS path that contains an ASN with at least six characters and the substring 1234. An equivalent old style pattern is ._1234_..

For example, the old string style pattern 1234[5-9] matches 12345 through 12349 anywhere in the string. That yields matches such as 12345 3434 and 11 9123467 22. With new style matcher, the same pattern matches an AS path containing the exact ASN 1234 followed by an ASN from 5 to 9, such as 1234 7 111 or 111 1234 5 222. It does not match 12345 3434.

Danger Copying regexp patterns between implementations can produce unexpected or dangerous results.

Do not copy Regex patterns directly from ROS v6 or Cisco configurations, they are not directly compatible. It can lead to unexpected or even dangerous configurations in some scenarios.

Info The AS-Path parameter must exist for the regexp matcher to be applied. This means that it is not possible to match a non-existent (empty) AS-Path with a regular expression, aka ^$. bgp-path-len should be used instead.

Regex Testing Tool

RouterOS has a built-in regexp checking tool to help administrators validate regexps. This tool also supports num-list values so you can test a regexp against any AS path before applying it to routing filters.

/routing/filter/num-list/add list=test range=100-1500

/routing/filter/test-as-path-regexp regexp="[[:test:]]5678\$" as-path="1234,5678"

Supported Operators

Warning Repetition ranges {} are not supported.

Community and Num Lists

A list of commonly used numbers can be configured from the /routing/filter/num-list menu. These lists of numbers can be used in the filter rules to simplify the filter setup process.

In a similar manner, you are allowed to also define community, extended community, and large community lists. Community sets can be used for matching, appending, and setting.

For example, match communities from the list and clear the attribute:

/routing/filter/community-list
add communities=111:222 list=myCommunityList

/routing/filter/rule
add chain=myChain rule="if (bgp-communities equal-list myCommunityList) {delete bgp-communities wk,other; accept;}"

Route Selection

Route selection rules control how output routes are selected from available candidate routes. By default, if no selection rules are set, output selects the best route.

The following routing table shows two candidate routes and one best route. By default, when BGP selects a route to send out, it chooses the active route.

[admin@4] /routing/route> print where dst-address=1.0.0.0/24
Flags: A - ACTIVE; b, y - COPY
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
   DST-ADDRESS  GATEWAY         AFI  DISTANCE  SCOPE  TARGET-SCOPE  IMMEDIATE-GW
 b 1.0.0.0/24   10.155.101.217  ip4        19     40            30  10.155.109.254%ether1
Ab 1.0.0.0/24   10.155.101.232  ip4        20     40            30  10.155.109.254%ether1
 b 1.0.0.0/24   10.155.101.231  ip4        20     40            30  10.155.109.254%ether1

If you need a preference for routes that are not active, use selection rules.

Selection rules in RouterOS are configured from the /routing/filter/select-rule menu.

Select rules can also call routing filters so routes are selected by filter rules. For example, to mimic the default output selection, use this rule set:

/routing/filter/rule
add chain=get_active rule="if (active) {accept}"

/routing/filter/select-rule
add chain=my_select_chain do-where=get_active

Select rules can be also used to limit how many additional paths to pick for BGP Add-path, for example max 3 paths:

/routing/filter/select-rule add chain=select-for-addpath do-take=3

Routing Filter Wizard

Because writing filter rules in script-like syntax is more complex, routing filter wizard that generates filter rules with ROSv6-like syntax was introduced.

Quick demonstration:

[admin@CCR2004_2XS_111] /routing/filter> filter-wizard <tab>
action        dst                   ospf-type         scope-target      set-gw-check                use-te-nexthop
afi           dst-len               protocol          set-bgp-...       set-scope
bgp-...       gateway               routing-table     set-blackhole     set-scope-target
blackhole     jump-target-chain     rpki              set-comment       set-suppress-hw-offload
chain         match-chain           rpki-verify       set-distance      set-use-te-nexthop
distance      ospf-metric           scope             set-gateway       suppress-hw-offload

[admin@CCR2004_2XS_111] /routing/filter> filter-wizard action=accept chain=vpn-in afi=vpnv4 set-bgp-ext-communities=rt:2:2
  result: Filter rule 'if (afi vpnv4) { set bgp-ext-communities rt:2:2; accept; }' added

[admin@CCR2004_2XS_111] /routing/filter> /routing/filter/rule/print
Flags: X - disabled, I - inactive
 0   ;;; added by filter-wizard
     chain=vpn-in rule="if (afi vpnv4) { set bgp-ext-communities rt:2:2; accept; }"

The filter wizard adds rules at the end of the list and gives them the comment added by filter-wizard.

Errors returned when you try to add a filter with unacceptable values are printed in the CLI and logged in the system log with the route,error topic.

[admin@CCR2004_2XS_111] /routing/filter> filter-wizard action=accept chain=vpn-in afi=vpnv4 match-chain=vpn-in
  result: Error adding 'if (chain vpn-in && afi vpnv4) { accept; }'match with 'vpn-in' creates chain loop (6)

[admin@CCR2004_2XS_111] /routing/filter> /log/print
 2025-05-19 13:05:15 route,error Error adding 'if (chain vpn-in && afi vpnv4) { accept; }'match with 'vpn-in' creates chain loop (6)