Kernel dropped some netlink messages, will resync on next scan.
Hi, I'm upgrading my core router (running an old bird 1.3.10) with a new Ubuntu 16.04 running 1.6.3 from the official PPA. Actually it'a a pretty simple configuration ISP3 ISP1 ISP2 | | | | | | NEWROUTER=====<iBGP>======OLDROUTER | | ipv4/21 ipv6/32 In the new router i find a lot of messages "Kernel dropped some netlink messages, will resync on next scan." for both IPv6 and IPv4 For IPv6 daemon this seems to happen only when i start the sessions and load the full table and so I think it could be acceptable. For IPv4 daemon this seems to happen *a lot* when I start the BGP session with the iBGP enabled (and also this I think could be acceptable), but the message gets printed sometimes (a single line every 5/10 minutes) when the BGP is running normally. I already tried to adjust the net.core mem kernel parameters with: net.core.rmem_max = 8388608 net.core.wmem_max = 8388608 net.core.optmem_max = 65536 net.core.rmem_default=1064960 net.core.wmem_default=1064960 But the messages are still there. Any hints? maybe the rmem_default is still too low? Thanks Giuseppe
On Tue, Sep 12, 2017 at 11:19:43AM +0200, Giuseppe Ravasio (LU) wrote:
Hi, I'm upgrading my core router (running an old bird 1.3.10) with a new Ubuntu 16.04 running 1.6.3 from the official PPA.
Actually it'a a pretty simple configuration
ISP3 ISP1 ISP2 | | | | | | NEWROUTER=====<iBGP>======OLDROUTER | | ipv4/21 ipv6/32
In the new router i find a lot of messages "Kernel dropped some netlink messages, will resync on next scan." for both IPv6 and IPv4
Hi Note that we added this warning, but there is most likely no change in underlying issue (it was just silent before). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Il 12/09/2017 13:14, Ondrej Zajicek ha scritto:
Hi
Note that we added this warning, but there is most likely no change in underlying issue (it was just silent before).
I read that this message was added recently, but I was wondering about what could lead to this error in such a simple configuration and how I can debug the problem? Thanks Giuseppe
❦ 12 septembre 2017 11:19 +0200, "Giuseppe Ravasio (LU)" <giuseppe_ravasio@modiano.com> :
For IPv4 daemon this seems to happen *a lot* when I start the BGP session with the iBGP enabled (and also this I think could be acceptable), but the message gets printed sometimes (a single line every 5/10 minutes) when the BGP is running normally.
In a terminal, also run "ip monitor route" and check if there is anything fishy in it. -- Perilous to all of us are the devices of an art deeper than we ourselves possess. -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]
Hi, Vincent thanks for the hint!! I did some fishing with the ip monitor route and the message gets printed only when more than about 500/600 routes gets changed, and so
600 are added and >600 are deleted from the routing table.
Do you think that there is something that can be tuned to avoid this message dropping by the kernel? Thanks Giuseppe Il 12/09/2017 18:24, Vincent Bernat ha scritto:
❦ 12 septembre 2017 11:19 +0200, "Giuseppe Ravasio (LU)" <giuseppe_ravasio@modiano.com> :
For IPv4 daemon this seems to happen *a lot* when I start the BGP session with the iBGP enabled (and also this I think could be acceptable), but the message gets printed sometimes (a single line every 5/10 minutes) when the BGP is running normally.
In a terminal, also run "ip monitor route" and check if there is anything fishy in it.
❦ 13 septembre 2017 12:34 +0200, "Giuseppe Ravasio (LU)" <giuseppe_ravasio@modiano.com> :
I did some fishing with the ip monitor route and the message gets printed only when more than about 500/600 routes gets changed, and so 600 are added and >600 are deleted from the routing table.
Do you think that there is something that can be tuned to avoid this message dropping by the kernel?
Increasing net.core.rmem_default should do the trick (before starting BIRD). Otherwise, this is not a real worry: internally, unless you have another process pushing routes, BIRD already has a correct view of the routing table. -- By trying we can easily learn to endure adversity. Another man's, I mean. -- Mark Twain
Il 13/09/2017 13:27, Vincent Bernat ha scritto:
Increasing net.core.rmem_default should do the trick (before starting BIRD). Otherwise, this is not a real worry: internally, unless you have another process pushing routes, BIRD already has a correct view of the routing table.
setting net.core.rmem_default = 4194304 did the trick :-) BTW I did already tried to raise the value but I didn't think that bird must be restarted. Thanks!!! Giuseppe
participants (3)
-
Giuseppe Ravasio (LU) -
Ondrej Zajicek -
Vincent Bernat