Roting Tables
By default all routes are added in "main" routing table as it was before. From 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 new menu /routing route, which shows all address family routes as well as all fitlered 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 routing process which significantly improves the speed compared to v6.
Use of Routing Tables and Policy Routing
Main difference from v6 is that routing table must be added in /routing table menu and fib parameter should be specified if 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 route is added in 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 consider 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.
OSPF Configuration
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 instance for each and then add 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 case of IPv6 you add either interface on which you want to run OSPF (the same as ROSv6) or IPv6 network. In second case OSPF will automatically detect interface. Here are some interface configuration examples:
/routing ospf interface add network=192.168.0.0/24 area=backbone_v2 add network=2001:db8::/64 area=backbone_v3 add network=ether1 area=backbone_v3
Another big difference is that interface and neighbor menus are purely for configuration, to monitor adjacent neighbors or interface status there are two new menu interface-state and neighbor-state.
All route distribution control is now done purely with routing filter select, no more redistribution knobs in instance. This gives greater flexibility on what routes from which protocols you want to redistribure.
For example lets say you want to redistribute only static ipv4 routes from /192.168.0.0/16 network range.
/routing ospf instance set backbone_v2 out-filter=ospfv2_out_select /routing filter select-rule add chain=ospfv2_out_select do-where=ospf_out /routing filter rule add chain=ospf_out match-prfx-value=dst<subsumes>182.168.0.0/16 action=accept
If routing filter chain is not specified OSPF will try to advertise every active route it can find in routing table
Default action of routing filter chain is "drop"
BGP Configuration
There is complete redesing of BGP configuration compared to ROSv6. First biggest difference is that there is no more instance and peer configuration menus. Instead we have connection, template and peer-cache menus.
THe reason for such structure is to strictly split parameters that are responsible for connection and change of these parameters require immediate connection termination and parameters that that do not tear existing connection when changed.
Lets start with the Template. It contains all BGP protocol related configuration options. It can be used as template for dynamic peers and apply simlar config to group of peers. Note that this is not the same as peer gropus on Cisco devices, where group i smore than just a common configuration.
By default there is default template which 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 output and input section. If you are familiar with capsman then syntax is the same, for example, to specify output filter chain you set output.filter=myBgpChain.
You can even inherit template parameters from another template, for example:
/routing bgp template add name=myAsTemplate as=65500 output.filter=myAsFilter set default template=myAsTemplate
Another important aspect of new routing configuration is Routing Instance, which sets router-id and groups peers in one instance. RouterOS adds default instance which picks instnace-id from any interface lowest IP. Default bgp template by default is set to use "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 template we can add BGP connections. Minimal set of parameters are remote.address, template, connect, listen and local.role
Connect and listen parameters specify whether peer will try to connect and listen to remote address or just connect or just listen. It is possible that in setups where peer uses multihop connection local.address must be configured too (similar as it was with update-source in ROSv6).
It is not mandatory to specify remote AS number. ROS v7 can determine remote ASN from open message. You should specify remote.as only when you want to accept connection from that specific AS.
Peer role is now mandatory parameter, for basic setups you can just use ibgp, ebgp (more information on available roles can be fond in corresponding rfc draft https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/?include_text=1)
Very basic iBGP setup to listen on whole local network for connections:
/routing bgp connection add remote.address=192.168.1.0/24 listen=yes template=default local.role=ibgp
Now you can monitor status of all connected and disconnected peers from /routing bgp peer-cache menu.
Other great debugging information on all routing processes can be monitored from /routing stats menu
[admin@v7_ccr_bgp] /routing/stats/process> print interval=1 Columns: TASKS, PRIVATE-MEM-BLOCKS, SHARED-MEM-BLOCKS, PSS, RSS, VMS, RETIRED, ID, PID, RPID, PROCESS-TIME, KERNEL-TIME, CUR-B> # TASKS PRIVATE-M SHARED-ME PSS RSS VMS RET ID PID R PROCESS-TI KERN> 0 routing tables 12.2MiB 20.0MiB 18.7MiB 42.2MiB 83.4MiB 8 main 319 0 19s750ms 8s50> rib > connected networks > 1 fib 512.0KiB 0 7.4MiB 30.9MiB 83.4MiB fib 384 1 5s160ms 22s5> 2 ospf 1024.0KiB 1024.0KiB 5.9MiB 25.9MiB 83.4MiB 382 ospf 388 1 1m42s170ms 1m31> connected networks > 3 fantasy 512.0KiB 0 2061.0KiB 5.9MiB 83.4MiB fantasy 389 1 1s410ms 870m> 4 configuration and reporting 40.0MiB 512.0KiB 45.0MiB 64.8MiB 83.4MiB static 390 1 12s550ms 1s17> 5 rip 768.0KiB 0 5.3MiB 24.7MiB 83.4MiB rip 387 1 1s380ms 1s20> connected networks > 6 routing policy configuration 512.0KiB 256.0KiB 2189.0KiB 6.0MiB 83.4MiB policy 385 1 1s540ms 1s20> 7 BGP service 768.0KiB 0 2445.0KiB 6.2MiB 83.4MiB bgp 386 1 6s170ms 9s38> 8 BGP Input 10.155.101.217 8.8MiB 6.0MiB 15.6MiB 38.5MiB 83.4MiB 20 21338 1 25s170ms 3s23> BGP Output 10.155.101.217 > 9 Global memory 256.0KiB global 0 0 > -- [Q quit|D dump|C-z pause|right]