By default, all routes are added to the "main" routing table as it was before. From a configuration point of view, the biggest differences are routing table limit increase, routing table monitoring differences, and how routes are added to specific routing tables (see next example)
v7 introduces a new menu /routing route, which shows all address family routes as well as all filtered routes with all possible route attributes.
/ip route and
/ipv6 route menus are used to add static routes and for simplicity shows only basic route attributes.
For more in-depth information on routing see this article (How Packets Are Routed).
Another new change is that most common route print requests are processed by the routing process which significantly improves the speed compared to v6.
The main difference from v6 is that the routing table must be added in
/routing table menu before actually referencing it anywhere in the configuration. And fib parameter should be specified if the routing table is intended to push routes to the FIB.
Routing rule configuration is the same except the menu location (instead of
/ip route rule, now it is
Let's consider a basic example where we want to resolve 18.104.22.168 only in the routing table named myTable to the gateway 172.16.1.1:
Instead of routing rules, you could use mangle to mark packets with routing-mark, the same way as it was in ROSv6.
OSPFv3 and OSPFv2 is now merged into one single menu
/routing ospf. At the time of writing this article, there is no default instances and areas.
To start both OSPFv2 and OSPF v3 instances, first, you need to create an instance for each and then add an area to the instance.
At this point, you are ready to start OSPF on the network interface. In the case of IPv6, you add either interface on which you want to run OSPF (the same as ROSv6) or IPv6 network. In the second case, OSPF will automatically detect the interface. Here are some interface configuration examples:
Another big difference is that
neighbor menus are purely for configuration, to monitor adjacent neighbors or interface status there are two new menu
All route distribution control is now done purely with routing filter select, no more redistribution knobs in the instance. This gives greater flexibility on what routes from which protocols you want to redistribute.
For example, let's say you want to redistribute only static IPv4 routes from the 192.168.0.0/16 network range.
If the routing filter chain is not specified OSPF will try to advertise every active route it can find in the routing table
The default action of the routing filter chain is "drop"
There is a complete redesign of the BGP configuration compared to ROSv6. The first biggest difference is that there is no more
peer configuration menus. Instead, we have
The reason for such structure is to strictly split parameters that are responsible for connection and change of these parameters requires immediate connection termination and parameters that do not tear existing connection when changed.
Let's start with the Template. It contains all BGP protocol related configuration options. It can be used as a template for dynamic peers and apply a similar config to a group of peers. Note that this is not the same as peer groups on Cisco devices, where the group is more than just a common configuration.
By default, there is a default template that requires you to set your own AS.
Starting from v7.1beta4 template parameters are exposed in "connecrtion" configuration. Which means that template is not mandatory anymore, allowing for easier basic BGP connection setup, similar as it was in ROSv6.
Most of the parameters are similar to ROSv6 except that some are grouped in the output and input section. If you are familiar with capsman then the syntax is the same, for example, to specify output selection chain you set
You can even inherit template parameters from another template, for example:
output.filter should be the selection chain, see the OSPF example.
Another important aspect of the new routing configuration is Routing Instance, which sets router-id and group peers in one instance. RouterOS adds a default instance which picks instance-id from any interface highest IP. The default BGP template by default is set to use the "default" instance.
If for any reason you need to tweak or add new instances it can be done in
/routing instance menu.
Very interesting parameters are
output.affinity, they allow to control in which process input and output of active session will be processed:
Now that we have parameters set for the template we can add BGP connections. A minimal set of parameters are
Connect and listen to parameters specify whether peers will try to connect and listen to a remote address or just connect or just listen. It is possible that in setups where peer uses the multi-hop connection
local.address must be configured too (similar as it was with
update-source in ROSv6).
It is not mandatory to specify a remote AS number. ROS v7 can determine remote ASN from an open message. You should specify the remote AS only when you want to accept a connection from that specific AS.
Peer role is now a mandatory parameter, for basic setups, you can just use ibgp, ebgp (more information on available roles can be found in corresponding RFC draft https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/?include_text=1), keep in mind that at the moment capabilities, communities, and filtering described in the draft is not implemented.
Very basic iBGP set up to listen on the whole local network for connections:
Now you can monitor the status of all connected and disconnected peers from
/routing bgp session menu.
Other great debugging information on all routing processes can be monitored from /routing stats menu
Route filtering differs a bit from ROSv6. In the BGP template, you can now specify output.filter, input.filter as well as several input.accept-* options.
Now input.accept-* allows filter incoming messages directly before they are even parsed and stored in memory, that way significantly reducing memory usage. Regular input filter chain can only reject prefix which means that it will still eat memory and will be visible in /routing route table as "not active, filtered",
A very basic example of a BGP input filter to accept prefixes from 192.168.0.0/16 subnet without modifying any attributes. For other prefixes subtract 1 from received local pref value and set IGP metric to value from OSPF ext. Additionally, we will accept only specific prefixes from the address list to reduce memory usage
If the routing filter chain is not specified BGP will try to advertise every active route it can find in the routing table
The default action of the routing filter chain is "drop"
Lastly, you might notice that
So ROSv6 network configuration:
in v7 would translate to:
Starting from ROSv7.1beta4, routing filter configuration is changed to script-like configuration. Rule now can have "if .. then" syntax to set parameters or apply actions based on conditions from "if" statement.
Multiple rules without action are stacked in single rule and executed in order like firewall, the reason is that the "set" parameter order is important and writing one "set"s per line, allows for an easier understanding from top to bottom on what actions were applied.
For example, match static default route and apply action accept can be written in one config rule:
For example, ROSv6 rule "/routing filter add chain=ospf_in prefix=172.16.0.0/16 prefix-length=24 protocol=static action=accept" converted to ROSv7 would be:
Another example, match prefixes from 172.16.0.0/16 range with prefix length equal to 24 and set bgp med and prepend values
It is also possible to match prefix length range like this
Filter rules now can be used to match or set communities, large communities, and extended communities from community list:
If there are a lot of community sets, that need to be applied in multiple rules, then it is possible to define community sets and use them to match or set:
Since route-target is encoded in extended community attribute to change or match RT you need to operate on extended community attribute, for example:
RouterOS implements an RTR client. You connect to the server which will send route validity information. This information then can be used to validate routes in route filters against a group with "rpki-validate" and further in filters "match-rpki" can be used to match the exact state.
For more info refer to the /routing/rpki documentation.