Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

The AA website gives an example of a ppp object that has the settings lcp-rate="1" lcp-timeout="5" .

I am assuming that this means that the Firebrick is doing PPP LCP ping link detection, checking that the (entire ?) link is really up? If so, this is like the CQM link state checking that AA’s routers do to check that the links are working and measure the links’ latency, but presumably is in the reverse direction. Is this correct?

There does not seem to be much documentation but I assume that lcp-rate is the interval between PPP LCP pings being sent out and lcp-timeout is the time before the Firebrick gives up and declares that the link is down following n seconds with no responses to LCP pings.

How does one choose suitable values for these? Any suggestions?

If I were to reduce the lcp-timeout value slightly then it would give me faster link down detection so that switchover to using other PPP links or failover to 3G would be quicker and things would go more smoothly after a DSL link goes down. Reducing it too much might cause spurious switchovers if LCP pings are lost because of errors even yet the link has not gone down.

Do you think that shortening it would be a good or very bad idea? Perhaps down to 3 or even 2 seconds from the suggested 5? Since I have many DSL links it won’t cause a risk of disaster even if I shorten it a bit too much.

[Ixel]

What you're saying is correct.

- lcp-rate is the interval of 'pinging' in seconds
- lcp-timeout is the time in seconds where there's been no response for the LCP pings after which it drops the PPP connection

I currently have mine at 1 and 11, however 1 and 5 might actually be better for faster action on a dropped line (two bonded). Once FTTPoD is live however I won't have to be bothered about this any longer. I don't know what impact it may have for your lines if you were to try a timeout that's less than 5 seconds. I imagine if your CQM graphs are showing very little packet loss then it'll be stable enough?

[burakkucat]

I suspect that experiments will be required to determine the best values for a particular circumstance. Having read the relevant section, I would expect those values to be sufficient if the circuit in question is similar to that of the example.

Connect to AAISP over PPPoE session (3G dongle tweaks and NAT):

<ppp name="AAISP" port="WAN" username="me@a.1" password="secret" nat="true" lcp-rate="1" lcp-timeout="5" graph="AAISP" log="default"/>

[Weaver]

I decided to risk a limited time test with the crazy lcp-timeout=2 just to get some experience. I have done some small downloads. No badness encountered yet, but I will keep an eye on it and do some larger downloads shortly. I don’t know if this setting means that you can miss two pings or you can only miss one ping and it decides the link has gone down. Dropping a single ping has to be fairly common. Perhaps I need to do an upload test too?

[burakkucat]

Perhaps I need to do an upload test too?

Yes, that would be a sensible, worthwhile, experiment.

[Weaver]

Timeout set to 2 was a total disaster, so I do think it could possibly effectively mean ’freak out if missing just one ping response’. Trying 3 instead.

[Weaver]

Three seconds seems to be absolutely fine. No spurious link down events seen. Some substantial flat-out downloads and a fairly large flat-out upload were included in the test session.

[burakkucat]

Now all you need to do is to convince me why you would prefer to use 3 rather than the 5, as specified in the A&A documentation! 

[Weaver]

Further testing showed that 3 was a disaster. After a few hours, things went really bad. So at least I know that there is a reason behind the values documented.

[burakkucat]

Further testing showed that 3 was a disaster. After a few hours, things went really bad.

If I understand correctly, that must mean all four circuits were simultaneously bad? 

[Weaver]

Individual links reported link-down - link-up events randomly in the logs later in the night, presumably due to occasional runs of LCP ping responses being absent, for whatever reason. There were results such as ‘link down for 1 second’ which clearly is bogus as a modem could not resync in one second. So the experiment was terminated, but the outcome was a successful gathering of information.