Hello,

Has anyone observed that ROS7 consumes significant CPU resources for route advertisement? I've recently migrated two peering routers to version 7.10, taking advantage of the added BFD support. After conducting tests on the ccr1016 model, I've encountered an unusable state due to a kernel failure bug confirmed by MikroTik. While awaiting a fix, I've also found the CCR2004-1G-12S+2XS to be unsuitable for my purposes, especially when handling a full table or two. This includes approximately 780k IPv6 routes, 1.4mil IPv4 routes, and around 70 BGP peers.

Despite experimenting with various input and output affinity settings, I haven't been able to achieve proper functionality. The most stable configuration utilized the "main" setting for both input and output, but it introduced its own set of issues. Having run this on a CHR with ten 3GHz cores, I can understand why, as on the ccr2004, a single CPU core is stuck at 100% without successfully advertising any routes even after 20 minutes. On the CHR, I've set the input and output settings to "alone." Here, enabling my advertisement filters causes all ten CPU cores to spike to around 80% for about 20-30 seconds. This process is responsible for advertising routes to approximately 70 peers, averaging about 38 IPv4 routes and 17 IPv6 routes per peer. Given the modest volume of routes being advertised, I'm puzzled by the substantial CPU load. I'm uncertain whether my route filters are configured incorrectly, contributing to this excessive load. Below is an example of an outbound route filter per peer:

chain=T_GOOGLE rule="set bgp-communities 15169:13010; jump T_GEN_S_ZONE;"
chain=T_GEN_S_ZONE rule="if (dst in xxx.xxx.252.0/22 && dst-len in 22-24) { set bgp-out-med 20; accept; }"
chain=T_GEN_S_ZONE rule="if (dst in xxx.xxx.224.0/19 && dst-len in 19-24) { set bgp-out-med 20; accept; }"
chain=T_GEN_S_ZONE rule="if (dst in xxxx::/32 && dst-len in 32-36) { set bgp-out-med 20; accept; }"
chain=T_GEN_S_ZONE rule="return;"

With that number of peer our platform of choice is Juniper MX200 at least, you can certainly try CCR2216 if you have budget or leeway to make experiment , we have a few dozen of that CCR2004 that we loan to other or just collecting dust due underwhelming bgp performance

sometimes CCR2004-1G-12S+2XS offering a lot of sfp interfaces for a low cost, can be tempting to use on challenging scenarios, with bad results

because is not as powerful as a 2116/2216

ccr2004-1G-12S+2XS= 4 cpu cores at 1.7ghz
ccr2116/2216= 16 cpu cores at 2.0 ghz (same cpu both models)

ccr2004-1G-12S+2XS= 4GB RAM
ccr2116/2216= 16GB RAM (same on both models)

ccr2004-1G-12S+2XS= NO L3 nor L2 Hardware Offload, all done by CPU
ccr2116/2116= L3 and L2 Hardware Offload assisted by Switching ASIC

ccr2004-1G-12S+2XS= 2 x 25G SFP28 + 2 x 10G SFP+
ccr2116= 4 x10G SFP+ + 12 1G Rj45
ccr2216= 2 x 100G QSFP28 + 12 x 25G SFP28

As we can see, the only strong point of CCR2004-1G-12S+2XS is SFP+ interface ammount

I think your scenario deserves a stronger machine

suggestion, always check block diagram of the products, ther you will find valuable information about its internal architecture