Routing Tables

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 show only basic route attributes.

For more in-depth information on routing see this article (How Packets Are RoutedIP Routing).

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

The main difference from v6 is that the routing table must be added to the /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.
The routing rule configuration is the same except for the menu location (instead of /ip route rule, now it is /routing rule).

...

Instead of routing rules, you could use mangle to mark packets with routing-mark, the same way as it was in ROSv6.

OSPF Configuration

OSPFv3 and OSPFv2 are now merged into one single menu /routing ospf. At the time of writing this article, there are 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.

...

BGP Configuration

There is a complete redesign of the BGP configuration compared to ROSv6. The first biggest difference is that there is no more instance and peer configuration menus. Instead, we have connection, template and session menus.
The reason for such a structure is to strictly split parameters that are responsible for connection and parameters that are BGP protocol specific.

...

Monitoring Advertisements

RouterOS v7 by default disables monitoring of the BGP output. This allows to significantly reduce resource usage on setups with large routing tables.

To be able to see output advertisements several steps should be taken:

• enable "output.keep-sent-attributes" in BGP connection configuration
• run "dump-saved-advertisements" from BGP session menu
• view saved output from "/routing/stats/pcap" menu

[admin@arm-bgp] /routing/bgp/connection>  set 0 output.keep-sent-attributes=yes
[admin@arm-bgp] /routing/bgp/session> print 
Flags: E - established 
 0 E remote.address=10.155.101.183 .as=444 .id=192.168.44.2 .refused-cap-opt=no .capabilities=mp,rr,gr,as4 
     .afi=ip,ipv6 .messages=4 .bytes=219 .eor="" 
     local.address=10.155.101.186 .as=456 .id=10.155.255.186 .capabilities=mp,rr,gr,as4 .afi=ip,ipv6 
     .messages=1 .bytes=19 .eor="" 
     output.procid=66 .filter-chain=bgp_out .network=bgp-nets .keep-sent-attributes=yes 
     input.procid=66 ebgp 
     hold-time=3m keepalive-time=1m uptime=4s30ms 

[admin@arm-bgp] /routing/bgp/session> dump-saved-advertisements 0 save-to=test_out.pcap

Networks

Lastly, you might notice that the network menu is missing and probably wondering how to advertise your own networks. Now networks are added to the firewall address-list and referenced in the BGP configuration.
Lastly, you might notice that the network menu is missing and probably wondering how to advertise your own networks. Now networks are added to the firewall address-list and referenced in the BGP configuration.
Following ROSv6 network configuration:

...

Routing Filters

Starting from ROSv7.1beta4, the routing filter configuration is changed to a script-like configuration. The rule now can have "if .. then" syntax to set parameters or apply actions based on conditions from the "if" statement.

...

/routing/filter/rule
add chain=bgp_in rule="set bgp-ext-communities rt:327824:20 "

RPKI

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 RPKI documentation.

RIP Configuration

To start RIP, the instance should be configured. There you should select which routes will be redistributed by RIP and if it will redistribute the default route.

...

/routing/rip/instance

...

add name=instance1 originate-default=never redistribute=connected,static 

Then interface-template should be configured. There is no need to define networks in ROS version 7 as it was in version 6.

...

/routing/rip/interface-template

...

add interfaces=ether1 instance=instance1

Now the basic configuration is completed on one router. RIP neighbor router should be configured in a similar way. 

In ROS v7 the neighbors will appear only when there are routes to be sent or/and to be received.

Prefix lists from ROSv6 are deprecated, now all the filtering must be done by the routing filters.