[OLSR-users] Default routing question

[Andreas Tønnesen]

Comments inline.

John Gorkos wrote:
> Replies inline, thanks for the quick response.
> 
> On Friday 26 March 2004 23:18, Andreas Tønnesen wrote:
> 
>>Hi,
>>
>>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 
gateway configuration...
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
>>at runtime.
> 
> 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 
feature.

- Andreas

-- 
Andreas Tønnesen((spam-protected))
UniK University Graduation Center
University of Oslo
http://www.olsr.org