kernel: missing 'prefsrc' when installing route to KRT (original BIRD, no patches)
Hello community! While ago I write to list about importance of 'prefsrc' (BIRD's name krt_prefsrc) in Linux network stack (see thread "kernel: does not learn routes with RTPROT_KERNEL (proto kernel in ip-route(8) output)"). However there is another problem with kernel protocol, I spot when *restarting* bird: bird wont install krt_prefsrc attribute when installing route to KRT for routes learned via kernel syncer from another KRT and distributed between BIRD's routing tables via pipe protocol, after daemon restart. There is completely clear bird build without any patches (including patch in maillist thread I point above). Tests was done on Linux 3.8.13 and Linux 3.2.42 kernels. Also I try bird 1.3.9 among with 1.3.11 with some results as with 1.3.11. Here is simple configuration, steps and debugging output from BIRD. --------------------------------------------------------------------------------------- # Configure logging log syslog all; log stderr all; router id 172.16.1.1; protocol device devices { scan time 15; } ### KRT 10 table rt_10; protocol kernel kernel10 { table rt_10; debug all; persist no; scan time 15; learn yes; device routes no; kernel table 10; import where krt_source = ipp_static; export none; } ### KRT 20 table rt_20; protocol kernel kernel20 { table rt_20; debug all; persist no; scan time 15; learn no; device routes no; kernel table 20; import none; export all; } ### pipe 10->20 protocol pipe pipe10 { table rt_10; peer table rt_20; import none; export all; } Wery simple config: two bird RT, with kernel syncer attached to each, connected trought pipe protocol. "kernel10" only learns routes from KRT id 10 with RTPROTO_STATIC to rt_10 and then "pipe10" export these routes to rt_20 table, where kernel syncer installs everything from rt_20 to KRT id 20. Now, on console, before starting bird: ----------------------------------------------- # ip link set up dev lo255 # ip link set up dev lo254 # ip -4 addr add 172.16.254.1/24 dev lo254 # ip -4 addr add 172.16.255.1/24 dev lo255 # ip -4 addr show dev lo254 14: lo254: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN inet 172.16.254.1/24 scope global lo254 # ip -4 addr show dev lo255 15: lo255: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN inet 172.16.255.1/24 scope global lo255 # ip -4 route show table 10 # ip -4 route show table 20 Create, setup and configure two (lo254, Lo255) Linux dummy interfaces, show KRT id 10, 20. Starting bird in debug mode in foreground: ------------------------------------------------------ [root@tuxracer etc]# bird -d 22-08-2013 12:46:50 <TRACE> kernel10: Initializing 22-08-2013 12:46:50 <TRACE> kernel20: Initializing 22-08-2013 12:46:50 <TRACE> kernel10: Starting 22-08-2013 12:46:50 <TRACE> kernel10: Connected to table rt_10 22-08-2013 12:46:50 <TRACE> kernel10: State changed to feed 22-08-2013 12:46:50 <TRACE> kernel20: Starting 22-08-2013 12:46:50 <TRACE> kernel20: Connected to table rt_20 22-08-2013 12:46:50 <TRACE> kernel20: State changed to feed 22-08-2013 12:46:50 <INFO> Started 22-08-2013 12:46:50 <TRACE> kernel10: State changed to up 22-08-2013 12:46:50 <TRACE> kernel20: State changed to up 22-08-2013 12:46:50 <TRACE> kernel10: Scanning routing table 22-08-2013 12:46:50 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:46:50 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:46:50 <TRACE> kernel20: Pruning table rt_20 # birdc 'show route table rt_10' BIRD 1.3.11 ready. # birdc 'show route table rt_20' BIRD 1.3.11 ready. # birdc 'show route table master' BIRD 1.3.11 ready. # birdc 'show protocols' BIRD 1.3.11 ready. name proto table state since info devices Device master up 12:46 kernel10 Kernel rt_10 up 12:46 kernel20 Kernel rt_20 up 12:46 pipe10 Pipe rt_10 up 12:46 => rt_20 Then on another console: --------------------------------- # ip -4 route add 192.168.1.0/24 table 10 proto static src 172.16.255.1 via 172.16.254.254 # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 192.168.1.0/24 via 172.16.254.254 dev lo254 proto bird src 172.16.255.1 There is no problem with 'prefsrc' when received async notification from kernel. and BIRD debug output: ------------------------------- 22-08-2013 12:52:50 <TRACE> kernel10: Scanning routing table 22-08-2013 12:52:50 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:52:50 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:52:50 <TRACE> kernel20: Pruning table rt_20 22-08-2013 12:52:50 <TRACE> kernel10: 192.168.1.0/24: [alien async] created 22-08-2013 12:52:50 <TRACE> kernel10 > added [best] 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:52:50 <TRACE> kernel20 < added 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:52:50 <TRACE> kernel10 < rejected by protocol 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:53:05 <TRACE> kernel10: Scanning routing table 22-08-2013 12:53:05 <TRACE> kernel10: 192.168.1.0/24: [alien] seen 22-08-2013 12:53:05 <TRACE> kernel20: 192.168.1.0/24: seen 22-08-2013 12:53:05 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:53:05 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:53:05 <TRACE> kernel20: Pruning table rt_20 Terminate bird on console and flush KRT 10, 20: ------------------------------------------------------------ # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 192.168.1.0/24 via 172.16.254.254 dev lo254 proto bird src 172.16.255.1 # ip -4 route flush table 10 # ip -4 route flush table 20 # ip -4 route show table 10 # ip -4 route show table 20 Now add route to KRT 10 from previous example and start bird: -------------------------------------------------------------------------------- # ip -4 route add 192.168.1.0/24 table 10 proto static src 172.16.255.1 via 172.16.254.254 # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 # bird -d 22-08-2013 12:57:59 <TRACE> kernel10: Initializing 22-08-2013 12:57:59 <TRACE> kernel20: Initializing 22-08-2013 12:57:59 <TRACE> kernel10: Starting 22-08-2013 12:57:59 <TRACE> kernel10: Connected to table rt_10 22-08-2013 12:57:59 <TRACE> kernel10: State changed to feed 22-08-2013 12:57:59 <TRACE> kernel20: Starting 22-08-2013 12:57:59 <TRACE> kernel20: Connected to table rt_20 22-08-2013 12:57:59 <TRACE> kernel20: State changed to feed 22-08-2013 12:57:59 <INFO> Started 22-08-2013 12:57:59 <TRACE> kernel10: State changed to up 22-08-2013 12:57:59 <TRACE> kernel20: State changed to up 22-08-2013 12:57:59 <TRACE> kernel10: Scanning routing table 22-08-2013 12:57:59 <TRACE> kernel10: 192.168.1.0/24: [alien] created 22-08-2013 12:57:59 <TRACE> kernel10: Pruning table rt_10 22-08-2013 12:57:59 <TRACE> kernel10: Pruning inherited routes 22-08-2013 12:57:59 <TRACE> kernel10 > added [best] 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:57:59 <TRACE> kernel20 < added 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:57:59 <TRACE> kernel10 < rejected by protocol 192.168.1.0/24 via 172.16.254.254 on lo254 22-08-2013 12:57:59 <TRACE> kernel20: Pruning table rt_20 22-08-2013 12:57:59 <TRACE> kernel20: 192.168.1.0/24: reinstalling and catch: ------------- # ip -4 route show table 10 192.168.1.0/24 via 172.16.254.254 dev lo254 proto static src 172.16.255.1 # ip -4 route show table 20 192.168.1.0/24 via 172.16.254.254 dev lo254 proto bird and bird RT output: ------------------------ # birdc 'show route table rt_10 all' BIRD 1.3.11 ready. 192.168.1.0/24 via 172.16.254.254 on lo254 [kernel10 12:57] * (10) Type: inherit unicast univ Kernel.source: 4 Kernel.metric: 0 Kernel.prefsrc: 172.16.255.1 # birdc 'show route table rt_20 all' BIRD 1.3.11 ready. 192.168.1.0/24 via 172.16.254.254 on lo254 [kernel10 12:57] * (10) Type: inherit unicast univ Kernel.source: 4 Kernel.metric: 0 Kernel.prefsrc: 172.16.255.1 Why BIRD does not install/update route with correct 'prefsrc' it it is known even after pipe to another table? When deleting this route from '10' and then adding it again, everything is ok (as with previous example). -- SP5474-RIPE Sergey Popovich
On Thu, Aug 22, 2013 at 01:25:23PM +0300, Sergey Popovich wrote:
Hello community!
While ago I write to list about importance of 'prefsrc' (BIRD's name krt_prefsrc) in Linux network stack (see thread "kernel: does not learn routes with RTPROT_KERNEL (proto kernel in ip-route(8) output)").
However there is another problem with kernel protocol, I spot when *restarting* bird: bird wont install krt_prefsrc attribute when installing route to KRT for routes learned via kernel syncer from another KRT and distributed between BIRD's routing tables via pipe protocol, after daemon restart.
...
Why BIRD does not install/update route with correct 'prefsrc' it it is known even after pipe to another table?
Hello This is a bug in some eattr magic code. Use attached patch. BTW, thanks for very elaborate bug reports. -- 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."
В письме от 23 августа 2013 02:01:00 Вы написали:
On Thu, Aug 22, 2013 at 01:25:23PM +0300, Sergey Popovich wrote:
Hello community!
While ago I write to list about importance of 'prefsrc' (BIRD's name krt_prefsrc) in Linux network stack (see thread "kernel: does not learn routes with RTPROT_KERNEL (proto kernel in ip-route(8) output)").
However there is another problem with kernel protocol, I spot when
*restarting* bird: bird wont install krt_prefsrc attribute when installing route to KRT for routes learned via kernel syncer from another KRT and distributed between BIRD's routing tables via pipe protocol, after daemon restart.
...
Why BIRD does not install/update route with correct 'prefsrc' it it is known even after pipe to another table?
Hello
This is a bug in some eattr magic code. Use attached patch.
Thanks again, Ondrej! Patch tested and found working as expected, problem solved.
BTW, thanks for very elaborate bug reports.
I also try to find solution, before you did, and have following patch with tries but NOT solves problem (and I do not known why). I'm trying to address issue by "adding" eattrs learned in nl_parse_route() in sysdep/linux/netlink.c, in krt_make_tmp_attrs() function at sysdep/unix/krt.c, called from krt_export_rte(), but this does not work. Provide my version anyway (this patch does not work) for convenience: ------------------------------------------------------------------------------------------ @@ -59,6 +59,7 @@ #include "lib/timer.h" #include "conf/conf.h" #include "lib/string.h" +#include "lib/alloca.h" . #include "unix.h" #include "krt.h" @@ -906,21 +907,28 @@ krt_scan_timer_stop(struct krt_proto *p) static struct ea_list * krt_make_tmp_attrs(rte *rt, struct linpool *pool) { - struct ea_list *l = lp_alloc(pool, sizeof(struct ea_list) + 2 * sizeof(eattr)); + struct ea_list *t, *l; - l->next = NULL; - l->flags = EALF_SORTED; - l->count = 2; - - l->attrs[0].id = EA_KRT_SOURCE; - l->attrs[0].flags = 0; - l->attrs[0].type = EAF_TYPE_INT | EAF_TEMP; - l->attrs[0].u.data = rt->u.krt.proto; - - l->attrs[1].id = EA_KRT_METRIC; - l->attrs[1].flags = 0; - l->attrs[1].type = EAF_TYPE_INT | EAF_TEMP; - l->attrs[1].u.data = rt->u.krt.metric; + t = alloca(sizeof(struct ea_list) + 2 * sizeof(eattr)); + + t->next = NULL; + t->flags = EALF_SORTED; + t->count = 2; + + t->attrs[0].id = EA_KRT_SOURCE; + t->attrs[0].flags = 0; + t->attrs[0].type = EAF_TYPE_INT | EAF_TEMP; + t->attrs[0].u.data = rt->u.krt.proto; + + t->attrs[1].id = EA_KRT_METRIC; + t->attrs[1].flags = 0; + t->attrs[1].type = EAF_TYPE_INT | EAF_TEMP; + t->attrs[1].u.data = rt->u.krt.metric; + + t = ea_append(t, rt->attrs->eattrs); + l = lp_alloc(pool, ea_scan(t)); + ea_merge(t, l); + ea_sort(l); return l; } -- SP5474-RIPE Sergey Popovich
On Fri, Aug 23, 2013 at 09:45:07AM +0300, Sergey Popovich wrote:
I also try to find solution, before you did, and have following patch with tries but NOT solves problem (and I do not known why).
Perhaps because in krt_export_rte() function krt_make_tmp_attrs() is not called if the filter is 'export all'? Which is strange, but does not cause any problems (kernel protocol reads such attrs directly, does not need krt_make_tmp_attrs(), which is mainly for filters).
I'm trying to address issue by "adding" eattrs learned in nl_parse_route() in sysdep/linux/netlink.c, in krt_make_tmp_attrs() function at sysdep/unix/krt.c, called from krt_export_rte(), but this does not work.
-- 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."
participants (2)
-
Ondrej Zajicek -
Sergey Popovich