Hello, I just installed bird 2.0.0 on a test machine to try it out and I have some issues: (CentOS 7 / kernel 4.14.5-1.el7.elrepo.x86_64) 1) the kernel protcol sees no routes (both ipv4 and ipv6) and doesn't export any routes 2) each time I change the config and do a 'birdc conf' it resets all BGP sessions and logs bird: Cannot reconfigure channel XXX.ipv4 bird: Cannot remove channel XXX.ipv4 bird: Restarting protocol XXX 3) can't establish BGP with bird 1.6.3 if I have add paths on; on the session - 2.0.0 says: "BGP Error: Malformed attribute list" and 1.6.3: "Socket: Connection closed". add paths on; works between two bird 2.0.0. Could these be caused by kernel or *lib versions or are these bugs in bird? Thanks, Radu
On Thu, Dec 14, 2017 at 08:23:01PM +0200, Radu Anghel wrote:
Hello,
I just installed bird 2.0.0 on a test machine to try it out and I have some issues: (CentOS 7 / kernel 4.14.5-1.el7.elrepo.x86_64)
1) the kernel protcol sees no routes (both ipv4 and ipv6) and doesn't export any routes
2) each time I change the config and do a 'birdc conf' it resets all BGP sessions and logs
bird: Cannot reconfigure channel XXX.ipv4 bird: Cannot remove channel XXX.ipv4 bird: Restarting protocol XXX
3) can't establish BGP with bird 1.6.3 if I have add paths on; on the session - 2.0.0 says: "BGP Error: Malformed attribute list" and 1.6.3: "Socket: Connection closed". add paths on; works between two bird 2.0.0.
Could these be caused by kernel or *lib versions or are these bugs in bird?
Hello Thanks for reports Could you send me your config file? If you add 'debug all' to your Kernel protocol, what you see in logs? -- 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."
On 14.12.2017 20:31, Ondrej Zajicek wrote:
Hello
Thanks for reports Could you send me your config file? If you add 'debug all' to your Kernel protocol, what you see in logs?
Nothing is logged if I enable debug all to the kernel protocol, total silence. I'm attaching my current config. Thanks, Radu
On Thu, Dec 14, 2017 at 08:51:59PM +0200, Radu Anghel wrote:
On 14.12.2017 20:31, Ondrej Zajicek wrote:
Hello
Thanks for reports Could you send me your config file? If you add 'debug all' to your Kernel protocol, what you see in logs?
Nothing is logged if I enable debug all to the kernel protocol, total silence. I'm attaching my current config.
Hi You have doubled channel definitions, one with implicit arguments ('ipv4;'), and one with explicit arguments ('ipv4 { ... }'). That is likely a cause of issue #2. We definitely should add a check for that. Could you try config file with only one channel of each type per protocol? It may be also issue #1, or perhaps it is problem with newer Linux kernels (i checked up to 4.13). But regardless of Linux API, we still should get at least periodic 'Scanning routing table' messages. Issue #3 is most likely a bug in BGP, i will check that. -- 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."
On 14.12.2017 21:09, Ondrej Zajicek wrote:
Hi
You have doubled channel definitions, one with implicit arguments ('ipv4;'), and one with explicit arguments ('ipv4 { ... }'). That is likely a cause of issue #2. We definitely should add a check for that. Could you try config file with only one channel of each type per protocol?
It may be also issue #1, or perhaps it is problem with newer Linux kernels (i checked up to 4.13). But regardless of Linux API, we still should get at least periodic 'Scanning routing table' messages.
Issue #3 is most likely a bug in BGP, i will check that.
Hi, I can confirm that keeping only one channel definition fixes both #1 and #2. A check warning/rejecting this would be nice :) Thanks, Radu
On Thu, Dec 14, 2017 at 09:19:32PM +0200, Radu Anghel wrote:
On 14.12.2017 21:09, Ondrej Zajicek wrote: Hi,
I can confirm that keeping only one channel definition fixes both #1 and #2. A check warning/rejecting this would be nice :)
Hi Tested add-path between old and new BIRD, works for me. Does the problem appear even with fixed channel definitions? It is possible that it is also related, like add-path announced in capabilities due to the second channel (with add-path), but incoming update dispatched by the first one (without). -- 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."
On 14.12.2017 23:44, Ondrej Zajicek wrote:
On Thu, Dec 14, 2017 at 09:19:32PM +0200, Radu Anghel wrote:
Hi
Tested add-path between old and new BIRD, works for me. Does the problem appear even with fixed channel definitions? It is possible that it is also related, like add-path announced in capabilities due to the second channel (with add-path), but incoming update dispatched by the first one (without).
Sorry I didn't test it yesterday also, add-path works for me too with only one channel definition, so #3 was the same. Thanks, Radu
participants (2)
-
Ondrej Zajicek -
Radu Anghel