[cmaster-next] stable/2.0 / initial delay before BGP availability through vty
Hi Donald, I have 2 questions/remarks. 1) Is there any specific reason why having kept the delay just after starting BGP daemon. Even with disabling zebra in configure, it takes quite some time. The root cause is related to: lib: Allow zclient do-over of connect on initial attempt Is there any reason to keep the mecanism like that ? Side effect of this is if you just execute bgp daemon and expect it to be available for configuration, either from vty ( or in a near-future basis capnproto), then the locked thread mecanism makes that it is not possible to immediately configure daemon. I would revert the commit. No ? 2) About this trace BGP: SLOW THREAD: task zclient_connect As this trace may happen more than once, is it necessary to add by default that I would put a conditionate to that trace. Regards, Philippe =================================== /sbin/bgpd 2016/12/08 17:33:55 BGP: BGPd 2.0-rc0 starting: vty@2605, bgp@<all>:179 2016/12/08 17:33:55 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:56 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:57 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:58 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:59 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:00 BGP: SLOW THREAD: task zclient_connect (7fa0e93c0cbc) ran for 5002ms (cpu time 0ms) 2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:01 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:02 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:03 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:04 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:05 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:05 BGP: SLOW THREAD: task zclient_connect (7fa0e93c0cbc) ran for 5000ms (cpu time 0ms) => Just at this point, VTY access OK
I've opened issue #10 to track this On Fri, Dec 9, 2016 at 1:57 AM, Philippe Guibert <philippe.guibert@6wind.com> wrote:
Hi Donald,
I have 2 questions/remarks.
1) Is there any specific reason why having kept the delay just after starting BGP daemon. Even with disabling zebra in configure, it takes quite some time.
The root cause is related to: lib: Allow zclient do-over of connect on initial attempt
Is there any reason to keep the mecanism like that ? Side effect of this is if you just execute bgp daemon and expect it to be available for configuration, either from vty ( or in a near-future basis capnproto), then the locked thread mecanism makes that it is not possible to immediately configure daemon. I would revert the commit. No ?
2) About this trace BGP: SLOW THREAD: task zclient_connect
As this trace may happen more than once, is it necessary to add by default that I would put a conditionate to that trace.
Regards,
Philippe
===================================
/sbin/bgpd 2016/12/08 17:33:55 BGP: BGPd 2.0-rc0 starting: vty@2605, bgp@<all>:179 2016/12/08 17:33:55 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:56 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:57 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:58 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:33:59 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:00 BGP: SLOW THREAD: task zclient_connect (7fa0e93c0cbc) ran for 5002ms (cpu time 0ms) 2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:01 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:02 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:03 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:04 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:05 BGP: zclient_socket_un connect failure: 2 2016/12/08 17:34:05 BGP: SLOW THREAD: task zclient_connect (7fa0e93c0cbc) ran for 5000ms (cpu time 0ms)
=> Just at this point, VTY access OK
participants (2)
-
Donald Sharp -
Philippe Guibert