For those running BGP with full tables on v7 is it normal for one core to be 90-100% almost all the time when BGP is running. tool profile shows it as “routing”. This happens regardless of no traffic or high traffic.
If you didn’t properly configure BGP input/output CPU affinity on all BGP peers to match the CPU model of your router, then you will face CPU issues.
Configure input multi-core processing. Read more in Routing Protocol Multi-core Support article.
alone - input and output of each session are processed in its own process, most likely the 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 the main process (could potentially increase performance on single-core even possibly on multi-core devices with a small amount of cores)
input - run output in the same process as input (can be set only for output affinity)
This behavior occurs on baremetal x86 with 22 cores and CCR2116 with 16 cores. I have them set to “alone” BGP stability is good and throughput is good. Just always have a single core 90-100%. Curious what others have observed.
You need to set “alone” for all peers and both input/output on each peer. If you only do it for some peers and not all peers, you may see issues.
I’m having the same problem even though all peers are configured affinity input/output alone. It keeps alternating 100% processing between CPU cores.
I saw that I have this issue once I open ip/route or ipv6/route windows on winbox.
If I reboot the router and don’t open those windows, I don’t have any core at ~100% for routing
You are correct. After a reboot it no longer taps out one core. Mikrotik needs to figure out how to optimize Winbox so something as simple as ip/route or ipv6/route does not cause such behavior even after the ip/route box is closed or the Winbox session has been closed.
sometimes when you open winbox and a window with many elements that consume alot of resources
is a matter of clossing that windows and then exit winbox
reopen winbox and wait (without opening a window with many elements) some minutes and that 100% core will be gone
windows with many elements:
simple queues when you have a lot of them
ip firewall when you hav a lot of rules
ip firewall connections when you use conn tracking
ip routes when you have a lot of routes
i think they have optimizes this, in some age problem was worst, i hope this improve, several full tables will be a increasingly frequent situation on CCR2216/2116
In my case I closed all windows and waited an hour as well as exited the Winbox session and opened a new one with only the system resources cpu box open and it was still tapping out a core. This was replicated on 4 x86 7.8 routers as well as a 7.8 CCR2116
Does this happen if you print the table in the terminal directly outside Winbox as well?
Im also seeing similar issues, Im currently testing on V7.10rc1
I’m also observing this exact same behavior on RouterOS 7.13.
Opening the route list in winbox, even if filtering, maxes one core to 100%. Closing the window or winbox does not fix the issue. Restarting the entire routes does seem to fix it, which is not an option for a production machine.
Same problem here, also SNMP stops working because of the high cpu usage.