How to determine when reconfiguration is complete?
Hi! How can I tell when bird is done with reconfiguration? E.g. bird can respond: "Reconfiguration in progress", but how do you know when it is ready? Invoking configure again will trigger full re-configure again I guess? Thanks, Kenth
Hello Kenth, What I do on my Bird 1.6.4 install is run `ip r | wc -l` and check if I have a full table in the kernel routing table. A second method I use is check if the Bird process doesn't use a single CPU core anymore. I use htop for this, but other cli monitoring tools could be used too. A line in the logging would be useful indeed :). Kind regards, Cybertinus On 2019-06-04 18:31, Kenth Eriksson wrote:
Hi!
How can I tell when bird is done with reconfiguration? E.g. bird can respond: "Reconfiguration in progress", but how do you know when it is ready? Invoking configure again will trigger full re-configure again I guess?
Thanks, Kenth
On Tue, Jun 04, 2019 at 09:04:39PM +0200, Cybertinus wrote:
Hi!
How can I tell when bird is done with reconfiguration? E.g. bird can respond: "Reconfiguration in progress", but how do you know when it is ready? Invoking configure again will trigger full re-configure again I guess?
Hi Yes, if you do configre again while in progress, then re-configure request is queued.
Hello Kenth,
A line in the logging would be useful indeed :).
I do not know about interactive way, but there is a line in the log about that: 2019-06-05 01:40:57.531 <INFO> Reconfiguring 2019-06-05 01:40:57.531 <TRACE> device1: Reconfigured 2019-06-05 01:40:57.531 <TRACE> direct1: Reconfigured 2019-06-05 01:40:57.531 <TRACE> bgp1: Reconfigured 2019-06-05 01:40:57.531 <INFO> Reconfigured The first line means reconfiguration started, the last line means it is finished. There may still be some asynchronous work running (like re-evaluating filters on routes if they were changed), but for all purposes the new config is active and BIRD is in regular state. -- 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 Tue, Jun 4, 2019 at 9:08 PM Cybertinus <bird@cybertinus.nl> wrote:
What I do on my Bird 1.6.4 install is run `ip r | wc -l` and check if I have a full table in the kernel routing table. A second method I use is check if the Bird process doesn't use a single CPU core anymore. I use htop for this, but other cli monitoring tools could be used too.
Funny, we're doing pretty much the same, even automated, to only enable BGP towards inside clients (and send them a default route) once a full table has been received. For an efficient implementation, as "ip r" takes quite a while with a full table, we found that there's a nice compount counter in /proc/net/fib_triestat (Prefixes), which is what we actually use. best regards Patrick
On Wed, 2019-06-05 at 07:22 +0200, Patrick Schaaf wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Tue, Jun 4, 2019 at 9:08 PM Cybertinus <bird@cybertinus.nl> wrote:
What I do on my Bird 1.6.4 install is run `ip r | wc -l` and check if I have a full table in the kernel routing table. A second method I use is check if the Bird process doesn't use a single CPU core anymore. I use htop for this, but other cli monitoring tools could be used too.
Funny, we're doing pretty much the same, even automated, to only enable BGP towards inside clients (and send them a default route) once a full table has been received.
For an efficient implementation, as "ip r" takes quite a while with a full table, we found that there's a nice compount counter in /proc/net/fib_triestat (Prefixes), which is what we actually use.
best regards Patrick
Thanks for your proposals, but we need a robust machine interface to check the re-configuration status. I will propose a patch.
This adds the CLI command 'configure status' so that it is possible to check if reconfiguration is done. Signed-off-by: Kenth Eriksson <kenth.eriksson@infinera.com> --- conf/conf.c | 6 ++++++ conf/conf.h | 1 + sysdep/unix/config.Y | 3 +++ sysdep/unix/main.c | 7 +++++++ sysdep/unix/unix.h | 1 + 5 files changed, 18 insertions(+) diff --git a/conf/conf.c b/conf/conf.c index 439aa41d..1905da8d 100644 --- a/conf/conf.c +++ b/conf/conf.c @@ -444,6 +444,12 @@ config_undo(void) return CONF_PROGRESS; } +int +config_status(void) +{ + return configuring? CONF_PROGRESS : CONF_DONE; +} + extern void cmd_reconfig_undo_notify(void); static void diff --git a/conf/conf.h b/conf/conf.h index 427569fd..e5998146 100644 --- a/conf/conf.h +++ b/conf/conf.h @@ -68,6 +68,7 @@ void config_free(struct config *); int config_commit(struct config *, int type, uint timeout); int config_confirm(void); int config_undo(void); +int config_status(void); void config_init(void); void cf_error(const char *msg, ...) NORET; void config_add_obstacle(struct config *); diff --git a/sysdep/unix/config.Y b/sysdep/unix/config.Y index e7ecd735..8ad7da60 100644 --- a/sysdep/unix/config.Y +++ b/sysdep/unix/config.Y @@ -124,6 +124,9 @@ CF_CLI(CONFIGURE CONFIRM,,, [[Confirm last configuration change - deactivate und CF_CLI(CONFIGURE UNDO,,, [[Undo last configuration change]]) { cmd_reconfig_undo(); } ; +CF_CLI(CONFIGURE STATUS,,, [[Show configuration status]]) +{ cmd_reconfig_status(); } ; + CF_CLI(CONFIGURE CHECK, cfg_name, [\"<file>\"], [[Parse configuration and check its validity]]) { cmd_check_config($3); } ; diff --git a/sysdep/unix/main.c b/sysdep/unix/main.c index 921115b1..73f5d4f1 100644 --- a/sysdep/unix/main.c +++ b/sysdep/unix/main.c @@ -339,6 +339,13 @@ cmd_reconfig_undo(void) cmd_reconfig_msg(r); } +void +cmd_reconfig_status(void) +{ + int r = config_status(); + cmd_reconfig_msg(r); +} + /* * Command-Line Interface */ diff --git a/sysdep/unix/unix.h b/sysdep/unix/unix.h index 0e1e98c0..d5ce8ff9 100644 --- a/sysdep/unix/unix.h +++ b/sysdep/unix/unix.h @@ -26,6 +26,7 @@ void cmd_check_config(char *name); void cmd_reconfig(char *name, int type, uint timeout); void cmd_reconfig_confirm(void); void cmd_reconfig_undo(void); +void cmd_reconfig_status(void); void cmd_shutdown(void); #define UNIX_DEFAULT_CONFIGURE_TIMEOUT 300 -- 2.21.0
On Tue, Jun 11, 2019 at 02:58:33PM +0200, Kenth Eriksson wrote:
This adds the CLI command 'configure status' so that it is possible to check if reconfiguration is done.
Hi We could add this feature, but it should also report more cases (the submitted patch covers just first two): - progress - done - progress+queued - config timeout running Also i am not 100% sure if separate 'configure status' command is necessary, perhaps it could be part of 'show status'. But i have no strong strong feeling one way or the other. -- 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 Tue, 2019-06-11 at 15:42 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Tue, Jun 11, 2019 at 02:58:33PM +0200, Kenth Eriksson wrote:
This adds the CLI command 'configure status' so that it is possible to check if reconfiguration is done.
Hi
We could add this feature, but it should also report more cases (the submitted patch covers just first two):
- progress - done - progress+queued - config timeout running
The first two could be added without any refactoring. I'm not sure the latter two can be done without some refactoring. But I can revisit later and see if it is possible. But at least having progress and done solves many issues since we want to know when reconfiguration is complete. Are you willing to let it go upstream with only the first two included?
Also i am not 100% sure if separate 'configure status' command is necessary, perhaps it could be part of 'show status'. But i have no strong strong feeling one way or the other.
Would prefer 'configure status', it makes sense to keep configure request command and its status together. Also the 'show status' is composed of lots of other stuff, making it harder to parse out when remote controlling bird.
-- 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, Jun 12, 2019 at 11:08:36AM +0000, Kenth Eriksson wrote:
Hi
We could add this feature, but it should also report more cases (the submitted patch covers just first two):
- progress - done - progress+queued - config timeout running
The first two could be added without any refactoring. I'm not sure the latter two can be done without some refactoring. But I can revisit later and see if it is possible. But at least having progress and done solves many issues since we want to know when reconfiguration is complete. Are you willing to let it go upstream with only the first two included?
Hi I do not like merging partial implementations and revisiting that later, as that often means changing user-visible behavior of existing features, which is something we try to avoid. Therefore, i just finished it [*]. Also, i did not use messages from cmd_reconfig_msg(), as these are appropriate as answers to requests, but not as status reports. But used the same reply codes, to ease parsing. [*] see commit 9106a750cd76d4a76c7a60294ce3a43eede166c9
Also i am not 100% sure if separate 'configure status' command is necessary, perhaps it could be part of 'show status'. But i have no strong strong feeling one way or the other.
Would prefer 'configure status', it makes sense to keep configure request command and its status together. Also the 'show status' is composed of lots of other stuff, making it harder to parse out when remote controlling bird.
OK -- 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, 2019-06-12 at 17:26 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, Jun 12, 2019 at 11:08:36AM +0000, Kenth Eriksson wrote:
Hi
We could add this feature, but it should also report more cases (the submitted patch covers just first two):
- progress - done - progress+queued - config timeout running
The first two could be added without any refactoring. I'm not sure the latter two can be done without some refactoring. But I can revisit later and see if it is possible. But at least having progress and done solves many issues since we want to know when reconfiguration is complete. Are you willing to let it go upstream with only the first two included?
Hi
I do not like merging partial implementations and revisiting that later, as that often means changing user-visible behavior of existing features, which is something we try to avoid.
Therefore, i just finished it [*]. Also, i did not use messages from cmd_reconfig_msg(), as these are appropriate as answers to requests, but not as status reports. But used the same reply codes, to ease parsing.
[*] see commit 9106a750cd76d4a76c7a60294ce3a43eede166c9
Thanks for completing my rudimentary patch! The reply text for reply code 3 (CONF_DONE) is "Daemon is up and running". Is that on purpose? I would have expected something like "Re-configuration done" or similar.
Also i am not 100% sure if separate 'configure status' command is necessary, perhaps it could be part of 'show status'. But i have no strong strong feeling one way or the other.
Would prefer 'configure status', it makes sense to keep configure request command and its status together. Also the 'show status' is composed of lots of other stuff, making it harder to parse out when remote controlling bird.
OK
-- 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 Thu, Jun 13, 2019 at 11:29:32AM +0000, Kenth Eriksson wrote:
The reply text for reply code 3 (CONF_DONE) is "Daemon is up and running". Is that on purpose? I would have expected something like "Re-configuration done" or similar.
Yes, because the same message is reported after start, when there is no previous reconfiguration. Therefore "Re-configuration done" would be confusing. -- 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, 2019-06-12 at 17:26 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Therefore, i just finished it [*]. Also, i did not use messages from cmd_reconfig_msg(), as these are appropriate as answers to requests, but not as status reports. But used the same reply codes, to ease parsing.
[*] see commit 9106a750cd76d4a76c7a60294ce3a43eede166c9
Noticed an issue with the code in this commit; it omits the reply code if it was preceded by a configure command. Consider the following; bird> configure 0002-Reading configuration from /usr/local/src/BUILD/HOST/x86/etc/bird.conf 0003 Reconfigured bird> configure status Daemon is up and running bird> configure status 0003-Daemon is up and running bird>
On Mon, 2019-11-25 at 16:02 +0000, Kenth Eriksson wrote:
On Wed, 2019-06-12 at 17:26 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Therefore, i just finished it [*]. Also, i did not use messages from cmd_reconfig_msg(), as these are appropriate as answers to requests, but not as status reports. But used the same reply codes, to ease parsing.
[*] see commit 9106a750cd76d4a76c7a60294ce3a43eede166c9
Noticed an issue with the code in this commit; it omits the reply code if it was preceded by a configure command. Consider the following;
bird> configure 0002-Reading configuration from /usr/local/src/BUILD/HOST/x86/etc/bird.conf 0003 Reconfigured bird> configure status Daemon is up and running bird> configure status 0003-Daemon is up and running bird>
I believe reply code issue is caused by the following lines since reply code 3 is used twice... if (cd == c->last_reply) size = bsprintf(buf, " "); else size = bsprintf(buf, "%04d-", cd);
On Mon, Nov 25, 2019 at 04:26:45PM +0000, Kenth Eriksson wrote:
On Mon, 2019-11-25 at 16:02 +0000, Kenth Eriksson wrote:
On Wed, 2019-06-12 at 17:26 +0200, Ondrej Zajicek wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Therefore, i just finished it [*]. Also, i did not use messages from cmd_reconfig_msg(), as these are appropriate as answers to requests, but not as status reports. But used the same reply codes, to ease parsing.
[*] see commit 9106a750cd76d4a76c7a60294ce3a43eede166c9
Noticed an issue with the code in this commit; it omits the reply code if it was preceded by a configure command. Consider the following;
bird> configure 0002-Reading configuration from /usr/local/src/BUILD/HOST/x86/etc/bird.conf 0003 Reconfigured bird> configure status Daemon is up and running bird> configure status 0003-Daemon is up and running bird>
I believe reply code issue is caused by the following lines since reply code 3 is used twice...
if (cd == c->last_reply) size = bsprintf(buf, " "); else size = bsprintf(buf, "%04d-", cd);
Thanks, you are right. I will check this. -- 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 Tue, 2019-11-26 at 15:59 +0100, Ondrej Zajicek wrote:
I believe reply code issue is caused by the following lines since reply code 3 is used twice...
if (cd == c->last_reply) size = bsprintf(buf, " "); else size = bsprintf(buf, "%04d-", cd);
Thanks, you are right. I will check this.
Thanks, please let me know when you have a proposed fix for this. /k
On Mon, Dec 02, 2019 at 07:30:27AM +0000, Kenth Eriksson wrote:
On Tue, 2019-11-26 at 15:59 +0100, Ondrej Zajicek wrote:
I believe reply code issue is caused by the following lines since reply code 3 is used twice...
if (cd == c->last_reply) size = bsprintf(buf, " "); else size = bsprintf(buf, "%04d-", cd);
Thanks, you are right. I will check this.
Thanks, please let me know when you have a proposed fix for this.
Already fixed, sorry for not noticing you: https://gitlab.labs.nic.cz/labs/bird/commit/d033e6327d1e63f5d212981fca785b50... -- 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 Mon, 2019-12-02 at 12:08 +0100, Ondrej Zajicek wrote:
Thanks, please let me know when you have a proposed fix for this.
Already fixed, sorry for not noticing you:
Thanks for the patch. Can confirm it resolves issue.
participants (5)
-
Cybertinus -
Kenth Eriksson -
Kenth Eriksson
-
Ondrej Zajicek -
Patrick Schaaf