...
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 input.affinity and 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.
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 does calculation in its own process and just sends the final result to the "main".
Routing protocols continuously loop through following procedures:
- "main" process waits for updates from other sub tasks (1);
- "main" starts to calculate new routes 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 .
Consider "updated" and "current" as two copies of routing table, where "current" table is the one used at the moment and "updated" is table of candidate routes to be published in the next publish event. 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 does calculation in its own process and just sends the final result to the "main".
...
- (7).
All currently used tasks and their allocated private/shared memory can be monitored using command:
...