home 
wiki
wiki
Spelling: OLSRExperiment
This page has been created to document experimentations with the OLSR
[1] routing protocol on the Melbourne Wireless network.
For a generic config file to run on your router, please see
OLSRConfig [2]
GATEWAYING BETWEEN OSPF AND OLSR
As of 27th July 2006, OLSR is running on NodeGHO [3]. It is running
in parallel with Quagga/OSPF.
IMPORTANT UPDATE
The gateway method described below seems to cause routing problems on
some nodes. We should discontinue it's use until we can find a
solution. The parts of the text relating to the /17 gatewaying have
been literally "put in a box". The example config files have also
been edited to remove the /17 gateway advertisements. But the rest of
the information below is still valid. --DanFlett
The OLSRd and Quagga daemons cannot currenly exchange routes
satisfactorily, but it is possible to set up routes to make a node
"gateway" between OLSR and OSPF domains. The specific configurations
can be seen below in the example config files.
A node running both Quagga/OSPF and OLSR can send out supernet routes
that represent the whole network. By doing this, the node is saying to
other nodes on the network "if you don't have a route for an ip
address you are trying to reach, send your traffic to me". If a node
running only OSPF is trying to reach a node running only OLSR, it can
do so via the OLSR/OSPF gateway node. The reverse is also true.
The entire Melbourne Wireless network is represented by this address
range:
10.10.0.0/16
Another way of writing this is:
10.10.0.0 netmask 255.255.0.0
Both these ranges represent all ip addresses from 10.10.0.0 to
10.10.255.255.
A node running both OSPF and OLSR should send out a static route that
says "I have a route to the rest of the network". Routers always
prefer narrow-range routes to wide-range routes, so if a router has a
specific route to a node, it will ignore the gateway routes sent from
the OSPF/OLSR nodes.
Normally, to send a gateway route you'd choose the simplest route -
10.10.0.0/16. However, doing this would interfere with one of the more
interesting features of OLSR.
On an OLSR node, one can set up a network interface that has a
netmask the same size as the entire network. This allows direct
communication between neighboring nodes that have not previously
arranged to link to each other. This is called an Adhoc network. In a
metropolitain community network, this is a handy feature indeed.
In our current OSPF, fictional Node YYY has an IP address of
10.10.243.1 and Node ZZZ has an address of 10.10.255.250. In the
Melbourne Wireless netowork, nodes are given an allocation block
consisting of 14 usable IP addresses. This is a netmask of /28 or
255.255.255.240.
The allowed ip ranges for both nodes are as follows:
Node YYY
10.10.243.1
to
10.10.243.14
Node ZZZ
10.10.255.241
to
10.10.255.254
Nodes need to keep within their own IP allocations and not use IP
addresses outside these ranges unless they have made prior arrangement
with another node or are using automatic-address-assignment protocols
such as DHCP. In our current practice of using narrow nemasks, for
Nodes YYY and ZZZ to talk to each other they need to arrange to use
another IP address from either Node YYY or ZZZ's address pool. This is
the problem with using OSPF - it needs to be reconfigured each time a
node makes a new local link. And Quagga does not send routes for nodes
with overlapping netmasks - it consideres them to be on the local
link.
But in a wireless adhoc network, nodes with overlapping netmasks may
not be local to each other - it may take multiple hops for them to
reach each other. 802.11 IBSS (Adhoc) wireless ethernet nodes do not
relay packets at the ethernet layer, so two nodes that are out of
radio range cannot be considered "link local", even if there is a node
between the both of them. Nodes that are not "link local" cannot
communicate at the the Ethernet layer unless an intermediate nodes or
nodes act as Ethernet bridges. But in this case, we don't want to do
that. To communicate, the two nodes must route their traffic via the
intermediate node(s) at the IP layer. Management of this process is
done by routing protocol.
In wired Ethernet networks, the general convention is that nodes
within the same IP subnet (layer 3) are communicating at the Ethernet
(layer 2) level, and are effectively ignoring their IP addresses. When
all nodes are link-local to each other, this is indeed the case. They
will be using their MAC addresses to talk to each other, because they
will be aware each other from using ARP broadcasts.
IP routing can still be used between nodes with overlapping netmasks.
OLSR sends out host routes - /32 (or 255.255.255.255) by default. /32
routes have priority over all other routes in a routing table because
they are the most narrow and specific route possible.
A /32 route even has priority over the local network interface
netmask (usually /28 on the Melbourne Wireless network). When an
application wishes to send a packet, it sends it to the IP-stack,
which first consults the routing table. Convention says that if the
destination IP address falls within the netmask of a local ethenet
interface, it will use ARP to find the MAC address corresponding to
that IP address. This is true, except if there is a route in the
routing table that matches the destination IP with a narrower netmask
than the local interface. If this is the case, instead of sending an
ARP broadcast to find the destination node, the IP-stack follows the
directions of that route table entry. This is a specific instruction
that the destination and the next-hop are NOT the same address.
So a wireless interface can have a very wide /16 netmask and not
interfere with routing.
But if a /16 static gateway route is being propogated across the
network by OSPF or OLSR, it _will_ cause trouble on a node with a /16
interface netmask. To avoid this problem, we split the static /16
route into two /17 (or netmask 255.255.128.0) routes. They achieve the
same result as a /16, but both /17 routes will always have priority
over any /16 route.
Finally, it is important to remember that an interface with a wide
netmask isn't sending a signal that it "owns" the whole address space,
nor will it cause network problems to other nodes that fall within the
address space. A node that has been allocated a /28 address range by
Melbourne wireless can only use addresses from that range, but that
doesn't mean it can't use a /16 netmask on it's network interfaces.
NODE GHO CONFIGS
OLSR CONFIG
The vitals:
olsrd version
0.4.10
ETX Link Quality Metric
enabled - level 2
httpinfo plugin
enabled, all interfaces, port 1978
nameservice plugin
enabled
If you want to run OLSR and connect it to GHO, you need to make sure
you're compatible! You must have the LinkQualityLevel [4] set to 2,
and you should be running olsrd version 0.4.10. The other settings
aren't so important for compatibility, but you should copy them as
they have been optimised for a community wireless network like ours.
Don't forget to change the Interface paramater to the interfaces on
your box that you want to run OLSR on, and you should edit the
Nameservice plugin parameters to match the setup on your node.
For more info, please read the documentation:
OLSRd [5]
Nameservice plugin [6]
httpinfo plugin [7]
example olsrd.conf file [8]
For those using Freifunk Firmware [9], under the OLSR settings
everything should be Enabled except for Hysteresis and DynGW [10].
OLSR CONFIG
extra comments by DanFlett [11]
/ETC/OLSRD.CONF
The lines you need to edit for your node are highlighted in
GREEN, like this!
#0 = run in background (daemon) #1 or above = output messages with
increasing verbosity DebugLevel [12] 0 IpVersion [13] 4 ClearScreen
[14] yes # Host Network Announcement # - static routes to be
distributed by OLSR # add any routes that your router is able to
connect to here # this advertises the routes to the rest of the
network Hna4 { #example for IP block = 10.10.145.44/28 #netmask must
be in the dotted quad format # 10.10.145.44 255.255.255.240 }
AllowNoInt [15] yes UseHysteresis [16] no #Everyone MUST set their
LinkQualityLevel [17] to 2! LinkQualityLevel [18] 2 LinkQualityWinSize
[19] 100 Pollrate 0.05 TcRedundancy [20] 2 MprCoverage [21] 7
LinkQualityFishEye [22] 1 LinkQualityDijkstraLimit [23] 0 5.0 #The
Network Interface(s) that OLSRd talks on Interface "vlan0" "vlan1"
"vlan2" "vlan3" "vlan4"{ HelloInterval [24] 5.0 HelloValidityTime [25]
200.0 TcInterval [26] 0.5 TcValidityTime [27] 260.0 MidValidityTime
[28] 100.0 HnaValidityTime [29] 100.0 } #Runs a tiny webserver on port
1978 with OLSR route info LoadPlugin [30] "olsrd_httpinfo.so.0.1" {
PlParam [31] "port" "1978" PlParam [32] "Net" "0.0.0.0 0.0.0.0" }
#Announces this node's name and address via OLSR messages #it writes
any upstream (i.e. Internet-connected) #DNS servers to
/tmp/resolv.conf #it reads any manually defined entries from
/etc/local.hosts #and it writes any hosts entries to /tmp/hosts.olsr
#/tmp/hosts.olsr is symlinked from /etc/hosts #Other nodes must be
runnning OLSRd with the nameservice plugin #to be able to receive
these messages LoadPlugin [33] "olsrd_nameservice.so.0.2" { PlParam
[34] "name" "nodegho" PlParam [35] "add-hosts" "/etc/local.hosts"
PlParam [36] "hosts-file" "/tmp/hosts.olsr" PlParam [37] "resolv-file"
"/tmp/resolv.conf" }
Quagga config has been removed for now - since we're no longer
gatewaying between OLSR and OSPF, the OSPF config file isn't really
relevant.
Links:
------
[1] http:///www.olsr.org
[2] http://www.melbournewireless.org.au/?OLSRConfig
[3] http://www.melbournewireless.org.au/?NodeGHO
[4] http://www.melbournewireless.org.au/?LinkQualityLevel
[5]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/README
[6]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/lib/nameservice/README
[7]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/lib/httpinfo/README_HTTPINFO
[8]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/files/olsrd.conf.default.lq-fisheye
[9] http://freifunk.net/wiki/FreifunkFirmwareEnglish
[10] http://www.melbournewireless.org.au/?DynGW
[11] http://www.melbournewireless.org.au/?DanFlett
[12] http://www.melbournewireless.org.au/?DebugLevel
[13] http://www.melbournewireless.org.au/?IpVersion
[14] http://www.melbournewireless.org.au/?ClearScreen
[15] http://www.melbournewireless.org.au/?AllowNoInt
[16] http://www.melbournewireless.org.au/?UseHysteresis
[17] http://www.melbournewireless.org.au/?LinkQualityLevel
[18] http://www.melbournewireless.org.au/?LinkQualityLevel
[19] http://www.melbournewireless.org.au/?LinkQualityWinSize
[20] http://www.melbournewireless.org.au/?TcRedundancy
[21] http://www.melbournewireless.org.au/?MprCoverage
[22] http://www.melbournewireless.org.au/?LinkQualityFishEye
[23] http://www.melbournewireless.org.au/?LinkQualityDijkstraLimit
[24] http://www.melbournewireless.org.au/?HelloInterval
[25] http://www.melbournewireless.org.au/?HelloValidityTime
[26] http://www.melbournewireless.org.au/?TcInterval
[27] http://www.melbournewireless.org.au/?TcValidityTime
[28] http://www.melbournewireless.org.au/?MidValidityTime
[29] http://www.melbournewireless.org.au/?HnaValidityTime
[30] http://www.melbournewireless.org.au/?LoadPlugin
[31] http://www.melbournewireless.org.au/?PlParam
[32] http://www.melbournewireless.org.au/?PlParam
[33] http://www.melbournewireless.org.au/?LoadPlugin
[34] http://www.melbournewireless.org.au/?PlParam
[35] http://www.melbournewireless.org.au/?PlParam
[36] http://www.melbournewireless.org.au/?PlParam
[37] http://www.melbournewireless.org.au/?PlParam
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]