home  wiki


Note: This document lacks elephants.
--  jj

OSPF, BGP, bah. If you're reading this, you probably like one or the other. They're both shit.

But Ja-aymz, I hear you cry, how can you make this assertion?

Looking out a dirty old iface, down below the cars in the city go rushing by
I sit here alone, and I wonder why

Bight lights, the music gets faster, checking your timestamp, another glance
I'm not leaving, no honey, no not a chance.

I realise that this is a terribly, terribly difficult thing for people to grasp, but this is important - despite the name, and the shitty attempt to emulate it, WIFI IS NOT ETHERNET. It is ESPECIALLY not cat-5 connected ethernet, not even 10M, let alone the 100M that everyone is trying to pretend that it is.

Today's proposed alternative is OLSR http://olsr.org . OLSR is not perfect. It's not even good. It's got massive problems, in fact, which we'll talk about here. But yet, most of those problems exist in functionality that OSPF and BGP don't even provide.

OLSR has three major advantages over the aforementioned two: It was designed for mesh routing, which vaguely resembles what we're trying to do, it supports both single hosts and networks, and has at least some measure of link quality built into it. And, unlike BGP or OSPF, a human can actually configure the thing - even on windows.


# A very complicated configuration.  Sort of.  The actual
# running config on hanuman.nodefus.wireless.org.au
# (,,
# Note the special case for the ethernet connections!
DebugLevel              0
ClearScreen             yes
LinkQualityLevel        2
LinkQualityWinSize      100
UseHysteresis           no

Interface "eth0" "wlan1" "wlan0" { HelloInterval 2.0 HelloValidityTime 20.0 # pieces of 100mbit cat5 are always cheap :) LinkQualityMult 10.0 LinkQualityMult 10.0 }

LoadPlugin "olsrd_httpinfo.so.0.1"
        PlParam "Net" ""


One of the most glaring problems is the link quality calculation - the algorythm is 1/(packetLoss * packetLossBackToMe). Note any mention of speed in there? I didn't think you did... our original thought was to combine it with the script from last month for calculating speed, and apply the output of that to LinkQualityMult - which would work great, if only you could reconfigure the router at runtime. But, alas, you cannot.

There is a plugin interface, and this was our next thought - however, while it can with the route table, it doesn't seem to be able to change actual settings. Which is a shame for other reasons that we'll get to momentarily. The point is, that you need to either know your link speed in advance, or trust that it knows best. And while on wifi packet loss is actually a pretty good metric, it is far from perfect - some combinations of interface are just inherently better than others.

There is an argument that the algorythm is also not harsh enough to lossy links - a link with 30% packet loss in each direction will get a route cost of 2.04, whereas in reality that link is almost dead. We actually did experiment with changing the algorythm to 1/(packetLoss^2*packetLossBackToMe^2), which gave results that I was happier with. Which is not to say that the current results are terrible, just that they only consider the GHO link as a 1.41 cost right now, whereas a perfect wifi link is a 1.0 cost. Under the squared algorythm, that cost would be over 2.0, which is much more realistic.

But I really don't want to maintain a forked tree - especially considering that pre-built binaries already exist for linux, windows, pocketpc, and wrt54g. I'm sure that few would argue this point.

The other major complaint, is that point to point links are non-obvious. UDP is the transport used, although unlike OSPF the unreliable transport actually works well here. But the default is to send to the broadcast address of the network - the official way to set up point to point exclusive links, is to change a parameter called Ip4Broadcast. Which makes sense when you think about it, but is non obvious. I don't think you can have multiple ones of these per interface, either, especially a problem when due to other trivia, olsrd tends to fail with aliased interfaces.

Ironically, in the name of sanity checking. There is no management, the program knows best. This is a horrible pain in the ass sometimes... like now, for example. Of course, there is an argument that most MW people shouldn't be controlling their routers in the first place. The protocol is designed to be self configuring, and sometimes this even works. It's just a pain when it doesn't. And like I said, if you don't like it, who the want sto maintain a parallel version? .

But still, the question is, better than OSPF though? Almost certainly. Better than BGP? No, except if you're trying to do what we're trying to do. Then Yes.

Version 8 (current) modified Tue, 03 Jul 2007 23:12:18 +1000 by jaymzj
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]
> home> about> events> files> members> maps> wiki board   > home   > categories   > search   > changes   > formatting   > extras> site map


 Remember me.

> forgotten password?
> register?
currently 0 users online
Node Statistics