OLSR problems

[mrmike]

I am trying to set up a parallel, redundant system from my office to the internet gatesay. I have dual war boards connected through a switch, up to 2 radio systema on a tower, through a switch to 2 radios lower down, to 2 radios at the gateway, into a switch, and on to the internet, with 2 seperate public IPs. I have OLSR set up as per the wiki that TOG has, with the HNA statement of 0.0.0.0 0.0.0.0 at the gateways, and a static route to the internet port. I can ping the internet from either of the 2 edge radios, but not from anywhere inside the network. The daemon does not show the route to the internet. Am I missing something. does someone want to take a look?

[therealboss]

MeMike

I have sent you a PM

[mrmike]

OK, I got it going. I started with TOGs' OLSR statement, and modified it a bit. The link quality setting was placed to 0; this prevents the system from switching back immediately after the bad link is restored. The TcRedundacy was set to 0, as per the man pages. I tinkered with the Hello and Tc timing, basically set to 1.0 secs intervals, and 5 secs timing, the mid and hna set to 5 and 15 respectively. Once it was set up, removing one link in the chain would cause the chain to re-route, in about 2 ping no-response time cycles, and carry on. Now all the customers can have the rip taken off, and the ethernets can stay at 192.168.1.1 for now. The only drawback I found was the external DNS servers wouldn't respond fast enough (if at all).

Now, can someone explain policy routing a bit more???

[tog]

Are you saying you decided to change LinkQualityLevel to 0 to turn off the LQ algorithm? I like the LQ algorithm and I wouldn't want to turn it off...

Can you post the relevant bits of your new config? I wouldn't mind looking at your changes for more aggressive/faster failover. With my config it currently takes about 15 - 20 seconds to failover.

Primarily just the following bits:

UseHysteresis no
LinkQualityLevel 2
LinkQualityWinSize 10
Pollrate 0.5
TcRedundancy 2
MprCoverage 7



Interface "eth0" "eth1" "wpci0" "wpci1" "wpci2" "wpci3"
{
HelloInterval 0.5
HelloValidityTime 10.0
TcInterval 1.0
TcValidityTime 14.0
MidInterval 5.0
MidValidityTime 15.0
HnaInterval 5.0
HnaValidityTime 15.0
# LinkQualityMult 192.168.0.1 0.49
# Weight 0
}

[mrmike]

I took out the link quality because I have a parallel link from my office to the gateway. The audio from the radio station in on this link. I found on the bench if one part of the link went, the other went up pretty fast. Good. But with the link quality on, when that link came back up, it would switch over (it had a better signal, even thought it was just a little better). This would cause the stream to possible be interrupted twice in a short time.
I set the TcRedundacy to 0, as per the default settings. What I got from the man pages, and other reading, is this level will reduce the packet flooding between nodes.
The Hello times and Validity times were selected by using the 1 second timing, and with the default to be set at 3x, I just upped it a little to see how it would work.
After doing some more reading, I might bring those times down by half, a watch it for a while. I might bring down the MPR to 2, or even 1. On a small network, that will suffice.