Should LCP echo be enabled and if so with what parameters?

I've had FTTP 80/20 Openreach for around 6 months. It has been great. I've currently got LCP Echo enabled with a 1 second echo interval and a failure threshold of 6 no response events, so after 1x6=6 seconds my router decides the remote end has disappeared and attempts to reconnect.

Occasionally, I've seen a few events where the router has decided the remote end has gone away and reconnected. There was one last night, but there was also an issue at around 20:30 last night with many BT connected lines dropping.

https://ebilling.aquiss.net/serverstatus.php
https://aastatus.net/#status

Are there any recommended settings for FTTP or is it just personal preference? What are other TBB members using? Are my settings reasonable?

It's a trade off between detecting an issue quickly or waiting a little longer before attempting a reconnect.

What is the purpose of your monitoring of LCP packets? Answering that question is probably the first step in understanding what parameters should be set.

In the normal case, for optimum recovery after an interruption you would want both sides of the link to have similar behaviour so the question is what LCP timeout does Aquiss use? If they are different then for disruptions of a duration between the settings on the two ends you will have a case where one end could have re-established without a PPP drop and re-login but the other won't allow it. The additional overhead is probably only a second or so, so a mismatch isn't that big an issue however.

If you urgently need to know that the link appears to have dropped (e.g. because that would trigger a change in routing on your side to use an alternative path) then having a very short LCP timeout on your end might be appropriate. If the FTTP line is your only internet connection and knowing that it has dropped is not important to you then a longer timeout might be appropriate.

For reference, AAISP allows customers to choose the LCP timeout on their side from a (default) 60 second timeout for the "normal" case or a "fast" 10 second timeout for those who have bonded lines and want AAISP to detect a drop and reconfigure the bonding to take account of it more quickly.

Thanks @Dassa,

My fascination re LCP Echo is due to my historically unreliable FTTC connection, where connection durations were all over the place until the final few months when they defaulted to every 2 weeks following some engineer interaction. With FTTP, I want see the longest connection duration I can achieve.

A few months ago, I had seen messages in my router that said 5 echo requests had not been acknowledged and thus the link was being re-established. I thought that the 1 second request frequency from the router and the 5 response threshold may have been "not enough" and therefore I increased it to 6. I also thought that maybe a request frequency of 1 second was too high and should be increased.

There was an incident as reported by my suppliers last night. The router shows the LCP echo request / reply heart beat detected the problem.

[23 Jun 2026, 19:25:22 UTC] daemon.info: dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.175 78:60:bb:XX:XX:XX Samsung_A17_2_4
[23 Jun 2026, 19:31:35 UTC] daemon.info: pppd[8282]: No response to 6 echo-requests
[23 Jun 2026, 19:31:35 UTC] daemon.notice: pppd[8282]: Serial link appears to be disconnected.
[23 Jun 2026, 19:31:35 UTC] daemon.info: pppd[8282]: Connect time 29204.7 minutes.
[23 Jun 2026, 19:31:35 UTC] daemon.info: pppd[8282]: Sent 11270205201 bytes, received 180753569332 bytes.
[23 Jun 2026, 19:31:35 UTC] daemon.notice: netifd: Interface 'wan_6' is disabled
[23 Jun 2026, 19:31:35 UTC] daemon.notice: netifd: Network device 'pppoe-wan' link is down
[23 Jun 2026, 19:31:35 UTC] daemon.notice: netifd: Network alias 'pppoe-wan' link is down
[23 Jun 2026, 19:31:35 UTC] daemon.notice: netifd: Interface 'wan_6' has link connectivity loss
................
[23 Jun 2026, 19:32:18 UTC] daemon.notice: netifd: Network device 'pppoe-wan' link is up
[23 Jun 2026, 19:32:18 UTC] daemon.notice: netifd: Network alias 'pppoe-wan' link is up
[23 Jun 2026, 19:32:18 UTC] daemon.notice: netifd: Interface 'wan' is now up

I noticed the outage on my Ipad. I could disable the echo request/reply heart beat on my router and let the remote end (ISP) take care of the link. If there is an issue, then irrespective of how fast my router detects it, I am at the mercy of the remote end recovering because I don't have a second / fallback line.


I just wondered what everyone else did and whether there was a "best practice".

LCP echoes should not be disabled.

I connected directly to the ONT and used WireShark to get the LCPs. It looks like the remote sends Echo Requests every 10 seconds.

Text

1 23 45 67

[b]No.  Time            Source                  Destination        Protocol        Length               Info[/b] 68      16.5661501      Nokia_de:c2:81      BizLink_af:84:49    PPP     LCP     60                      Echo Request69      16.566396       BizLink_af:84:49        Nokia_de:c2:81  PPP     LCP     34                      Echo Reply 108     26.5812639      Nokia_de:c2:81      BizLink_af:84:49    PPP     LCP     60                      Echo Request109     26.5814132      BizLink_af:84:49        Nokia_de:c2:81  PPP     LCP     34                      Echo Reply 178     36.5968568      Nokia_de:c2:81      BizLink_af:84:49    PPP     LCP     60                      Echo Request179     36.5970017      BizLink_af:84:49        Nokia_de:c2:81  PPP     LCP     34                      Echo Reply

I've asked my ISP how many Echo Requests need to go unanswered before the link is deemed stale.

I'll put the same values into my router.

I want to avoid the situation where the echo requests my router sends and lack of reply from the remote end trigger a stale connection scenario and therefore the router forces a disconnection/reconnect. My current settings of 1 second frequency and 6 missed replies seem very aggressive.

Dassa thanks for your help.