home 
wiki
wiki
OLSRExperiment
This page has been created to document experimentations with the
OLSR routing protocol on the Melbourne Wireless network.Gatewaying between OSPF and OLSR
As of 27th July 2006, OLSR is running on NodeGHO. 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. 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.
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. So a wireless interface can have a very wide /16 netmask and not interfere with routing. But if a /16 static 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.
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 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:
For those using
OLSR Config file, with extra comments by DanFlett
/etc/olsrd.conf
#0 = run in background (daemon) #1 or above = output messages with increasing verbosity DebugLevel 0 IpVersion 4 ClearScreen 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 yes UseHysteresis no #Everyone MUST set their LinkQualityLevel to 2! LinkQualityLevel 2 LinkQualityWinSize 100 Pollrate 0.05 TcRedundancy 2 MprCoverage 7 LinkQualityFishEye 1 LinkQualityDijkstraLimit 0 5.0 #The Network Interface(s) that OLSRd talks on Interface "vlan0" "vlan1" "vlan2" "vlan3" "vlan4" { HelloInterval 5.0 HelloValidityTime 200.0 TcInterval 0.5 TcValidityTime 260.0 MidValidityTime 100.0 HnaValidityTime 100.0 } #Runs a tiny webserver on port 1978 with OLSR route info LoadPlugin "olsrd_httpinfo.so.0.1" { PlParam "port" "1978" PlParam "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 static entries from /etc/hosts.static #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 "olsrd_nameservice.so.0.2" { PlParam "name" "nodegho" PlParam "add-hosts" "/etc/hosts.static" PlParam "hosts-file" "/tmp/hosts.olsr" PlParam "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"
/etc/quagga/zebra.conf
hostname nodegho password ****** enable password ****** log syslog ! ip route 10.10.0.0 255.255.128.0 null0 ip route 10.10.128.0 255.255.128.0 null0 !
Note that ospfd.conf does not need to be edited - all we need to do is add static routes to the OSPF domain and that is done in zebra.conf with the ip route command.Version 1 (old) modified Mon, 26 Jul 2021 12:49:29 +0000 by Dan[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]