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 overloaded OVS is still better solution for us. Regards, saso
On 6 May 2019, at 21:01, Kees Meijs <kees@nefos.nl> wrote:
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 better more upgrade-and-maintainance-proof solution I would welcome more information.
Regards, Kees
On 06-05-19 20:40, Saso Tavcar wrote:
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/043007.html> ... https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043063.html <https://mail.openvswitch.org/pipermail/ovs-discuss/2016-November/043063.html>
Official OVS quote:
We'd accept patches to improve OVS's routing table code. It's not designed to scale to 1,800,000 routes. We'd also take code to suppress the routing table code in cases where it isn't actually needed, since it's not always needed. But we can't take a patch to just delete it; I'm sure you understand. I tried to apply this patch at that time, but was already useless for newer versions:
https://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161123/5379... <https://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20161123/5379b333/attachment.bin>
Our workaround was to scale VM with 3 vCPU-s, since our average system load is 1.5 for BGP.
You can see what is happening: