On Tue, Apr 17, 2012 at 11:37:52AM +0100, Howden Nick wrote:

Hi,

I tried to post this to the mailing list but to no avail.

Don't know why it wasn't delivered.

I wonder if you can shed some light on the problem we are having with devices not being preserved when Bird updates the kernel routing tables.

...

birdc show table BIRD ... 11.6.9.0/24 via 11.6.1.200 on TAP_One [MYOSPF 16:04] * I (100/10436) ... The BIRD table contains the correct network device TAP_One

...

ip route ls table NEW ... 11.6.9.0/24 via 11.6.1.200 dev TAP_Two proto bird ... But, when we inspect the kernel table the network device information has been lost.

Generally, BIRD assumed that IP address is the whole key for gw and iface is derivable from it. With IPv6 and link-local addresses that had to changed, but it probably remained in some parts where it is not relevant to that. I personally never tested this variant.

Tap_One and Tap_Two both have IP addresses in the range 11.6.1.0/24 and I am relying on the routing tables being correct in order to identify the correct interface to use for the outbound traffic. The behaviour we are seeing is the behaviour we expect if routes are added as: ip route add 11.6.9.0/24 via 11.6.1.200 table NEW instead of ip route add 11.6.9.0/24 via 11.6.1.200 dev TAP_One table NEW

You are right, for some unknown reason device is not used when route is propagated to the kernel. You could try attached patch.

My understanding was that the "device routes" option would allow the device part of the routes to be preserved but there is clearly a flaw in my knowledge.

No, that 'device routes' is something completely different - whether device routes (routes without via/gw) are propagated.

Is it actually possible to preserve the device information present in the BIRD routing tables when they are exported to kernel tables?

Try attached patch. -- 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."