2 x BGP full routing table performs terribly

[itrack]

Hi,

I have a CCR2116-12G-4S+ / RouterOS 7.15.3 with the following setup:

• 2 Default route BGP sessions;
• 2 Full routing table BGP sessions with 1 mil.+ prefixes.

When I establish a bgp full routing table session, the router behaves super weird, commands like the following no longer work:

• routing stats/process/print interval=1
  ip route print detail where bgp-as-path ~ “30621$”

and so on.

Also if a full routing table session is started before a default route session, the default route session is not started and probably waits after importing full routing routes or something like that

All this time CPU load is around 6-7%.

• Note that the affinity was set to alone.

/routing bgp template
set default as=21**30 disabled=no input.affinity=alone .filter=bgp_in output.affinity=alone .filter-chain=bgp_out .network=public_class routing-table=main
add as=21**30 disabled=no input.filter=bgp_in local.address=10.192.**.*** .role=ebgp name=***-Backup output.filter-chain=bgp_out .network=public_class remote.address=10.192.**.***/32 .as=8**8 routing-table=\
    main templates=default
add as=21**30 disabled=yes input.affinity=alone .filter=bgp_in local.address=10.192.**.*** .role=ebgp multihop=yes name=***-Full-Route output.affinity=alone .filter-chain=bgp_out .network=public_class \
    remote.address=86.120.**.*** .as=8**8 routing-table=main templates=default
add as=21**30 disabled=no input.filter=bgp_in local.address=92.180.**.** .role=ebgp name=*** output.filter-chain=bgp_out .network=public_class remote.address=92.180.**.**/32 .as=8**3 routing-table=main \
    templates=default
add as=21**30 disabled=yes input.affinity=alone .filter=bgp_in local.address=92.180.**.** .role=ebgp multihop=yes name=****-Full-Route output.affinity=alone .filter-chain=bgp_out .network=public_class \
    remote.address=62.217.***.***/32 .as=8**3 routing-table=main templates=default

[mrz]

ip route print detail where bgp-as-path ~ “30621$”

is not going to work because such parameters do not exist.
And even if you do such search in a correct menu with correct parameters you are asking console to run a script that gets whole routing table ( which by itself could take few minutes), and performs regexp matching on every entry it got.
2mil very resource intensive regexp executions will add significant load to the CPU.

[itrack]

ip route print detail where bgp-as-path ~ “30621$”

is not going to work because such parameters do not exist.
And even if you do such search in a correct menu with correct parameters you are asking console to run a script that gets whole routing table ( which by itself could take few minutes), and performs regexp matching on every entry it got.
2mil very resource intensive regexp executions will add significant load to the CPU.

It was just an example, the biggest problem is that although it uses a small amount of processor, once the processing full routing bgp session starts, it blocks the processing of other sessions.

[itrack]

e.g:


In the session table I see only 2 sessions, although all 4 are established (I checked with the providers) :

it practically blocks the normal operation of the router, although the processor and ram memory are used to a minimum.

[mrz]

There are certain tasks done by one process, check this article how multicore with routing processes work:
https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Multi-core+Support

[itrack]

There are certain tasks done by one process, check this article how multicore with routing processes work:
https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Multi-core+Support

To me it looks like I have multiple process:

Thank you!

[mrz]

As it is described in the article above input and output processes are not handling route calculations.
bgp input process receives updates, decodes and sends routing info to main process.
Main process is doing the calculations
bgp output is similar to input, it “asks” for routes from the main process, encodes and sends the packets.

[itrack]

As it is described in the article above input and output processes are not handling route calculations.
bgp input process receives updates, decodes and sends routing info to main process.
Main process is doing the calculations
bgp output is similar to input, it “asks” for routes from the main process, encodes and sends the packets.

Got it now!
I think I also found problems with processing performance. It may be a bug or something that could definitely be improved.
If you have huge bgp tables and open IP/Routes or perform operations from the console that involve routes, the processor is constantly at 6%, if you insist and open IP/Routes several times the router freezes completely. It seems like something that shouldn’t happen, maybe there should be a pagination or something to close processes launched by opening IP/Routes.

Thank you!