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.