RouterOS v7 is capable of splitting tasks between multiple processes.
There is one "main" task, which can start/stop sub-tasks and process data between those sub-tasks. Each sub-task can allocate "private" (only accessible by this particular task) and "shared" memory (accessible by all route tasks).
List of tasks that can be split:
- Handling of "print" command;
- Entire OSPF protocol handling;
- Entire RIP protocol handling;
- Static configuration handling;
- Routing Policy configuration;
- BGP connections and configuration handling;
- BGP receive (one task per peer or grouped by specific parameters);
- BGP send (one task per peer or grouped by specific parameters);
- FIB update.
BGP receive and send can be split in sub tasks by specific parameters, for example, it is possible to run input per each peer or group all peer inputs and run them in main process. This split by sub-tasks is controlled with
output.affinity parameter configuration in
/routing/bgp/template.It is possible to boost performance by playing with affinity values on devices with less cores, since sharing data between tasks is a bit slower than process the same data within one task. For example, on single core or two core devices running input and output in main or instance process will boost performance.
All currently used tasks and their allocated private/shared memory can be monitored using command:
Routing Table Update Mechanism
Illustration below tries to explain in more user friendly form on how routing table update mechanism is working.
Routing protocols continuously loop through following procedures:
- "main" process waits for updates from other sub tasks (1);
- "main" starts to calculate new routes (2..4) if:
- update from sub task is received;
- protocol has not published all routes;
- configuration has changed or link state has changed.
- during new route calculation (5) following event occur:
- all received updates are applied to the route;
- gateway reachability is being determined;
- recursive route is being resolved;
- "publish" event is called where "current" routes are being published. During this phase, "current" routes will not change, but protocols can still receive and send updates (6).
- Do cleanup and free unused memory (7). In this step everything that is no longer used in new "current" table is removed (routes, attributes, etc.).
Consider "updated" and "current" as two copies of routing table, where "current" table (2) is the one used at the moment and "updated" (1) is table of candidate routes to be published in the next publish event (3 and 4). This method prevents protocols to fill memory with buffered updates while "main" process is doing "publish", instead protocols sends the newest update directly to "main" process which then copies new update in "updated" table. A bit more complicated is OSPF, it internally has similar process to select current OSPF routes which then are sent to the "main" for further processing.