problems: bird on ulibc openwrt with ospf
Tue Nov 3 15:28:11 CET 2009
Hello,
I got in touch with bird after your great presentation at the ripe meeting.
I like to use bird on small embeded WLAN routers like the linksys WRT54g,
running OpenWRT kamikaze, a uLibc linux system.
I've spent several days in getting my configuration running. From today on,
it does work (more ore less) and I'd like to describe my problems.
I started with bird 1.1.4 (and today 1.1.5) - both birds have the same
problem. I cross-compiled bird for uLibc mipsel myself.
bird 1.1.5 is only 390252 bytes large (striped, compiled without CFLAG -g);
bird 1.1.4 was a bit smaller.
Because free flash storage is a problem on these plattforms, I did not
use the birdc control program. Instead, I configured bird with
log stderr all;
debug protocols all;
and I started bird with
/usr/sbin/bird -c /etc/bird.conf -s /tmp/bird.ctl -d &
on both routers. This way I could see what's going on.
Bird told it was learning the routes (from OSPF between the two embeded
routers), but they did not appear in the kernel routing table.
I even used strace and ltrace and saw that bird did not do any system- or
library-calls for setting routes.
The debug output has not told me why. Unfortunately, bird does only listen on
unix sockets. With 256k free "disk" space I could not install birdc, because it
depends on libncurses. libncurses is 258343 bytes large.
Wrapper programs like socat are also too big.
It would be nice if birdc could be used to speak over tcp to the remote
system's bird..
Today I copied libncurses and birdc to /tmp (ramfs) and symlinked libncurses
to /usr/lib. After this, I was able to use birdc and saw what's going on.
linux kernel routing table:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.25.193.248 * 255.255.255.248 U 0 0 0 br-wlan50LINK
10.25.193.128 10.25.193.64 255.255.255.248 UG 0 0 0 br-lan
10.25.190.248 * 255.255.255.248 U 0 0 0 br-wlan24LINK
10.25.193.144 10.25.193.65 255.255.255.248 UG 0 0 0 br-lan
10.25.193.224 * 255.255.255.240 U 0 0 0 br-wlan24USER
10.25.193.0 * 255.255.255.128 U 0 0 0 br-lan
bird> sh ro
10.0.0.0/8 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000)
10.25.193.224/28 dev br-wlan24USER [direct1 12:56] (240)
10.25.190.248/29 dev br-wlan24LINK [direct1 12:56] (240)
dev br-wlan24LINK [ospf1 12:57] I (150/20)
10.25.193.248/29 dev br-wlan50LINK [direct1 12:56] (240)
dev br-wlan50LINK [ospf1 12:57] I (150/10)
192.168.1.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] IA (150/20)
127.0.0.0/8 dev lo [direct1 12:56] (240)
10.25.193.0/24 dev lo [static1 12:56] (1000)
10.25.193.0/25 dev br-lan [direct1 12:56] (240)
10.25.190.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000)
10.25.190.0/25 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000)
-> as you can see, the kernel did not learn the routes from the ospf neighbor
(10.25.193.254) like 10/8, 10.25.190.0/25, etc.
"sh protocols" shows that all protocols are running.
I assumed that "sh ro" should tell me also about kernel routes - but it
doesn't.
Here's the solution:
bird> disable kernel1
kernel1: disabled
bird> enable kernel1
kernel1: enabled
bird> show route
0.0.0.0/0 via 10.25.193.254 on br-wlan50LINK [ospf1 13:03] E2 (150/20/10000)
192.168.99.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 13:03] E2 (150/20/10000)
10.0.0.0/8 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000)
10.25.193.224/28 dev br-wlan24USER [direct1 12:56] (240)
10.25.190.248/29 dev br-wlan24LINK [direct1 12:56] (240)
dev br-wlan24LINK [ospf1 12:57] I (150/20)
10.25.193.248/29 dev br-wlan50LINK [direct1 12:56] (240)
dev br-wlan50LINK [ospf1 12:57] I (150/10)
192.168.1.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] IA (150/20)
127.0.0.0/8 dev lo [direct1 12:56] (240)
10.25.193.0/24 dev lo [static1 12:56] (1000)
10.25.193.0/25 dev br-lan [direct1 12:56] (240)
10.25.193.128/29 via 10.25.193.64 on br-lan [kernel1 13:02] (10)
10.25.190.0/24 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000)
10.25.190.0/25 via 10.25.193.254 on br-wlan50LINK [ospf1 12:57] E2 (150/10/10000)
10.25.193.144/29 via 10.25.193.65 on br-lan [kernel1 13:02] (10)
and now the linux kernel routing table looks like this:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.25.193.248 * 255.255.255.248 U 0 0 0 br-wlan50LINK
10.25.193.128 10.25.193.64 255.255.255.248 UG 0 0 0 br-lan
10.25.190.248 * 255.255.255.248 U 0 0 0 br-wlan24LINK
10.25.193.144 10.25.193.65 255.255.255.248 UG 0 0 0 br-lan
10.25.193.224 * 255.255.255.240 U 0 0 0 br-wlan24USER
10.25.190.0 10.25.193.254 255.255.255.128 UG 0 0 0 br-wlan50LINK
10.25.193.0 * 255.255.255.128 U 0 0 0 br-lan
10.25.190.0 10.25.193.254 255.255.255.0 UG 0 0 0 br-wlan50LINK
192.168.1.0 10.25.193.254 255.255.255.0 UG 0 0 0 br-wlan50LINK
192.168.99.0 10.25.193.254 255.255.255.0 UG 0 0 0 br-wlan50LINK
10.25.193.0 * 255.255.255.0 U 0 0 0 lo
10.0.0.0 10.25.193.254 255.0.0.0 UG 0 0 0 br-wlan50LINK
default 10.25.193.254 0.0.0.0 UG 0 0 0 br-wlan50LINK
Ok, that's fine now. But I cannot do this without manually disable-/enableing
protocol kernel1 via birdc.
Do you have any ideas what causes this problem?
As you can see, it's beautiful with bird to set up two direct paths to the
same ospf neighbor:
the first is a the primary wlan link on 5GHz with high ospf priority and
the second is a backup wlan link on 2.4GHz with lower ospf priority
If 5GHz fails, the 2.4GHz link is used, at both sides.
Btw, when do you expect bird's ospf will learn the NSSA (not-so-stubby area)
feature?
Regards,
- Thomas
PS: I'm not subscribed to the mailing-list yet.
----- End forwarded message -----
More information about the Bird-users
mailing list