Route Filtering

Filter Syntax

The routing filter rule implements script-like syntax. The example below is a quick demonstration of a routing filter that matches prefixes with a prefix length greater than 24 from subnet 192.168.1.0/24 and increments the default distance by 1. If there is no match then subtract 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}"

Filter rule may consist of multiple matchers and actions:

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

There are two types of properties:

• only readable - ones that value is only readable and cannot be rewritten, these properties can be used only by matchers
• readable/writable - ones that value is readable and writeable, used by filter actions, and also can be used by matchers

Readable properties can be matched by other readable properties (for numeric properties only) or constant values using boolean operators. 

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

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

The boolean operator is not used if there is only one possible operation.

Example without boolean operator:

if ( protocol connected ) { accept }

Example with boolean operator:

if ( bgp-med < 30 ) { accept }

With readable flag properties, matcher is used without specified boolean operator and without value

if ( ospf-dn ) { reject }

Only Readable Properties

Writeable Properties

Commands

Operators

Matcher Operators

Num Prop Operators

Prefix Operators

BGP Community Operators

String Operators

Deleting BGP Communities

Routing filters allow to clear BGP communities by using "delete" command. Delete command accepts several parameters based on the type of the community type:

• 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 SSO 
  • "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 SSOs, other type 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 sso,other,myRTList;"

AS-PATH Regexp Matching

AS Path is the sequence of autonomous system numbers (ASNs), for example AS Path 123 456 789 would indicate, that route originated from AS with the number 789, and to reach the destination, the packet would need to travel through two autonomous systems: 456 and 789. To apply specific routing policies administrator might want to match specific AS numbers or set of numbers in the AS Path (for example, reject prefixes that travel through AS 456), which can be achieved using regular expression (regexp).

There are two common ways how to operate with AS Path data:

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

Basically, the first method is performing the match per character, the second method is performing the match per whole AS number. As you would imagine the latter method is much faster and less resource-intensive than the string matching approach.

This change would require administrators to implement new Regex strategies. Old Regex patterns from RouterOS v6 cannot be directly copied/pasted as they will result either in syntax errors or unexpected results.

Let us take a very basic AS Path filter rule.

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

In ROS v7 this Regex pattern will match ASN 1234 anywhere in the middle of the AS-path, the same pattern in ROS v6 would match any AS path that contains ASN consisting of at least 6 characters and contains a string of "1234".  Obviously, if we directly copy/paste the Regex pattern from one implementation to another it will lead to unexpected/dangerous results. An equivalent pattern in ROS v6 would look something like this: "._1234_.".

Let's take another example from ROS v6, say we have a pattern "1234[5-9]" what it does is it matches 12345 to 12349 anywhere in the string, which means that valid matches are AS-path "12345 3434", "11 9123467 22" and so on. If you enter the same pattern in ROS v7 it will match AS path containing exact ASN 1234 followed by ASN in a range from 5 to 9 (matching AS-paths would be "1234 7 111", "111 1234 5 222" etc., it will not match "12345 3434").

Regex Testing Tool

RouterOS now has a built-in regex checking tool to simplify the hard life of the administrators. This tool supports also num-list so now exact regex can be tested against any as-path before applying it to the 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

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 define also 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;}"

/routing/filter/community-list

/routing/filter/community-ext-list

/routing/filter/community-large-list

Route Selection

Route selection rules allow controlling how output routes are selected from available candidate routes. By default, (if no selection rules are set) output always picks the best route.

For example, if we look at the routing table below, we can see that there are 2 candidate routes and one best route. By default when BGP selects which route to send out, it will pick 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

But there might be cases where you would want preference for other routes, not the active ones, and here come in-play selection rules.

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

Select rules can also call routing filters where routes get selected based on filter rules. For example, to mimic default output selection we can set up the following rule sets:

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

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

Property Reference

/routing/filter/chain

Dynamic list of filter rule chains that can be referenced in BGP/OSPF configuration.

Read-only properties:

/routing/filter/select-chain

Dynamic list of filter select chains that can be referenced in BGP/OSPF configuration.

Read-only properties: