Re: 100% CPU load with device scanning enabled

Hi, I've been struggling with similiar issue while trying to setup BIRD on EdgeRouter platform. Unfortunately, VRF approach worked only until I put some ip rules. Best regards, Łukasz Jarosz wt., 7 maj 2019, 09:06 użytkownik Kees Meijs napisał: > Hi again, > > Placing the routes in another tabl

Re: 100% CPU load with device scanning enabled

Hi again, Placing the routes in another table works fine: > # ip r s ta 10 | wc -l > 744892 Meanwhile in the default table: > # ip r s | wc -l > 3 However it seems the Open vSwitch daemon is again triggered and polls to synchronise the routes. Still eating it's way through a CPU thread: > to

Re: 100% CPU load with device scanning enabled

Hi there, Just creating a bridge with no configuration and no ports attached is enough: > ~# ovs-vsctl add-br foobar Now host a BGP full feed and there's havoc. Hopefully I'll be able to configure VRFs today and'll if that helps. Cheers, Kees On 07-05-19 07:04, Maria Matějka wrote: > Fine! >

Re: 100% CPU load with device scanning enabled

Fine! Anyway, I can offer you this: Most of the time spent is the configuration of OVS as I'm not familiar with it. If you could provide me with a script that I could just run with no configured OVS before and the bug manifests… whooa, it would really help me. Maria On May 7, 2019 6:53:42 AM GM

Re: 100% CPU load with device scanning enabled

Thanks Maria. I don't want to eat up your precious time so I'll try the VRF approach first. If that works we're good. K. On 06-05-19 23:04, Maria Matejka wrote: > Just shortly, I was trying BIRD in QEMUs connected via OVS bridges > several years ago. It was even worse, I went to some segfaults i

Re: 100% CPU load with device scanning enabled

Hi and thanks again. We're in need of VRF support and maybe it works without overloading when placing the full feed in another than default VRF (which is good practice anyway). Hopefully OVS only synchronises the default system tables. I'll post my findings. Regards, Kees On 06-05-19 21:33, Sas

Re: 100% CPU load with device scanning enabled

Hello! Just shortly, I was trying BIRD in QEMUs connected via OVS bridges several years ago. It was even worse, I went to some segfaults in OVS. (A week later, one of my friends told me that it was an embargoed bug.) I didn't try any more, it wasn't feasible. I'd like to promise that I'd look

Re: 100% CPU load with device scanning enabled

The best solution would be a good OVS routing table patch as quoted. Maybe BIRD developers can help, since they are native C developers. We also tried bird on native (K)VM network interfaces. Since they are some kind of SW emulation too, we hit on unrecoverable network IRQ problems, thus overloa

Re: 100% CPU load with device scanning enabled

Hi Saso, Thank you very much. OVS is new in the mix (we're not replacing Quagga alone) as well. Obviously we didn't expect this to happen. I'll see if patching OVS in Debian in a similar way works for us or if another approach fits better (i.e. maybe not using OVS at all). If you'll know of a be

Re: 100% CPU load with device scanning enabled

Update: strace(1) shows the following in regard to Open vSwitch in an endless loop: > socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 40 > ioctl(40, SIOCGIFNAME, {ifr_index=6, ifr_name="vlan1105"}) = 0 > close(40)   = 0 This doesn't make any sense (at least, to me) sinc

Re: 100% CPU load with device scanning enabled

Hi, this is an OVS issue, already discussed: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043007.html ... https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043063.html

Re: 100% CPU load with device scanning enabled

Hi again, Sorry: shouldn't happen. Meanwhile we tested BIRD 2.0.4 as well (compiled from source) with the same result. The process ovs-vswitchd completely consumes a CPU thread. When disabling the exportation of the routes (full feed, so 700k+ routes) the load drops back to nothing. Regards, Ke

100% CPU load with device scanning enabled

Hi list, We're in the process of replacing Quagga with BIRD but stumble upon a little problem. When device scanning is on (obviously default) our testing machine completely fills up a CPU core. The culprit isn't BIRD itself but an Open vSwitch daemon. After disabling the device protocol and rest