home 
wiki
wiki
OLSRExperiment
This page has been created to document experimentations with the
OLSR routing protocol on the Melbourne Wireless network.For a generic config file to run on your router, please see OLSRConfig
Gatewaying between OSPF and OLSR
As of 27th July 2006, OLSR is running on NodeGHO. 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:
Another way of writing this is:
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.
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 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
extra comments by DanFlett
/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 0 IpVersion 4 ClearScreen 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 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 onInterface "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 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 "olsrd_nameservice.so.0.2" {PlParam "name" "nodegho"PlParam "add-hosts" "/etc/local.hosts" PlParam "hosts-file" "/tmp/hosts.olsr" PlParam "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.Version 6 (current) modified Mon, 26 Jul 2021 12:49:29 +0000 by Dan[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]