Hi list, We've upgraded to 2.0.3 (from 1.6.3) and observed that the number of exported routes shown in the protocol details ('show protocol all') does not match (by large) these show in 'show route export PROTOCOL count'. In the below example we can see that the protocol export counters are at some crazy values. # birdc show proto all DIACONESCU_V4 | grep exported Routes: 16 imported, 0 filtered, 4294965736 exported While we actually export only 3 routes. # birdc show route export DIACONESCU_V4 count BIRD 2.0.3 ready. 3 of 726536 routes for 724797 networks in table main4. Now, what is interesting is that the exported count changes periodically. i.e. Routes: 16 imported, 0 filtered, 4294967283 exported Routes: 16 imported, 0 filtered, 4294967293 exported At this stage I believe this is related to protocols that export a only a few routes (rather than full tables). I've been able to reproduce this in lab using the production config and then ran the following tests: 1) changing export to none, reconfigure - did not clear the counters - looking at the code counters are reset on refeed, so perhaps that does not happen here 2) disabling and enabling the protocol - it briefly shows the correct count (3) and then goes back to a crazy number almost immediately. 3) restarting bird - the counters clear up and then some random time later the crazy number pops up again. Has anyone else on the list experienced this? I'd be happy to provide more info if needed, but at the moment not really sure what to make out of it. Also, can I ask why the preferred routes were removed from the protocol summary in bird 2 i.e. the below? Routes: 722830 imported, 0 filtered, 1 exported, 3648 preferred
On Fri, Feb 01, 2019 at 03:12:12PM +0200, michal.nowak@lnk.ro wrote:
Hi list,
We've upgraded to 2.0.3 (from 1.6.3) and observed that the number of exported routes shown in the protocol details ('show protocol all') does not match (by large) these show in 'show route export PROTOCOL count'.
In the below example we can see that the protocol export counters are at some crazy values. ... Has anyone else on the list experienced this?
Hi This is likely just integer overflow during counter decrease, it is mostly harmless. We will see how to fix it.
I'd be happy to provide more info if needed, but at the moment not really sure what to make out of it.
Also, can I ask why the preferred routes were removed from the protocol summary in bird 2 i.e. the below?
Well, it did not fit into the new design (stats are now per-channel, while pref counter as defined in 1.6.x was bound to per-protocol stats). It was also a bit confusing and meant something different than people expected, so we get repeated questions about it. But more people wanted it back and it seems that we can redefine it to both fit to per-channel stats and be less confusing (by counting best routes in adjacent routing table only), so it is back in the devel code in git, with slightly different meaning. -- 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 Sat, Feb 02, 2019 at 02:50:39PM +0300, Ondrej Zajicek wrote:
This is likely just integer overflow during counter decrease, it is mostly harmless. We will see how to fix it.
Hi Ondrej, thanks for quick response, and yes I agree that its mostly harmless, yet it upsets our monitoring, so I need to get to the bottom of it at some point.
But more people wanted it back and it seems that we can redefine it to both fit to per-channel stats and be less confusing (by counting best routes in adjacent routing table only), so it is back in the devel code in git, with slightly different meaning.
OK, I see that commit, but that would not display preferred counters if the 'keep filtered' is enabled on a given protocol. if (c->in_keep_filtered) cli_msg(-1006, " Routes: %u imported, %u filtered, %u exported", s->imp_routes, s->filt_routes, s->exp_routes); else cli_msg(-1006, " Routes: %u imported, %u exported, %u preferred", s->imp_routes, s->exp_routes, s->pref_routes); My preference would be to print out all the 4 counters (including 0 for filtered if disabled), and the rationale behind this idea is that this would allow for at least some degree of backwards compatibility with scripts that used to parse the Routes line in bird 1.6 deployments, which again for reference used to look like this: Routes: 0 imported, 0 filtered, 0 exported, 0 preferred So perhaps something among the lines of the below would be acceptable: diff --git a/nest/proto.c b/nest/proto.c index ab92d90..a68302d 100644 --- a/nest/proto.c +++ b/nest/proto.c @@ -1692,12 +1692,8 @@ channel_show_stats(struct channel *c) { struct proto_stats *s = &c->stats; - if (c->in_keep_filtered) - cli_msg(-1006, " Routes: %u imported, %u filtered, %u exported", - s->imp_routes, s->filt_routes, s->exp_routes); - else - cli_msg(-1006, " Routes: %u imported, %u exported, %u preferred", - s->imp_routes, s->exp_routes, s->pref_routes); + cli_msg(-1006, " Routes: %u imported, %u filtered, %u exported, %u preferred", + s->imp_routes, s->filt_routes, s->exp_routes, s->pref_routes); cli_msg(-1006, " Route change stats: received rejected filtered ignored accepted"); Let me know what you think. cli_msg(-1006, " Import updates: %10u %10u %10u %10u %10u",
On Sun, Feb 03, 2019 at 09:14:21AM +0200, michal.nowak@lnk.ro wrote:
On Sat, Feb 02, 2019 at 02:50:39PM +0300, Ondrej Zajicek wrote:
This is likely just integer overflow during counter decrease, it is mostly harmless. We will see how to fix it.
Hi Ondrej, thanks for quick response, and yes I agree that its mostly harmless, yet it upsets our monitoring, so I need to get to the bottom of it at some point.
But more people wanted it back and it seems that we can redefine it to both fit to per-channel stats and be less confusing (by counting best routes in adjacent routing table only), so it is back in the devel code in git, with slightly different meaning.
OK, I see that commit, but that would not display preferred counters if the 'keep filtered' is enabled on a given protocol.
Thanks, that was oversight.
if (c->in_keep_filtered) cli_msg(-1006, " Routes: %u imported, %u filtered, %u exported", s->imp_routes, s->filt_routes, s->exp_routes); else cli_msg(-1006, " Routes: %u imported, %u exported, %u preferred", s->imp_routes, s->exp_routes, s->pref_routes);
My preference would be to print out all the 4 counters (including 0 for filtered if disabled), and the rationale behind this idea is that this would allow for at least some degree of backwards compatibility with scripts that used to parse the Routes line in bird 1.6 deployments, which again for reference used to look like this:
No, BIRD 1.6.x does not print out 'filtered' when 'keep filtered' is disabled. So for compatibility it would make sense to not print it either. Also reporting 0 does not make sense as there may be routes that were filtered, we just do not have information to know how many. -- 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, Feb 05, 2019 at 04:35:02PM +0300, Ondrej Zajicek wrote:
No, BIRD 1.6.x does not print out 'filtered' when 'keep filtered' is disabled. So for compatibility it would make sense to not print it either. Also reporting 0 does not make sense as there may be routes that were filtered, we just do not have information to know how many.
Hi Ondrej, I stand corrected - thanks and sure thats perfectly fine.
On Fri, Feb 01, 2019 at 03:12:12PM +0200, michal.nowak@lnk.ro wrote:
We've upgraded to 2.0.3 (from 1.6.3) and observed that the number of exported routes shown in the protocol details ('show protocol all') does not match (by large) these show in 'show route export PROTOCOL count'.
Hi I would be glad if you could try the version from git master branch (commit 6e8fb66859a17b295cd9246264221a75cdbe6c55). It should fix the export number issue (at least to the pre-2.0.3/1.6.5 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."
Hi Ondrej,
From which URL can I fetch the code at this commit? The “download” link on https://gitlab.labs.nic.cz/labs/bird/commit/6e8fb66859a17b295cd9246264221a75... is disabled.
-- Alarig
On Wed, Feb 06, 2019 at 11:39:52AM +0100, Alarig Le Lay wrote:
Hi Ondrej,
From which URL can I fetch the code at this commit? The “download” link on https://gitlab.labs.nic.cz/labs/bird/commit/6e8fb66859a17b295cd9246264221a75... is disabled.
Here should be enabled: https://gitlab.labs.nic.cz/labs/bird/tree/master -- 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."
It looks good from there too: asbr01-lab /usr/local/src/bird # birdc -s /run/bird.ctl BIRD v2.0.3-12-g6e8fb668 ready. bird> show protocols all "ospf_*" Name Proto Table State Since Info ospf_ipv4 OSPF master4 up 15:16:22.978 Running Channel ipv4 State: UP Table: master4 Preference: 150 Input filter: (unnamed) Output filter: (unnamed) Import limit: 200 Action: block Routes: 63 imported, 0 filtered, 18 exported, 54 preferred Route change stats: received rejected filtered ignored accepted Import updates: 64 0 0 0 64 Import withdraws: 0 0 --- 0 0 Export updates: 912303 54 912231 --- 18 Export withdraws: 12 --- --- --- 0 ospf_ipv6 OSPF master6 up 15:16:22.978 Running Channel ipv6 State: UP Table: master6 Preference: 150 Input filter: (unnamed) Output filter: (unnamed) Import limit: 200 Action: block Routes: 18 imported, 0 filtered, 20 exported, 9 preferred Route change stats: received rejected filtered ignored accepted Import updates: 19 0 0 0 19 Import withdraws: 0 0 --- 0 0 Export updates: 170858 9 170829 --- 20 Export withdraws: 71 --- --- --- 0 bird> It’s not related to OSPF, but there is an error in INSTALL: asbr01-lab /usr/local/src # git clone https://gitlab.labs.nic.cz/labs/bird.git asbr01-lab /usr/local/src # cd bird/ asbr01-lab /usr/local/src/bird # git checkout 6e8fb66859a17b295cd9246264221a75cdbe6c55 asbr01-lab /usr/local/src/bird # cat INSTALL […] Default location for configuration file is /usr/local/etc/bird.conf and for control socket is /usr/local/var/run/bird.ctl . You can change that by --prefix, --sysconfdir and --runstatedir configure options, e.g.: $ ./configure --prefix=/usr --sysconfdir=/etc --runstatedir=/run […] asbr01-lab /usr/local/src/bird # autoreconf asbr01-lab /usr/local/src/bird # ./configure --prefix=/usr --sysconfdir=/etc --runstatedir=/run configure: error: unrecognized option: `--runstatedir=/run' Try `./configure --help' for more information asbr01-lab /usr/local/src/bird # ./configure --prefix=/usr --sysconfdir=/etc checking for gcc... gcc checking whether the C compiler works... yes […] -- Alarig
On Wed, Feb 06, 2019 at 03:21:41PM +0100, Alarig Le Lay wrote:
It looks good from there too: asbr01-lab /usr/local/src/bird # birdc -s /run/bird.ctl BIRD v2.0.3-12-g6e8fb668 ready.
It’s not related to OSPF, but there is an error in INSTALL: asbr01-lab /usr/local/src # git clone https://gitlab.labs.nic.cz/labs/bird.git asbr01-lab /usr/local/src # cd bird/ asbr01-lab /usr/local/src/bird # git checkout 6e8fb66859a17b295cd9246264221a75cdbe6c55 asbr01-lab /usr/local/src/bird # cat INSTALL […] Default location for configuration file is /usr/local/etc/bird.conf and for control socket is /usr/local/var/run/bird.ctl . You can change that by --prefix, --sysconfdir and --runstatedir configure options, e.g.:
$ ./configure --prefix=/usr --sysconfdir=/etc --runstatedir=/run […] asbr01-lab /usr/local/src/bird # autoreconf asbr01-lab /usr/local/src/bird # ./configure --prefix=/usr --sysconfdir=/etc --runstatedir=/run configure: error: unrecognized option: `--runstatedir=/run'
This depends on version/variant of autoconf tools. Older ones do not support --runstatedir. INSTALL instructions are intended for released tar.gz source, which contains configure generated by proper autoconf version. AFAIK autoconf in Debian Stable (and newer) is 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 mer. 6 févr. 15:51:56 2019, Ondrej Zajicek wrote:
This depends on version/variant of autoconf tools. Older ones do not support --runstatedir. INSTALL instructions are intended for released tar.gz source, which contains configure generated by proper autoconf version.
AFAIK autoconf in Debian Stable (and newer) is OK.
I used 2.69, it’s the last in the Gentoo tree. -- Alarig
On Wed, Feb 06, 2019 at 04:01:27PM +0100, Alarig Le Lay wrote:
On mer. 6 févr. 15:51:56 2019, Ondrej Zajicek wrote:
This depends on version/variant of autoconf tools. Older ones do not support --runstatedir. INSTALL instructions are intended for released tar.gz source, which contains configure generated by proper autoconf version.
AFAIK autoconf in Debian Stable (and newer) is OK.
I used 2.69, it’s the last in the Gentoo tree.
Unfortunately, last official release of Autoconf is more than 6 years old, so distributions backport important patches (like one for option --runstatedir, which is used by multiple software packages since /var/run was moved to /run) to their versions. -- 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."
Hi Ondrej, thanks for both the fixes - they appear to be working as intended in the lab. I will come back with definite confirmation to you once we upgrade production (sometime in March). ----- Original Message ----- From: "Ondrej Zajicek" <santiago@crfreenet.org> To: "michal nowak" <michal.nowak@lnk.ro>, "Alarig Le Lay" <alarig@swordarmor.fr> Cc: "bird-users" <bird-users@network.cz> Sent: Wednesday, February 6, 2019 3:16:06 AM Subject: Re: route export number discrepancy On Fri, Feb 01, 2019 at 03:12:12PM +0200, michal.nowak@lnk.ro wrote:
We've upgraded to 2.0.3 (from 1.6.3) and observed that the number of exported routes shown in the protocol details ('show protocol all') does not match (by large) these show in 'show route export PROTOCOL count'.
Hi I would be glad if you could try the version from git master branch (commit 6e8fb66859a17b295cd9246264221a75cdbe6c55). It should fix the export number issue (at least to the pre-2.0.3/1.6.5 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." -- Acest e-mail și orice fișier atașat sunt trimise de către LNK Systems Muntenia SRL. Acest mesaj conține informații care pot fi confidențiale sau privilegiate. Dacă nu sunteți persoana sau destinatarul mesajului, este interzisă folosirea, copierea, răspândirea sau divulgarea oricărei informații conținută în mesaj. Dacă ați primit acest mesaj dintr-o eroare, sunteți rugat să anunțați persoana care l-a trimis și apoi să ștergeți mesajul. Datorită faptului că informația poate fi interceptată, coruptă, pierdută, distrusă, incompletă sau poate să conțină viruși nu putem garanta transmiterea sigura si fara erori a e-mailului. Expeditorul nu poate fi tras la raspundere pentru orice omisiune din continutul acestui mesaj care deriva din transmiterea e-mailului. This email and any attached files are sent from LNK Systems Muntenia SRL. This message contains information which may be confidential and legally privileged. Unless you are the intended, you may not use, copy, distribute, disseminate, reproduce or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message. Email transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or contain viruses. The sender therefore is in no way liable for any errors or omissions in the content of this message, which may arise as a result of email transmission.
participants (3)
-
Alarig Le Lay -
michal.nowak＠lnk.ro -
Ondrej Zajicek