...

Routing Tables

By default, all routes are added in to the "main" routing table as it was before. From a configuration point of view, 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 fitlered 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.

...

Another new change is that most common route print requests are processed by the routing process which significantly improves the speed compared to v6.

Use of Routing Tables and Policy Routing

Main The main difference from v6 is that routing table must be added in /routing table menu 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 /routing rule).

Another main difference is how the route is added in to a specific routing table. There is no separate parameter routing-mark as it was in v6, now routing table is specified as part of destination: dst-address=dst@table_name

Lets Let's consider a basic example where we want to resolve 8.8.8.8 only in routing table named myTable to the gateway 172.16.1.1:

/routing table add name=myTable fib
/routing rule add dst-address=8.8.8.8 action=lookup-only-in-table table=myTable
/ip route add dst-address=8.8.8.8@myTable gateway=172.16.1.1@main

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.

/routing ospf instance 
add name=v2inst version=2 router-id=1.2.3.4
add name=v3inst version=3 router-id=1.2.3.4
/rouing ospf area
add name=backbone_v2 area-id=0.0.0.0 instance=v2inst
add name=backbone_v3 area-id=0.0.0.0 instance=v3inst

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 interface. Here are some interface configuration examples:

...

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 redistribureredistribute.
For example lets , let's say you want to redistribute only static ipv4 routes from /192.168.0.0/16 network range.

...

BGP Configuration

There is a complete redesing redesign of the BGP configuration compared to ROSv6. First The first biggest difference is that there is no more instance and peer configuration menus. Instead, we have connection, template and peer-cache menus.
THe The reason for such structure is to strictly split parameters that are responsible for connection and change of these parameters require requires immediate connection termination and parameters that that do not tear existing connection when changed.

Lets 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 simlar a similar config to a group of peers. Note that this is not the same as peer gropus groups on Cisco devices, where the group is more than just a common configuration.

By default, there is a default template which that requires for you to set your own AS.

/routing/bgp/template set default as=65533

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 filter chain you set output.filter=myBgpChain.

...

Another important aspect of the new routing configuration is Routing Instance, which sets router-id and groups group peers in one instance. RouterOS adds default instance which picks instnaceinstance-id from any interface lowest IP. Default bgp 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.

Now that we have parameters set for the template we can add BGP connections. Minimal A minimal set of parameters are remote.address, template, connect, listen and local.role

Connect and listen to parameters specify whether peer 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 multihop connection local.address must be configured too (similar as it was with update-source in ROSv6).

Peer role is now mandatory parameter, for basic setups you can just use ibgp, ebgp (more information on available roles can be fond found in corresponding rfc RFC draft https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/?include_text=1)

...

Very basic iBGP setup to listen on the whole local network for connections:

/routing/bgp/connection
add remote.address=10.155.101.0/24 listen=yes template=default local.role=ibgp 

Now you can monitor the status of all connected and disconnected peers from /routing bgp peer-cache 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 incomming 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", 

Very 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 substract subtract 1 from received local pref value and set IGP metric to value from OSPF ext. Additionally, we will accept only specific  prefixes from address list to reduce memory usage

...

...

One filter rule in ROSv7 compared to ROSv6 can have only one set of "match" and one set of "set", which menas means that if you want to match by more than one parameter you will have to add more than one rule, for example, match static default route and apply action accept:

...

Filter rules now can be used to match or set communities,  large communities, and extended communities from community list:

/routing/filter/large-community-set
add set=myLargeComSet community=200001:200001:10 


/routing/filter/rule
add chain=bgp_in set-bgp-communities-large=modify<append>myLargeComSet action=accept

RPKI

RouterOS implements an RTR client. You connect to the server which will send route validity information. This informaton 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 exact state.

Very basic example to reject all prefixes with "invalid" state and accept the rest. Lets Let's consider that we have our own RTR server on our network with IP adddress address 192.168.1.1

/routing/bgp/rpki
add group=myRpkiGroup address=192.168.1.1 port=8282 refresh-interval=20

/routing/filter/rule
add chain=bgp_in rpki-verify=myRpkiGroup 
add chain=bgp_in match-rpki=invalid action=reject
add action=accept

...