From StarOS Community Wiki
Jump to navigation Jump to search

OLSR is a replacement for RIP and/or OSPF and/or Static routes. The OLSR daemon will dynamically manage your routing table on your StarV3 system so the rest of your routed network is reachable.

Getting to know OLSR

Is OLSR a replacement for RIP and/or OSPF and/or Static routes?

You can and will want to remove the static route at any of your StarV3 systems which are not at the "edge" of the OLSR network. The ones which are at the edge will want to not only have a static route to someplace, but they'll also want to do an HNA announcement for so the rest of the OLSR network sees that router as a valid path to The Internet.

To enable OLSR do I just need to enable the default configuration on every AP, and on any AP that has a direct route (via Static Routes etc.) to the internet declaring a HNA entry of netmask

Yes, but you'll also need to add HNA entries for every directly-attached network on each router participating in the OLSR mesh. For example if you have a 2-radio board, one radio is the backhaul talking OLSR and the other radio is an access point with a public /27 assigned, you'll want to have an HNA entry for that /27 so the rest of the network knows how to reach your /27.

You can also use HNA entries in order to get the rest of the OLSR mesh to "find" a non-OLSR-speaking router you have attached to you. For example if you have a StarOS v2 system connected to you and it needs a/27 routed to it, you can HNA-announce the /27 on your v3 system and add then also add a static route for the /27 routing it to the StarOS v2 system.

As the interface for OLSR seems to be just a configuration file, is there somewhere I can see a list of routes (like sh ip rip) and is there somewhere I can see neighbours communicating etc?

Yes, there's an http plugin which will generate HTML pages to display what's going on.

Should I turn off RIP if I've turned on OLSR?

Yes. You should not try to run two IGPs (interior gateway protocol) at the same time on the same systems. Pick an IGP and stick with it.

Configuration template

Here is my default OLSR configuration I use in production everywhere. I always get rid of the default OLSR configuration and use my stripped-down one instead.

LinkQualityFishEye 1
IpVersion       4

AllowNoInt      yes
TosValue        16
Willingness     4

     MaxConnections  0

UseHysteresis           no
LinkQualityLevel        2
LinkQualityWinSize      20
Pollrate                0.1
TcRedundancy            2
MprCoverage             3

LoadPlugin "olsrd_httpinfo.so.0.1"
        PlParam "port" "8001"
        PlParam "Net" ""
        PlParam "Net" ""

Interface "eth0" "eth1" "wpci0" "wpci1" "wpci2" "wpci3"
    HelloInterval       2.0
    HelloValidityTime   20.0
    TcInterval          1.0
    TcValidityTime      80.0
    MidInterval         4.0
    MidValidityTime     80.0
    HnaInterval         4.0
    HnaValidityTime     80.0
    # LinkQualityMult 0.10

Three things to point out in this configuration template:

1) Hna4 { } is for announcing networks that you know how to reach. For example, you usually announce networks that are directly attached to one of your interfaces. Note my neat spacing between the IP and netmask for my example entries!

2) LoadPlugin "olsrd_httpinfo.so.0.1" { } gets "PlParam" "Net" entries for every network that I want to have access to the HTTP interface. This is the only authentication method so mind this carefully.

3) Interface "xxx0" { } needs to be stripped down so ONLY the interfaces that you'll be talking OLSR on are included in the Interface list. You don't want to bind olsrd unnecessarily to extra interfaces, especially since it may interfere with dhcpd's ability to operate on that same interface. Oh and the LinkQualityMult is an example of setting a specific neighbor as a less-preferred route. If you have two neighbors and you prefer one more than the other, use LinkQualityMult to downgrade your non-preferred route's "link quality".


More On LinkQualityMult

Another handy thing to do with LinkQualityMult is set LinkQualityMult to 2.00 if your neighbor is connected via ethernet. This will help soften or nullify the effect of the "extra hop" that is presented because a backhaul connection is possibly on the next system over even though it's physically right there on the same tower. (For example, you have two backhauls coming to your tower, but the backhauls are coming in on separate system boards.) This will affect the routing decision process for every OLSR participant on the mesh so it's a very good way to present two system boards that are on the same tower as "one".

I often put two separate system boards up on one tower (for when I need more than four radios and/or redundant backhauls on separate system boards) and connect their second ethernet interfaces to each other using an ethernet crossover cable. That's my practical real-world example of the perfect situation in which to use the above tip.

Troubleshooting OLSR

StarV3 Neighbors can't see each other

If you have multiple IPs assigned to an interface in StarV3, the order in which you assigned them is important here. The first IP you assign will be put on "eth0". The subsequent IPs you assign will be put on "eth0:0" and "eth0:1" and so on. OLSR will be talking on eth0, not on any of the :0 and :1, etc. alias interfaces. You can see which IP is assigned to eth0 in "view system report".

If you run into this problem, you will have to remove all IPs from the interface and put your "primary" IP in first, then re-add the other IPs.

External Links