В письме от 13 августа 2013 10:33:45 пользователь Ondrej Zajicek написал:
On Wed, Aug 07, 2013 at 02:11:46PM +0400, ???????????? ?????????????? wrote:
Well, i don't know why kernel device routes are not imported in 'learn' mode and instead direct protocol is used. Some of these reasons are probably lost in the past (like in ancient Linux where device routes have to be generated by user), another possible reason is that you still need some external protocol for these routes - if you can learn kernel device routes from kernel protocol but if you overwrite them by a route from another protocol, then kernel protocol stops announcing such device routes and the device route is not reintroduced when the other protocol withdraws its route.
Yes, I'm aware of this problem, and this could happen only if I learn router from KRT (Kernel Routing Table) and then (possibly by changing some attrs) export it to the same KRT (correct me if other cases exists). But for case when these kernel routers installed in different KRT this would not happen.
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.
Thanks for the explanation, problem with missing krt_prefsrc is interesting. Perhaps the simple fix would be to add krt_prefsrc to routes generated by direct protocol?
For now I have patch to address this issue. It works wery well for our setup on Linux with PBR and tousands of interfaces, inet_select_addr() is not case now as krt_prefsrc is preserved when reexporting route from one KRT to another. Also patch address some on *BSD systems (where also not all routes learned), however I do not have such system to test this. This patch also incorporates patch from Wiki (FAQ, BIRD does not import some routers from kernel): kern_dev.patch which was lost (not seen currently on new Wiki) possibly due to migration to the new Wiki page. Thank for your reply. -- SP5474-RIPE Sergey Popovich