Hi everybody, I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the following: bird> sh pro name proto table state since info kernel1 Kernel master up 13:10:06 device1 Device master up 13:10:06 NICbr1 BGP master up 13:10:28 Established NICbr2 BGP master up 13:10:29 Established PTTlg BGP master start 13:10:24 Connect Socket: Invalid argument MLPA1 BGP master start 13:10:24 Connect Socket: Operation timed out MLPA2 BGP master start 13:10:24 Connect Socket: Invalid argument MLPA3 BGP master start 13:12:51 OpenConfirm BGP Error: Hold timer expired MLPA4 BGP master start 13:10:24 Connect Socket: Invalid argument STATIC_BGP Static master up 13:10:06 All these BGP protocols are inherited from one template. The only difference is that those are established, use another source address which is configured on virtual interface. However my question is how to find out what's going on and how to detect a problem? Setting "log syslog all;" is not very helpful - it only fills the log file with a lot of "bird6: KRT: Error sending route 2c0f:fb50::/0 to kernel: No such process" messages. -- Is there any problem Exterminatus cannot solve? I have not found one yet.
On 09.04.2014 13:36, Peter Andreev wrote:
Hi everybody,
Hello!
I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the following:
bird> sh pro name proto table state since info kernel1 Kernel master up 13:10:06 device1 Device master up 13:10:06 NICbr1 BGP master up 13:10:28 Established NICbr2 BGP master up 13:10:29 Established PTTlg BGP master start 13:10:24 Connect Socket: Invalid argument MLPA1 BGP master start 13:10:24 Connect Socket: Operation timed out MLPA2 BGP master start 13:10:24 Connect Socket: Invalid argument MLPA3 BGP master start 13:12:51 OpenConfirm BGP Error: Hold timer expired MLPA4 BGP master start 13:10:24 Connect Socket: Invalid argument STATIC_BGP Static master up 13:10:06
All these BGP protocols are inherited from one template. The only difference is that those are established, use another source address which is configured on virtual interface.
However my question is how to find out what's going on and how to detect a problem? Setting "log syslog all;" is not very helpful - it only fills the log file with a lot of "bird6: KRT: Error sending route 2c0f:fb50::/0 to kernel: No such process" messages.
You can look at detailed protocol status via "show protocol [nam] all" You can enable appropriated level of per-protocol debug (e.g. add "debug { events, states };" to protocol config.
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
Hi Alexander, I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file. Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `bird6'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000464a9e in add_tail (l=0x801017798, n=0x80102a650) at lists.c:46 46 z->next = n; [New Thread 801007400 (LWP 100292/bird6)] (gdb) bt #0 0x0000000000464a9e in add_tail (l=0x801017798, n=0x80102a650) at lists.c:46 #1 0x0000000000469ce6 in ralloc (p=0x801017780, c=0x692260) at resource.c:224 #2 0x000000000045c20a in tm_new (p=0x801017780) at io.c:226 #3 0x0000000000425bef in bgp_setup_conn (p=0x801008020, conn=0x8010081c8) at ../../../proto/bgp/bgp.c:631 #4 0x0000000000425d97 in bgp_active (p=0x801008020) at ../../../proto/bgp/bgp.c:660 #5 0x00000000004252cb in bgp_decision (vp=0x801008020) at ../../../proto/bgp/bgp.c:334 #6 0x000000000045bd67 in ev_run (e=0x801017800) at event.c:85 #7 0x000000000045be02 in ev_run_list (l=0x694aa0) at event.c:135 #8 0x000000000045f05f in io_loop () at io.c:1716 #9 0x00000000004669b3 in main (argc=3, argv=0x7fffffffdb20) at main.c:820 (gdb) quit If this crash is interesting to you as port maintainer, I will provide any additional information which can help to understand why it happened. 2014-04-09 23:10 GMT+04:00 Alexander V. Chernikov <melifaro@freebsd.org>:
On 09.04.2014 13:36, Peter Andreev wrote:
Hi everybody,
Hello!
I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the following:
bird> sh pro name proto table state since info kernel1 Kernel master up 13:10:06 device1 Device master up 13:10:06 NICbr1 BGP master up 13:10:28 Established NICbr2 BGP master up 13:10:29 Established PTTlg BGP master start 13:10:24 Connect Socket: Invalid argument MLPA1 BGP master start 13:10:24 Connect Socket: Operation timed out MLPA2 BGP master start 13:10:24 Connect Socket: Invalid argument MLPA3 BGP master start 13:12:51 OpenConfirm BGP Error: Hold timer expired MLPA4 BGP master start 13:10:24 Connect Socket: Invalid argument STATIC_BGP Static master up 13:10:06
All these BGP protocols are inherited from one template. The only difference is that those are established, use another source address which is configured on virtual interface.
However my question is how to find out what's going on and how to detect a problem? Setting "log syslog all;" is not very helpful - it only fills the log file with a lot of "bird6: KRT: Error sending route 2c0f:fb50::/0 to kernel: No such process" messages.
You can look at detailed protocol status via "show protocol [nam] all" You can enable appropriated level of per-protocol debug (e.g. add "debug { events, states };" to protocol config.
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
On 10.04.2014 10:14, Peter Andreev wrote:
Hi Alexander,
I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file. Interesting.
Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace:
GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `bird6'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000464a9e in add_tail (l=0x801017798, n=0x80102a650) at lists.c:46 46 z->next = n; [New Thread 801007400 (LWP 100292/bird6)] (gdb) bt #0 0x0000000000464a9e in add_tail (l=0x801017798, n=0x80102a650) at lists.c:46 #1 0x0000000000469ce6 in ralloc (p=0x801017780, c=0x692260) at resource.c:224 #2 0x000000000045c20a in tm_new (p=0x801017780) at io.c:226 #3 0x0000000000425bef in bgp_setup_conn (p=0x801008020, conn=0x8010081c8) at ../../../proto/bgp/bgp.c:631 #4 0x0000000000425d97 in bgp_active (p=0x801008020) at ../../../proto/bgp/bgp.c:660 #5 0x00000000004252cb in bgp_decision (vp=0x801008020) at ../../../proto/bgp/bgp.c:334 #6 0x000000000045bd67 in ev_run (e=0x801017800) at event.c:85 #7 0x000000000045be02 in ev_run_list (l=0x694aa0) at event.c:135 #8 0x000000000045f05f in io_loop () at io.c:1716 #9 0x00000000004669b3 in main (argc=3, argv=0x7fffffffdb20) at main.c:820 (gdb) quit
If this crash is interesting to you as port maintainer, I will provide any additional information which can help to understand why it happened. Yes, definitely.
Can you provide me with config, core file and a binary? Is this stock bird from 1.4.2, default options, no patches? Do you using gcc or clang to build and which version? How can one reproduce this scenario? Does the same config work on 1.3.10?
2014-04-09 23:10 GMT+04:00 Alexander V. Chernikov <melifaro@freebsd.org <mailto:melifaro@freebsd.org>>:
On 09.04.2014 13:36, Peter Andreev wrote: > Hi everybody,
Hello! > > I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the > following: > > bird> sh pro name proto table state since info > kernel1 Kernel master up 13:10:06 device1 Device master > up 13:10:06 NICbr1 BGP master up 13:10:28 > Established NICbr2 BGP master up 13:10:29 > Established PTTlg BGP master start 13:10:24 Connect > Socket: Invalid argument MLPA1 BGP master start 13:10:24 > Connect Socket: Operation timed out MLPA2 BGP master > start 13:10:24 Connect Socket: Invalid argument MLPA3 > BGP master start 13:12:51 OpenConfirm BGP Error: Hold > timer expired MLPA4 BGP master start 13:10:24 Connect > Socket: Invalid argument STATIC_BGP Static master up > 13:10:06 > > All these BGP protocols are inherited from one template. The only > difference is that those are established, use another source > address which is configured on virtual interface. > > However my question is how to find out what's going on and how to > detect a problem? Setting "log syslog all;" is not very helpful - > it only fills the log file with a lot of "bird6: KRT: Error sending > route 2c0f:fb50::/0 to kernel: No such process" messages. You can look at detailed protocol status via "show protocol [nam] all" You can enable appropriated level of per-protocol debug (e.g. add "debug { events, states };" to protocol config.
> > -- Is there any problem Exterminatus cannot solve? I have not found > one yet. >
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
2014-04-10 11:35 GMT+04:00 Alexander V. Chernikov <melifaro@freebsd.org>:
On 10.04.2014 10:14, Peter Andreev wrote:
Hi Alexander,
I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file. Interesting.
Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace:
GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `bird6'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000464a9e in add_tail (l=0x801017798, n=0x80102a650) at lists.c:46 46 z->next = n; [New Thread 801007400 (LWP 100292/bird6)] (gdb) bt #0 0x0000000000464a9e in add_tail (l=0x801017798, n=0x80102a650) at lists.c:46 #1 0x0000000000469ce6 in ralloc (p=0x801017780, c=0x692260) at resource.c:224 #2 0x000000000045c20a in tm_new (p=0x801017780) at io.c:226 #3 0x0000000000425bef in bgp_setup_conn (p=0x801008020, conn=0x8010081c8) at ../../../proto/bgp/bgp.c:631 #4 0x0000000000425d97 in bgp_active (p=0x801008020) at ../../../proto/bgp/bgp.c:660 #5 0x00000000004252cb in bgp_decision (vp=0x801008020) at ../../../proto/bgp/bgp.c:334 #6 0x000000000045bd67 in ev_run (e=0x801017800) at event.c:85 #7 0x000000000045be02 in ev_run_list (l=0x694aa0) at event.c:135 #8 0x000000000045f05f in io_loop () at io.c:1716 #9 0x00000000004669b3 in main (argc=3, argv=0x7fffffffdb20) at main.c:820 (gdb) quit
If this crash is interesting to you as port maintainer, I will provide any additional information which can help to understand why it happened. Yes, definitely.
Can you provide me with config, core file and a binary?
Ok. I'll send in private message.
Is this stock bird from 1.4.2, default options, no patches?
Stock bird, default options.
Do you using gcc or clang to build and which version?
/home/apn>cc -v Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD]
How can one reproduce this scenario?
My rc.conf: vlans_em2="10 20" ifconfig_em2_10="<some_ip>" ifconfig_em2_20_ipv6="<some_v6_ip>" ifconfig_em2="up"
Does the same config work on 1.3.10?
1.3.10 doesn't crash, but BGP sessions don't set up.
2014-04-09 23:10 GMT+04:00 Alexander V. Chernikov <melifaro@freebsd.org <mailto:melifaro@freebsd.org>>:
On 09.04.2014 13:36, Peter Andreev wrote: > Hi everybody,
Hello! > > I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the > following: > > bird> sh pro name proto table state since info > kernel1 Kernel master up 13:10:06 device1 Device master > up 13:10:06 NICbr1 BGP master up 13:10:28 > Established NICbr2 BGP master up 13:10:29 > Established PTTlg BGP master start 13:10:24 Connect > Socket: Invalid argument MLPA1 BGP master start 13:10:24 > Connect Socket: Operation timed out MLPA2 BGP master > start 13:10:24 Connect Socket: Invalid argument MLPA3 > BGP master start 13:12:51 OpenConfirm BGP Error: Hold > timer expired MLPA4 BGP master start 13:10:24 Connect > Socket: Invalid argument STATIC_BGP Static master up > 13:10:06 > > All these BGP protocols are inherited from one template. The only > difference is that those are established, use another source > address which is configured on virtual interface. > > However my question is how to find out what's going on and how to > detect a problem? Setting "log syslog all;" is not very helpful - > it only fills the log file with a lot of "bird6: KRT: Error sending > route 2c0f:fb50::/0 to kernel: No such process" messages. You can look at detailed protocol status via "show protocol [nam] all" You can enable appropriated level of per-protocol debug (e.g. add "debug { events, states };" to protocol config.
> > -- Is there any problem Exterminatus cannot solve? I have not found > one yet. >
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
On Thu, Apr 10, 2014 at 10:14:03AM +0400, Peter Andreev wrote:
Hi Alexander,
I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file.
Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace:
Do you have the same socket problems in 1.3.10 or not? -- 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."
2014-04-10 12:41 GMT+04:00 Ondrej Zajicek <santiago@crfreenet.org>:
On Thu, Apr 10, 2014 at 10:14:03AM +0400, Peter Andreev wrote:
Hi Alexander,
I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file.
Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace:
Do you have the same socket problems in 1.3.10 or not?
Yes, I have. I started with version 1.3.9, upgraded to 1.3.10 (which is the latest in ports tree) and at last I tried 1.4.2. All of them showed the same.
-- 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."
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlNGWSIACgkQw1GB2RHercOZYQCfVQKtNtDqNPyZ/GUVJWj4p31c LkUAn0DT2T7AViWET25WDkEtCiL0IURj =Z/KD -----END PGP SIGNATURE-----
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
On 10.04.2014 12:41, Ondrej Zajicek wrote:
On Thu, Apr 10, 2014 at 10:14:03AM +0400, Peter Andreev wrote:
Hi Alexander,
I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file.
Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace: Do you have the same socket problems in 1.3.10 or not?
We're currently investigating this further, it really looks like OS-dependent problem. However, it seems that core was triggered by uninitialized rta *a in IPv6 bgp_do_rx_update().
On Thu, Apr 10, 2014 at 09:44:57PM +0400, Alexander V. Chernikov wrote:
On 10.04.2014 12:41, Ondrej Zajicek wrote:
On Thu, Apr 10, 2014 at 10:14:03AM +0400, Peter Andreev wrote:
Hi Alexander,
I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file.
Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace: Do you have the same socket problems in 1.3.10 or not?
We're currently investigating this further, it really looks like OS-dependent problem. However, it seems that core was triggered by uninitialized rta *a in IPv6 bgp_do_rx_update().
Hmm, that seems like sime kind of strange coincidence, as the rta *a variable is not used before it is initialized (see attached patch). Perhaps it is related to the bug fixed in efd6d12b975441c7e1875a59dd9e0f3db7e958cb ? Are these compiler options used in FreeBSD build? -- 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 11.04.2014 13:16, Ondrej Zajicek wrote:
On Thu, Apr 10, 2014 at 09:44:57PM +0400, Alexander V. Chernikov wrote:
On 10.04.2014 12:41, Ondrej Zajicek wrote:
On Thu, Apr 10, 2014 at 10:14:03AM +0400, Peter Andreev wrote:
Hi Alexander,
I tried "debug MLPA1 all" from birdc console, but nothing new appeared in log file.
Currently I rolled back to 1.3.10 version from ports because 1.4.2 started to crash with the following backtrace: Do you have the same socket problems in 1.3.10 or not?
We're currently investigating this further, it really looks like OS-dependent problem. However, it seems that core was triggered by uninitialized rta *a in IPv6 bgp_do_rx_update(). Hmm, that seems like sime kind of strange coincidence, as the rta *a variable is not used before it is initialized (see attached patch). Well, not exactly. DECODE_PREFIX() can perform 'goto done' for invalid prefix being withdrawn. In that case we'll probably get garbage in a.
Anyway, initially I was talking about IPv6 case (which has different bgp_do_rx_update() version). The same there, DO_NLRI() can jump to 'done' label before *a initialization which actually happened. I suddenly realized that we're speaking about different crash cases: the one I'm talking about is much clearer: #0 0x000000000042fa37 in rta_free (r=0x40118adb8) at route.h:476 #1 0x000000000042f4c2 in bgp_do_rx_update (conn=0x801007dc8, withdrawn=0x801f3b015 "", withdrawn_len=0, nlri=0x801f3b055 "^�", nlri_len=0, attrs=0x801f3b017 "\220\017", attr_len=62) at ../../../proto/bgp/packets.c:1255 #2 0x000000000042fc04 in bgp_rx_update (conn=0x801007dc8, pkt=0x801f3b000 '�' <repeats 16 times>, len=85) at ../../../proto/bgp/packets.c:1304 #3 0x000000000043011e in bgp_rx_packet (conn=0x801007dc8, pkt=0x801f3b000 '�' <repeats 16 times>, len=85) at ../../../proto/bgp/packets.c:1525 #4 0x0000000000430283 in bgp_rx (sk=0x80101b140, size=85) at ../../../proto/bgp/packets.c:1570 #5 0x000000000045eb5a in sk_read (s=0x80101b140) at io.c:1602 #6 0x000000000045f5d4 in io_loop () at io.c:1843 #7 0x00000000004669b3 in main (argc=3, argv=0x7fffffffdb20) at main.c:820 (gdb) x/96xb pkt 0x801f3b000: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x801f3b008: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x801f3b010: 0x00 0x55 0x02 0x00 0x00 0x00 0x3e 0x90 0x801f3b018: 0x0f 0x00 0x3a 0x00 0x02 0x01 0x20 0x20 0x801f3b020: 0x01 0x1b 0xf8 0x30 0x2a 0x02 0x16 0xd8 0x801f3b028: 0x01 0x01 0x20 0x2a 0x00 0x17 0x80 0x30 0x801f3b030: 0x20 0x01 0x06 0x7c 0x23 0x2c 0x30 0x2a 0x801f3b038: 0x02 0x16 0xd8 0x01 0x03 0x20 0x2a 0x02 0x801f3b040: 0x16 0xd8 0x30 0x2a 0x02 0x16 0xd8 0x01 0x801f3b048: 0x02 0x20 0x28 0x00 0x06 0x70 0x30 0x2a 0x801f3b050: 0x02 0x16 0xd8 0x01 0x04 0x5e 0xab 0x00 0x801f3b058: 0x05 0xda 0xb7 0xc1 0x00 0x30 0x20 0x01 (gdb) p p->mp_reach_len $7 = 0 (gdb) p p->mp_unreach_len $8 = 58 DO_NLRI(mp_reach) is not used so "a" assignment does not happen. Btw, clang yells for both cases.
Perhaps it is related to the bug fixed in efd6d12b975441c7e1875a59dd9e0f3db7e958cb ? Are these compiler options used in FreeBSD build?
On Fri, Apr 11, 2014 at 07:03:21PM +0400, Alexander V. Chernikov wrote:
Hmm, that seems like sime kind of strange coincidence, as the rta *a variable is not used before it is initialized (see attached patch).
Well, not exactly. DECODE_PREFIX() can perform 'goto done' for invalid prefix being withdrawn. In that case we'll probably get garbage in a.
Anyway, initially I was talking about IPv6 case (which has different bgp_do_rx_update() version). The same there, DO_NLRI() can jump to 'done' label before *a initialization which actually happened.
I suddenly realized that we're speaking about different crash cases: the one I'm talking about is much clearer: .. DO_NLRI(mp_reach) is not used so "a" assignment does not happen.
You are right, in both cases. Thanks for debugging it. These are stupid mistakes. Seems like 1.4.1 was really not a lucky release. -- 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 Wed, Apr 09, 2014 at 01:36:31PM +0400, Peter Andreev wrote:
Hi everybody,
I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the following:
PTTlg BGP master start 13:10:24 Connect Socket: Invalid argument MLPA1 BGP master start 13:10:24 Connect Socket: Operation timed out MLPA2 BGP master start 13:10:24 Connect Socket: Invalid argument
All these BGP protocols are inherited from one template. The only difference is that those are established, use another source address which is configured on virtual interface.
However my question is how to find out what's going on and how to detect a problem? Setting "log syslog all;" is not very helpful - it only fills the log file with a lot of "bird6: KRT: Error sending route 2c0f:fb50::/0 to kernel: No such process" messages.
Hi Socket errors are usually errors reported by OS kernel related to TCP (for BGP) socket, so there is not much to debug in BIRD. You could add 'debug all' to that BGP protocols, but i would guess these errors are just reactions to connect() syscall. -- 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."
2014-04-10 12:24 GMT+04:00 Ondrej Zajicek <santiago@crfreenet.org>:
On Wed, Apr 09, 2014 at 01:36:31PM +0400, Peter Andreev wrote:
Hi everybody,
I'm trying to set up bird 1.4.2 on FreeBSD 9.1 and stuck on the following:
PTTlg BGP master start 13:10:24 Connect Socket: Invalid argument MLPA1 BGP master start 13:10:24 Connect Socket: Operation timed out MLPA2 BGP master start 13:10:24 Connect Socket: Invalid argument
All these BGP protocols are inherited from one template. The only difference is that those are established, use another source address which is configured on virtual interface.
However my question is how to find out what's going on and how to detect a problem? Setting "log syslog all;" is not very helpful - it only fills the log file with a lot of "bird6: KRT: Error sending route 2c0f:fb50::/0 to kernel: No such process" messages.
Hi
Socket errors are usually errors reported by OS kernel related to TCP (for BGP) socket, so there is not much to debug in BIRD. You could add 'debug all' to that BGP protocols, but i would guess these errors are just reactions to connect() syscall.
You're right, there is no much info.
-- 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."
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlNGVSIACgkQw1GB2RHercPDXACfWRI/aRzF7INqmLswP8HM+vp6 RccAnRCqcPwcav02cMj/XgMk/Xg1aa7r =0JRZ -----END PGP SIGNATURE-----
-- Is there any problem Exterminatus cannot solve? I have not found one yet.
participants (4)
-
Alexander V. Chernikov -
Alexander V. Chernikov -
Ondrej Zajicek -
Peter Andreev