Пятница, 6 декабря 2013, 23:37 +01:00 от Ondrej Zajicek <santiago@crfreenet.org>:

On Fri, Dec 06, 2013 at 12:34:44PM +0200, Sergey Popovich wrote:
> ?? ???????????? ???? 6 ?????????????? 2013 02:28:32 ???????????????????????? Sargun Dhillon ??????????????:
> > So, from my understanding, routes in the Linux kernel have can have a
> > source associated with them.This is RTA_SRC attribute in netlink ( I
> > think ).
>
> Maybe you mean RTA_PREFSRC attr? This is implemented and could be set/get
> withing BIRD filters using krt_prefsrc attribute without any problem.

Yes, krt_prefsrc should do the thing, but communication with directly
connected hosts would be handled by implicit device routes from kernel,
which wouldn't be changed by BIRD.

And this creates major problem with PBR deployments with thousands of /30 routes,
where we need prefsrc attribute on route when importing route from ipt_main
and reinstalling it into different KRT. Using "direct" protocol don't help too much,
as it creates new routes based on addresses on interface, not imports them from
KRT with attributes attached by kernel.

BIRD could not change prefsrc of such routes, as it could not learn such routes from kernel.
Even with "learn" and "device routes" options on, due hard coded check for such route types.

Some time ago I submit first version of patch, to address this by entirely special
handling for KRT_SRC_KERNEL from "kernel" protocol core. Now I submit v2 of such
change which targets only Linux and not removes special handling for KRT_SRC_KERNEL
routes. Attached patch enable BIRD to learn routes with RTPROT_KERNEL (ipp_kernel).

--
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."

--
SP5474-RIPE
Sergey Popovich