Syntax for show route and primary route (*)?
Hi! When showing routing table, the output can have '*', '!' or empty depending on the route. I thought that the asterisk ('*') meant that the route is a primary route installed into the kernel. But this does not seem to always be true, e.g. consider the following: bird> show route 0.0.0.0/0 Table master4: 0.0.0.0/0 unicast [kernel1 2019-10-22] (215) via 10.210.137.1 on eth1 bird> show route ::0/0 Table master6: ::/0 unicast [static_ipv6 2019-10-22] * (255) via 2a02:1420:1:137::1 on eth1 bird> Why does the default route for IPv6 have a '*' but not for IPv4? Another example where a route pushed to the kernel is not having the '*' mark; bird> show route 10.210.138.64/30 Table master4: 10.210.138.64/30 unicast [ospfv2_1 16:50:34.613] I (145/20) [10.210.138.65] via 10.210.138.66 on p1-2-9-10g0 bird> q ~ # route | grep 10.210.138.64 10.210.138.64 10.210.138.66 255.255.255.252 UG 32 0 0 p1-2-9-10g0 ~ # Thanks, Kenth
Signed-off-by: Kenth Eriksson <kenth.eriksson@infinera.com> --- nest/rt-show.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nest/rt-show.c b/nest/rt-show.c index c7bcdf2f..3304cd5e 100644 --- a/nest/rt-show.c +++ b/nest/rt-show.c @@ -34,7 +34,7 @@ rt_show_rte(struct cli *c, byte *ia, rte *e, struct rt_show_data *d) byte from[IPA_MAX_TEXT_LENGTH+8]; byte tm[TM_DATETIME_BUFFER_SIZE], info[256]; rta *a = e->attrs; - int primary = (e->net->routes == e); + int primary = e->u.krt.best; int sync_error = (e->net->n.flags & KRF_SYNC_ERROR); void (*get_route_info)(struct rte *, byte *buf); struct nexthop *nh; -- 2.21.0
On Wed, Oct 23, 2019 at 09:11:31AM +0000, Kenth Eriksson wrote:
Hi!
When showing routing table, the output can have '*', '!' or empty depending on the route. I thought that the asterisk ('*') meant that the route is a primary route installed into the kernel. But this does not seem to always be true, e.g.
Hi The asterisk means the route is selected as best (i.e. is the first of routes for the same network). This does not mean that the route is exported to kernel. For example in route reflectors / route servers, a route is selected as best and propagated to BGP peers, but no Kernel protocol is configured. But i do not understand the cases below, where there is no other route for that network and the only route does not have asterisk.
consider the following:
bird> show route 0.0.0.0/0 Table master4: 0.0.0.0/0 unicast [kernel1 2019-10-22] (215) via 10.210.137.1 on eth1
-- 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-10-23 at 13:38 +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, Oct 23, 2019 at 09:11:31AM +0000, Kenth Eriksson wrote:
Hi!
When showing routing table, the output can have '*', '!' or empty depending on the route. I thought that the asterisk ('*') meant that the route is a primary route installed into the kernel. But this does not seem to always be true, e.g.
Hi
The asterisk means the route is selected as best (i.e. is the first of routes for the same network). This does not mean that the route is exported to kernel. For example in route reflectors / route servers, a route is selected as best and propagated to BGP peers, but no Kernel protocol is configured.
But i do not understand the cases below, where there is no other route for that network and the only route does not have asterisk.
Simplest of use case, its a default route from the kernel. But still no asterisk. Below is a gdb trace in function rt_show_rte gdb) print ia $1 = (byte *) 0xffc6c3ab "0.0.0.0/0" (gdb) print e $2 = (rte *) 0x56939d14 (gdb) print e->net->routes $3 = (struct rte *) 0x56939c54 (gdb) print e->next $4 = (struct rte *) 0x0 Obviously e->net->routes is not equal to e, thus no asterisk. /k
consider the following:
bird> show route 0.0.0.0/0 Table master4: 0.0.0.0/0 unicast [kernel1 2019-10-22] (215) via 10.210.137.1 on eth1
-- 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, Oct 23, 2019 at 12:40:42PM +0000, Kenth Eriksson wrote:
But i do not understand the cases below, where there is no other route for that network and the only route does not have asterisk.
Simplest of use case, its a default route from the kernel. But still no asterisk. Below is a gdb trace in function rt_show_rte
gdb) print ia $1 = (byte *) 0xffc6c3ab "0.0.0.0/0" (gdb) print e $2 = (rte *) 0x56939d14 (gdb) print e->net->routes $3 = (struct rte *) 0x56939c54 (gdb) print e->next $4 = (struct rte *) 0x0
Obviously e->net->routes is not equal to e, thus no asterisk.
Well, i do not understand why the text output below consists of only one route, while you have 0x56939d14 and 0x56939c54. Is the text output edited?
consider the following:
bird> show route 0.0.0.0/0 Table master4: 0.0.0.0/0 unicast [kernel1 2019-10-22] (215) via 10.210.137.1 on eth1
-- 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-10-23 at 15:00 +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, Oct 23, 2019 at 12:40:42PM +0000, Kenth Eriksson wrote:
But i do not understand the cases below, where there is no other route for that network and the only route does not have asterisk.
Simplest of use case, its a default route from the kernel. But still no asterisk. Below is a gdb trace in function rt_show_rte
gdb) print ia $1 = (byte *) 0xffc6c3ab "0.0.0.0/0" (gdb) print e $2 = (rte *) 0x56939d14 (gdb) print e->net->routes $3 = (struct rte *) 0x56939c54 (gdb) print e->next $4 = (struct rte *) 0x0
Obviously e->net->routes is not equal to e, thus no asterisk.
Well, i do not understand why the text output below consists of only one route, while you have 0x56939d14 and 0x56939c54. Is the text output edited?
No. But I filtered on 0.0.0.0/0, and there is only one such route entry.
consider the following:
bird> show route 0.0.0.0/0 Table master4: 0.0.0.0/0 unicast [kernel1 2019-10-22] (215) via 10.210.137.1 on eth1
-- 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-10-23 at 13:07 +0000, Kenth Eriksson wrote:
No. But I filtered on 0.0.0.0/0, and there is only one such route entry.
Re-tested on vanilla 2.0.7. Same issue there. Default route is not marked with asterisk. Tested on different setups, all showing same intermittent reporting of the primary route. BIRD v2.0.7 ready. bird> show route Table master4: 0.0.0.0/0 unicast [kernel1 11:10:53.058] (215) via 10.210.70.1 on eth0 10.210.70.0/23 unicast [direct1 11:10:53.058] * (255) dev eth0 unicast [kernel1 11:10:53.058] (215) dev eth0 Table master6: ::/0 unicast [kernel2 11:10:53.058] (215) via fe80::241:d2ff:fe45:17cc on eth0 weight 1 via fe80::5206:abff:fe04:954c on eth0 weight 1 2a02:1420:1:70::/64 unicast [direct1 11:10:53.058] * (255) dev eth0 unicast [kernel2 11:10:53.058] (215) dev eth0 bird>
On Thu, Oct 24, 2019 at 09:14:42AM +0000, Kenth Eriksson wrote:
On Wed, 2019-10-23 at 13:07 +0000, Kenth Eriksson wrote:
No. But I filtered on 0.0.0.0/0, and there is only one such route entry.
Re-tested on vanilla 2.0.7. Same issue there. Default route is not marked with asterisk. Tested on different setups, all showing same intermittent reporting of the primary route.
BIRD v2.0.7 ready. bird> show route Table master4: 0.0.0.0/0 unicast [kernel1 11:10:53.058] (215) via 10.210.70.1 on eth0 10.210.70.0/23 unicast [direct1 11:10:53.058] * (255) dev eth0 unicast [kernel1 11:10:53.058] (215) dev eth0
Hi What is your config? It is possible that you have some 'keep filtered' routes in net->routes for 0.0.0.0/0? If there is only one route in list net->routes for 0.0.0.0/0 (as there is no other in your output), then it should have asterisk. Is it possible that due to some bug a temporary route added by kernel during scan was not removed after the scan. Could you check the value of X->attrs->source (and perhaps content of attrs->src) for X in e, e->net->routes in this (or analogous) state:
(gdb) print e $2 = (rte *) 0x56939d14 (gdb) print e->net->routes $3 = (struct rte *) 0x56939c54
-- 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, 2019-10-24 at 16:05 +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 Thu, Oct 24, 2019 at 09:14:42AM +0000, Kenth Eriksson wrote:
On Wed, 2019-10-23 at 13:07 +0000, Kenth Eriksson wrote:
No. But I filtered on 0.0.0.0/0, and there is only one such route entry.
Re-tested on vanilla 2.0.7. Same issue there. Default route is not marked with asterisk. Tested on different setups, all showing same intermittent reporting of the primary route.
BIRD v2.0.7 ready. bird> show route Table master4: 0.0.0.0/0 unicast [kernel1 11:10:53.058] (215) via 10.210.70.1 on eth0 10.210.70.0/23 unicast [direct1 11:10:53.058] * (255) dev eth0 unicast [kernel1 11:10:53.058] (215) dev eth0
Hi
What is your config? It is possible that you have some 'keep filtered' routes in net->routes for 0.0.0.0/0?
Configuration looks like this; protocol kernel { learn; persist; scan time 120; ipv4 { import all; export where (source != RTS_DEVICE); preference 215; }; } protocol kernel { learn; persist; scan time 120; ipv6 { import all; export where (source != RTS_DEVICE); preference 215; }; } protocol device { scan time 60; } protocol direct { ipv4 { import all; preference 255; }; ipv6 { import all; preference 255; }; check link 1; }
If there is only one route in list net->routes for 0.0.0.0/0 (as there is no other in your output), then it should have asterisk.
Is it possible that due to some bug a temporary route added by kernel during scan was not removed after the scan. Could you check the value of X->attrs->source (and perhaps content of attrs->src) for X in e, e->net->routes in this (or analogous) state:
(gdb) print e $2 = (rte *) 0x56939d14 (gdb) print e->net->routes $3 = (struct rte *) 0x56939c54
-- 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, Oct 24, 2019 at 02:18:16PM +0000, Kenth Eriksson wrote:
Hi
What is your config? It is possible that you have some 'keep filtered' routes in net->routes for 0.0.0.0/0?
Configuration looks like this;
Hi Thanks, fixed (commit 498d8145c0984acf6b39d7e312950315571e7030). -- 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 Fri, 2019-10-25 at 13:33 +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.
Hi
Thanks, fixed (commit 498d8145c0984acf6b39d7e312950315571e7030).
Thanks for the patch! Can confirm it resolves the issue.
On Thu, 2019-10-24 at 16:05 +0200, Ondrej Zajicek wrote:
Is it possible that due to some bug a temporary route added by kernel during scan was not removed after the scan. Could you check the value of X->attrs->source (and perhaps content of attrs->src) for X in e, e->net->routes in this (or analogous) state:
(gdb) print ia $1 = (byte *) 0xffcb7f3b "0.0.0.0/0" (gdb) print e $2 = (rte *) 0x56c9dd14 (gdb) print e->net->routes $3 = (struct rte *) 0x56c9dc54 (gdb) print e->attrs->source $4 = 2 '\002' (gdb) print e->attrs->src $5 = (struct rte_src *) 0x56c982cc (gdb) print e->net->routes->attrs->source $6 = 2 '\002' (gdb) print e->net->routes->attrs->src $7 = (struct rte_src *) 0x56c982cc
participants (3)
-
Kenth Eriksson -
Kenth Eriksson
-
Ondrej Zajicek