...
By default, all routes are added 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 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.
...
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 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
...
Very interesting parameters are inutinput.affinity andoutput.affinity, they allow to control in which process input and output of active session will be processed:
- alone - input and output of each session is processed in its own process, most likely best option when there are a lot of cores and a lot of peers
- afi, instance, vrf, remote-as - try to run input/output of new session in process with similar parameters
- main - run input/output in main process (could potentially increase performance on single core even possiby possibly on multicore devices with small amount of cores)
- input - run output in the same process as input (can be set only for output affinity)
...
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 multihop multi-hop 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 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 desribed described in draft is not implemented.
...
Now you can monitor the 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
...