[OLSR-users] Default routing question
Sat Mar 27 06:58:33 CET 2004
John Gorkos wrote:
> Replies inline, thanks for the quick response.
> On Friday 26 March 2004 23:18, Andreas Tønnesen wrote:
>>A most interesting project! My comments inline.
>>John Gorkos wrote:
>>>I have a project involving a large number of WRT54G routers running linux
>>>w/ OLSR. Perhaps 1 in 10 of the routers will have a backhaul to the
>>>internet, the rest will use these internet connected routers as gateways.
>>> The kicker is this: I want to have a single configuration that works on
>>>all routers, regardless of whether they are internet-connected or not.
>>>Is this possible with the current OLSR imlpementation? From what I've
>>>been able to decipher, the OLSR daemon finds out from the configuration
>>>file whether or not it is a "default" router. I need to determine this
>>>dynamically, because I don't know yet which routers get an internet
>>>connection and which ones don't.
>>IMO you should create a startupscript that checks wether the node has a
>>internet route avalible. This check could easily be done inside the olsr
>>daemon - but IMO this is not olsrs job. Modularity! :)
> But what if a route becomes available while olsrd is running. For example, I
> plug a DSL modem into the WAN jack of my WRT54G. It detects the insertion as
> a hotplug event, runs the DHCP client and receives an IP address and a
> default route. In my perfect world, olsr would "see" this and reconfigure
> itself as a gateway node. Am I pipe-dreaming?
Ok - yout want a completley "plug and play" interface to the Internet
Well - a plugin could do this. Plugins will be supported from the next
release(0.4.1) - and if you are interested I could write a plugin that
dynamically checks for Internet routes and sets the node up as a gateway.
>>>All told, the mesh will contain 50 routers initially, with about 50 more
>>>in six months. Is OLSR the right tool for the job?
>>What kind of mobillity do you expect to see? And what kind of density?
>>Anyways - to me this souds like a job for olsr. Olsr is very well suited
>>for dense ad-hoc networks.
> I expect to see little mobility in the network. The project is to provide
> WISP access to an apartment complex. For a variety of reasons, I have
> rejected the traditional hub-spoke network in favor of the mesh. I will be
> adding/removing/moving nodes at a rate of less than 1/week after roll-out.
> The radios will be mounted in the attics of each building, and each building
> has either 2 or 4 tenants. Because of the ability to split out each of the
> LAN ports on a WRT54g into individual VLANs, I can use one radio on up to 4
> tenants. This drives the cost/user down, and allows me to splurge by putting
> radios in buildings where there are no tenants today, but may be in six
> months. Obviously, this strengthens the mesh. The entire complex occupies
> approximately 2 square KM.
>>Remember that you can tune the message-emission intervals to suit your
>>mobillity-degree. If mobillity is high the HELLO(and other) intervals
>>should be small.
> So in a fairly static network, is the converse true?
I would say so. If mobility is low the control traffic emission
intervals could be set up(longer intervals). This greatly reduces
overhead - expecially for flooded traffic.
>>I intend to implement a plugin that allows one to update theese values
> I would be happy to test, especially if it includes the ability to default
> rotue out of the mesh (is that the proper terminology?)
I just call them gateways :)
>>Again - this will be a _very_ interesting real-life experiment! Keep us
>>updated on your work!! When do you expect to do this?
> We have 20 WRT54Gs delivered, with 20 more on order. We have the backbone and
> all server equipment in place, and a tower with carrier-grade backhaul gear
> on order, with a installation date of 10 days from now. I intend to start
> installing radios NLT 15 April, 2004. the only piece of the puzzle not
> completely shaped is the final firmware image.
> I noticed that g/w address is one of the few parameters that MUST be set in
> the configuration file vs on the command line. Is there a reason for that?
The reason for this is that I never found it feasable to set HN routes
at the commandline. I am trying to remove options that include passing
lots of data(a node could be a gateway to several networks) from the
commandline. No reason except that :) But I realize that in certain
scenarios a configfile might not be avalible. If it is important to be
able to set HNA routes at the commandline I could consider adding that
UniK University Graduation Center
University of Oslo
More information about the Olsr-users