home 
wiki
wiki
Spelling: OLSRExperiment
This page has been created to document experimentations with the OLSR
[1] routing protocol on the Melbourne Wireless network.
GATEWAYING BETWEEN OSPF AND OLSR
As of 27th July 2006, OLSR is running on NodeGHO [2]. It is running
in parallel with Quagga/OSPF. 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 [3] 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 [4]
Nameservice plugin [5]
httpinfo plugin [6]
example olsrd.conf file [7]
For those using Freifunk Firmware [8], under the OLSR settings
everything should be Enabled except for Hysteresis and DynGW [9].
OLSR CONFIG
extra comments by DanFlett [10]
/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 [11] 0 IpVersion [12] 4 ClearScreen
[13] yes # Host Network Announcement # - static routes to be
distributed by OLSR # - until a more elegant solution is developed, #
nodes that are running OSPF and OLSR together # should inject static
network gateway routes into both # OLSR and OSPF - this allows
OSPF-only and OLSR-only # nodes to reach each other # - the whole of
the melbourne wireless network # is 10.10.0.0/16. Here, and in OSPF it
has # been split into two /17 routes # this has been done to ensure
that these routes # have priority over the /16 interface route that #
an adhoc/omni OLSR interface would use Hna4 { 10.10.0.0 255.255.128.0
10.10.128.0 255.255.128.0} AllowNoInt [14] yes UseHysteresis [15] no
#Everyone MUST set their LinkQualityLevel [16] to 2! LinkQualityLevel
[17] 2 LinkQualityWinSize [18] 100 Pollrate 0.05 TcRedundancy [19] 2
MprCoverage [20] 7 LinkQualityFishEye [21] 1 LinkQualityDijkstraLimit
[22] 0 5.0 #The Network Interface(s) that OLSRd talks on Interface
"vlan0" "vlan1" "vlan2" "vlan3" "vlan4"{ HelloInterval [23] 5.0
HelloValidityTime [24] 200.0 TcInterval [25] 0.5 TcValidityTime [26]
260.0 MidValidityTime [27] 100.0 HnaValidityTime [28] 100.0 } #Runs a
tiny webserver on port 1978 with OLSR route info LoadPlugin [29]
"olsrd_httpinfo.so.0.1" { PlParam [30] "port" "1978" PlParam [31]
"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 [32] "olsrd_nameservice.so.0.2" {
PlParam [33] "name" "nodegho" PlParam [34] "add-hosts"
"/etc/local.hosts" PlParam [35] "hosts-file" "/tmp/hosts.olsr" PlParam
[36] "resolv-file" "/tmp/resolv.conf" }
QUAGGA CONFIG
- edited to add static routes
_null0_ is a blackhole route - if a route can't be found, it goes
into the blackhole and the source node gets the message "destination
unreachable"
The code that provides the static "gateway" routes to OLSR are
highlighted
/ETC/QUAGGA/ZEBRA.CONF
hostname nodegho password ****** enable password ****** log syslog !
ip route 10.10.0.0 255.255.128.0 null0ip route 10.10.128.0
255.255.128.0 null0!
/ETC/QUAGGA/OSPFD.CONF
hostname nodegho password ****** enable password ****** log syslog !
interface eth1 ! interface vlan0 ! interface vlan1 ! interface vlan2 !
interface vlan3 ! interface vlan4 ! ! router ospf ospf router-id
10.10.129.1 network 10.10.129.0/28 area 0.0.0.0 network
10.10.130.176/28 area 0.0.0.0 network 10.10.131.64/28 area 0.0.0.0
network 10.10.131.80/28 area 0.0.0.0 network 10.10.131.96/28 area
0.0.0.0 passive-interface eth1 redistribute static!
Links:
------
[1] http:///www.olsr.org
[2] http://melbournewireless.org.au/?NodeGHO
[3] http://melbournewireless.org.au/?LinkQualityLevel
[4]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/README
[5]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/lib/nameservice/README
[6]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/lib/httpinfo/README_HTTPINFO
[7]
http://olsrd.cvs.sourceforge.net/*checkout*/olsrd/olsrd-current/files/olsrd.conf.default.lq-fisheye
[8] http://freifunk.net/wiki/FreifunkFirmwareEnglish
[9] http://melbournewireless.org.au/?DynGW
[10] http://melbournewireless.org.au/?DanFlett
[11] http://melbournewireless.org.au/?DebugLevel
[12] http://melbournewireless.org.au/?IpVersion
[13] http://melbournewireless.org.au/?ClearScreen
[14] http://melbournewireless.org.au/?AllowNoInt
[15] http://melbournewireless.org.au/?UseHysteresis
[16] http://melbournewireless.org.au/?LinkQualityLevel
[17] http://melbournewireless.org.au/?LinkQualityLevel
[18] http://melbournewireless.org.au/?LinkQualityWinSize
[19] http://melbournewireless.org.au/?TcRedundancy
[20] http://melbournewireless.org.au/?MprCoverage
[21] http://melbournewireless.org.au/?LinkQualityFishEye
[22] http://melbournewireless.org.au/?LinkQualityDijkstraLimit
[23] http://melbournewireless.org.au/?HelloInterval
[24] http://melbournewireless.org.au/?HelloValidityTime
[25] http://melbournewireless.org.au/?TcInterval
[26] http://melbournewireless.org.au/?TcValidityTime
[27] http://melbournewireless.org.au/?MidValidityTime
[28] http://melbournewireless.org.au/?HnaValidityTime
[29] http://melbournewireless.org.au/?LoadPlugin
[30] http://melbournewireless.org.au/?PlParam
[31] http://melbournewireless.org.au/?PlParam
[32] http://melbournewireless.org.au/?LoadPlugin
[33] http://melbournewireless.org.au/?PlParam
[34] http://melbournewireless.org.au/?PlParam
[35] http://melbournewireless.org.au/?PlParam
[36] http://melbournewireless.org.au/?PlParam
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]