Redistributing kernel routes
I am having difficulty redistributing kernel routes into any other protocol. The question is similar to the one asked here: http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg01036.htm l (subject "Problem with redistribute static routes from venet (openvz pseudointerface)") but a) the solution proposed there does not work. b) I cannot get normal static "via" routes to distribute. What I am trying to do at the moment is to get device routes (e.g. those created like ip route add 4.4.4.4/32 proto SOMEPROTO nexthop dev evrr-000001 to register in bird). Ultimately I'd like to redistribute them into ospf or similar. Right now the problem is that they do not show up at all. For test purposes I added normal static routes too: # ip route add 6.6.6.6/32 proto static nexthop via 172.16.1.22 # ip route add 7.7.7.7/32 proto boot nexthop via 172.16.1.22 These don't show up either. The interface routes, however, do show up. I am in control of the population of the routing table, so can set the protocol as appropriate. I would have thought "static" would be the most appropriate protocol. I have tried with and without "device routes yes" set in the kernel section. I have tried with and without the patch to ./sysdep/linux/netlink/netlink.c. As far as I can tell the patch special-cases routes with RTPROT_BOOT. I have installed dummy /32 routes with the protocols BOOT (i.e. the default), static, kernel, and 234. They all behave the same (i.e. bird does not see them). It also doesn't seem to apply to non-device routes. I can't help but think I must be doing something really stupid here. -- Alex Bligh root@alex-test:/# uname -a Linux alex-test 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux root@alex-test:/# ip r s 7.7.7.7 via 172.16.1.22 dev evrr-000001 2.3.4.5 dev evrr-000001 proto 234 5.5.5.5 dev evrr-000001 6.6.6.6 via 172.16.1.22 dev evrr-000001 proto static 1.1.1.1 dev evrr-000001 proto static 4.4.4.4 dev evrr-000001 proto kernel 2.2.2.2/31 dev evrr-000001 proto static 10.99.99.0/24 dev dummy proto kernel scope link src 10.99.99.1 172.16.1.0/24 dev evrr-000001 proto kernel scope link src 172.16.1.223 root@alex-test:/# ip a l 534: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 535: dummy2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 42:e8:af:c7:30:db brd ff:ff:ff:ff:ff:ff inet6 fe80::40e8:afff:fec7:30db/64 scope link valid_lft forever preferred_lft forever 536: dummy: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 1a:ca:93:5b:db:93 brd ff:ff:ff:ff:ff:ff inet 10.99.99.1/24 scope global dummy inet6 fe80::18ca:93ff:fe5b:db93/64 scope link valid_lft forever preferred_lft forever 537: evrr-000000: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 46:b6:4d:d3:74:c7 brd ff:ff:ff:ff:ff:ff inet6 fe80::44b6:4dff:fed3:74c7/64 scope link valid_lft forever preferred_lft forever 539: evrr-000001: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 12:ed:07:23:66:68 brd ff:ff:ff:ff:ff:ff inet 172.16.1.223/24 scope global evrr-000001 inet6 fe80::10ed:7ff:fe23:6668/64 scope link valid_lft forever preferred_lft forever root@alex-test:/# ip link show 534: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 535: dummy2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 42:e8:af:c7:30:db brd ff:ff:ff:ff:ff:ff 536: dummy: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 1a:ca:93:5b:db:93 brd ff:ff:ff:ff:ff:ff 537: evrr-000000: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 46:b6:4d:d3:74:c7 brd ff:ff:ff:ff:ff:ff 539: evrr-000001: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 12:ed:07:23:66:68 brd ff:ff:ff:ff:ff:ff root@alex-test:/# birdc BIRD 1.2.5 ready. bird> show route all 10.99.99.0/24 dev dummy [MyOSPF 19:46] * I (150/10) [10.99.99.1] Type: OSPF unicast univ OSPF.metric1: 10 OSPF.metric2: 16777215 OSPF.tag: 0x00000000 OSPF.router_id: 10.99.99.1 172.16.1.0/24 dev evrr-000001 [MyOSPF 19:46] * I (150/10) [10.99.99.1] Type: OSPF unicast univ OSPF.metric1: 10 OSPF.metric2: 16777215 OSPF.tag: 0x00000000 OSPF.router_id: 10.99.99.1 bird> root@alex-test:/# cat /etc/bird.conf protocol kernel { persist; # Don't remove routes on BIRD shutdown scan time 5; # Scan kernel routing table every 20 seconds export all; # Default is export none import all; device routes yes; } protocol device { scan time 10; # Scan interfaces every 10 seconds } protocol ospf MyOSPF { rfc1583compat yes; tick 2; export filter { accept; }; import filter { accept; }; area 0.0.0.0 { interface "dummy" { cost 10; stub yes; }; interface "evrr*" { cost 10; stub yes; }; }; } diff -ur --exclude='*~' ../bird-1.2.5.original-from-natty/sysdep/linux/netlink/netlink.c ./sysdep/linux/netlink/netlink.c --- ../bird-1.2.5.original-from-natty/sysdep/linux/netlink/netlink.c 2010-08-03 16:44:51.000000000 +0100 +++ ./sysdep/linux/netlink/netlink.c 2011-05-02 19:43:48.560597108 +0100 @@ -706,8 +706,10 @@ * for their 'alien' routes. */ +#if 0 if (i->rtm_protocol == RTPROT_BOOT) src = KRT_SRC_KERNEL; +#endif } break;
On Mon, May 02, 2011 at 08:20:36PM +0100, Alex Bligh wrote:
I am having difficulty redistributing kernel routes into any other protocol.
...
b) I cannot get normal static "via" routes to distribute.
You have to add 'learn' option to the kernel protocol config. Otherwise, kernel protocol is export-only. But if you do not have some special situation here (like routes dynamically generated by some other software), it is usually a better idea to have static routes configured in BIRD using static protocol and export these to the kernel instead. -- 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."
Ondrej, --On 2 May 2011 21:58:51 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, May 02, 2011 at 08:20:36PM +0100, Alex Bligh wrote:
I am having difficulty redistributing kernel routes into any other protocol.
...
b) I cannot get normal static "via" routes to distribute.
You have to add 'learn' option to the kernel protocol config. Otherwise, kernel protocol is export-only.
Ah. I knew it would be something stupid. It now works. Thanks. Without the patch it appears to import all the routes other than the device routes marked "proto boot". The device routes import whether or not I have "device routes yes" set. Is that expected behaviour? (not complaining, it simplifies my config).
But if you do not have some special situation here (like routes dynamically generated by some other software), it is usually a better idea to have static routes configured in BIRD using static protocol and export these to the kernel instead.
I have routes dynamically generated by some other software. My aim is to use bird to pick these up and advertise them. -- Alex Bligh
On Mon, May 02, 2011 at 09:01:35PM +0100, Alex Bligh wrote:
Ah. I knew it would be something stupid. It now works. Thanks.
Without the patch it appears to import all the routes other than the device routes marked "proto boot".
Also device routes marked "proto kernel" (i.e. common automatically generated device routes) are not imported.
The device routes import whether or not I have "device routes yes" set. Is that expected behaviour? (not complaining, it simplifies my config).
Yes. Option 'device routes' is related only to the export of device routes to the 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."
--On 2 May 2011 23:35:18 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Mon, May 02, 2011 at 09:01:35PM +0100, Alex Bligh wrote:
Ah. I knew it would be something stupid. It now works. Thanks.
Without the patch it appears to import all the routes other than the device routes marked "proto boot".
Also device routes marked "proto kernel" (i.e. common automatically generated device routes) are not imported.
Thanks. I will mark mine proto static.
The device routes import whether or not I have "device routes yes" set. Is that expected behaviour? (not complaining, it simplifies my config).
Yes. Option 'device routes' is related only to the export of device routes to the kernel.
Aaahhh... -- Alex Bligh
participants (2)
-
Alex Bligh -
Ondrej Zajicek