Hello. Recently I spot following issue with BIRD:   kernel syncer does not learn routes with RTPROT_KERNEL even with     "learn" and "device routes" turned on. Config is wery simple: # Main routing table (master), mapped to ipt_main kernel table. # ipt_main == 254 (see /etc/iproute2/rt_tables) protocol kernel kernel254 {         persist no;         scan time 120;         learn yes;         device routes yes;         kernel table ipt_main;         import all;         export all; } $ birdc 'show route' BIRD 1.3.10 ready. $ ip -4 route show table main 172.16.1.0/24 dev lo255  proto kernel  scope link  src 172.16.1.254 Can some one explain why this was done, and is there any way other than patching BIRD (at least sysdep/linux/netlink.c does checking and ignoring and sysdep/unix/krt.c makes its final verdict to ignore such route). Background of problem or why this might be important (at least for me). There is lot of text, and no need to read it, however it describes why learning routes with RTPROT_KENREL might be important. ----------------------------------------------------------------------------------------------- There is requirement to create separate Linux kernel RIB and install rules to direct traffic to it (ip-rules(8)). This is an PBR (Policy-Based Routing) BIRD has all necessary means to do that:   protocols direct - to learn directly connected routes and   pipe to import from main (master in BIRD) routing table some routes. And everything works as expected, except that protocol direct "imports" (better to say create may be?) routes based on interface ip address configuration. Contrary to this, kernel installs such directly connected routes with some attributes: like proto kernel, and very important as I discover src (krt_prefsrc attribute in BIRD). Actually attribute perfsrc used in kernel to determine outgoning source for packets that has no src addresses in it (application does not call bind(2), which is common for UDP). Without prefsrc on route, kernel uses fallback mechanism to find source: this is inet_select_addr() function, which is not ideal in functionality (in some cases strange source address might be choosen), and all it does it looks outgoing interface itself for primary address and other interfaces if interface has no such one). Recent kernels (linux-2.6.39+) has implemented genid table to cache information from inet_select_addr() (commits 436c3b66ec98 "ipv4: Invalidate nexthop cache nh_saddr more correctly." and  1fc050a13473 "ipv4: Cache source address in nexthop entries.") lookups, but implementation has also wholes (for example if interface has zero ip address on it and host on lan referenced by a route with interface as nexthop (so called ip unnumbered in proven vendor terms) as only event to regenerate (and thus recall inet_select_addr()) genid is changing state of the interface (i.e. changing route pointing to device has no chance to regenerate genid and packets might still go with source from previous call to inet_select_addr()). Some distributions with longterm support still provides 2.6.32 kernels. Having system with thousands interfaces and sending UDP for example over all of it is wery expensive in CPU terms. Thus I decided to learn routes from kernel protocol and then pass them trought pipe and install it in new kernel table for PBR. -- SP5474-RIPE Sergey Popovich