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 ). We basically want to ensure that when our routers get routes, locally generated traffic comes from the loopback address. Does anyone know a way to do this? I think if BIRD set RTA_SRC before sending the route to the kernel, it would work. Could this attribute be surfaced via BIRD easily?
В письме от 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.
We basically want to ensure that when our routers get routes, locally generated traffic comes from the loopback address.
Yes, setting krt_prefsrc whould help, but as for me there is no good reason to do this on router, as you loose troubleshooting hint on where packets failed to deliver (for example TTL exceeded in transmit) should be delivered: you always get ansver from your router loopback.
Does anyone know a way to do this? I think if BIRD set RTA_SRC before sending the route to the kernel, it would work. Could this attribute be surfaced via BIRD easily?
-- SP5474-RIPE Sergey Popovich
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.
We basically want to ensure that when our routers get routes, locally generated traffic comes from the loopback address.
Yes, setting krt_prefsrc whould help, but as for me there is no good reason to do this on router, as you loose troubleshooting hint on where packets failed to deliver (for example TTL exceeded in transmit) should be delivered: you always get ansver from your router loopback.
There are some good reasons for such behavior, for example you could use private addresses for inter-router networks, or even pseudo-link-local ones (i.e. private addresses not propagated in OSPF area). Another reason is that in some cases, an interface-attached address may not be reachable, while the loopback address will be. -- 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."
Пятница, 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
participants (4)
-
Ondrej Zajicek -
Sargun Dhillon -
Sergey Popovich -
Сергей Попович