Good Morning, I've recently migrated to a new ISP (Zen UK), from BT, and am facing an annoying problem - head banging against a brick-wall has started - it is the same broadband product, i.e VDSL2/FTTC, just a different ISP. For the last 3 years my current setup has functioned on BT, since the migration to Zen things seem to have gone a bit wonky - the Zen aspect may or may not be related.
I have an OpenBSD 5.7 router connected to either an HG612 or ECI modem, via a switch the PPPoE interface is on a VLAN and in its own rdomain, I encounter the same problem with both. The problem? PPPoE (kernel) drops frequently between 1 - 15 minutes of connected time and reconnects, then repeats, the modem sync is not dropping. The router has an OpenVPN (UDP) VPN connection that routes all traffic to the OpenVPN server in the DC. I should add, I still have another line still with BT with the exact same setup and this does not encounter the problem and has been up for some 70 days. Between migrating from BT -> Zen, the only thing that changed on the OpenBSD router was the PPPoE username/password. From the moment the migration occurred, this problem started occurring. Thing's I have ruled out: - Cabling, no errors on switch ports but all cables have been replaced - Not HG612 or ECI modem related, that I can see, problem happens with both. Initially thought it could be the HG612 bug with UDP/VPNs, however the modem is unlocked and running the latest release. The trick of unplugging and reseating the eth cable doesn't make any difference. - OpenBSD config, there is minimal kernel PPPoE config same setup works with BT and continues to work - OpenBSD OS versions (tried 3 different releases, 5.5, 5.6 and 5.7) - Rolled back RFC4638 setup, i.e for MTU 1500. The Max Payload is negotiated successfully during the connection process, so I don't believe this is the issue but have tried without anyway. - LCP echo/replies are all being sent and responded to in a timely manner, there are no ignore/dropped echos/replies before the 'term-req' is received' Enabled debug on the OpenBSD pppoe interface and it seems to me, that Zen are sending 'term-req' - although I need to make sure my reading of the logs is correct i.e 'lcp input' is the ISP/Zen? However, the below logs also show 'Down event (carrier loss)' but there is no carrier loss (the modem stays in sync) and all ethernet ports between the modem/switch/router stay up, no errors, etc - although this could be because the term-req has already been received and the disconnection is in process. ### Jun 28 21:15:56 rtr00 /bsd: pppoe0 (8864) state=3, session=0x2eb output -> 84:26:2b:a2:3c:da, len=139 Jun 28 21:15:56 rtr00 /bsd: pppoe0 (8864) state=3, session=0x2eb output -> 84:26:2b:a2:3c:da, len=139 Jun 28 21:15:56 rtr00 /bsd: pppoe0: lcp input(opened): <term-req id=0x0 len=4 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-3f-75-80-e0-83-59-1b-c3> Jun 28 21:15:56 rtr00 /bsd: pppoe0: lcp opened->stopping Jun 28 21:15:56 rtr00 /bsd: pppoe0: phase terminate Jun 28 21:15:56 rtr00 /bsd: pppoe0: ipcp down(opened) Jun 28 21:15:56 rtr00 /bsd: pppoe0: ipcp opened->starting Jun 28 21:15:56 rtr00 /bsd: pppoe0: ipcp close(starting) Jun 28 21:15:56 rtr00 /bsd: pppoe0: ipcp starting->initial Jun 28 21:15:56 rtr00 /bsd: pppoe0: lcp send terminate-ack Jun 28 21:15:56 rtr00 /bsd: pppoe0: lcp output <term-ack id=0x0 len=4> Jun 28 21:15:56 rtr00 /bsd: pppoe0 (8864) state=3, session=0x2eb output -> 84:26:2b:a2:3c:da, len=12 Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp TO(stopping) rst_counter = 0 Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp stopping->stopped Jun 28 21:16:06 rtr00 /bsd: pppoe0: phase dead Jun 28 21:16:06 rtr00 /bsd: pppoe0: timeout Jun 28 21:16:06 rtr00 /bsd: pppoe0: disconnecting Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp down(stopped) Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp stopped->starting Jun 28 21:16:06 rtr00 /bsd: pppoe0: phase establish Jun 28 21:16:06 rtr00 /bsd: pppoe0 (8863) state=1, session=0x0 output -> ff:ff:ff:ff:ff:ff, len=18 Jun 28 21:16:06 rtr00 /bsd: pppoe0: Down event (carrier loss), taking interface down.<7>pppoe0: lcp close(starting) Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp starting->initial Jun 28 21:16:06 rtr00 /bsd: pppoe0: phase dead Jun 28 21:16:06 rtr00 /bsd: pppoe0 (8863) state=2, session=0x0 output -> 84:26:2b:a2:3c:da, len=38 Jun 28 21:16:06 rtr00 /bsd: pppoe0: session 0x2ee connected Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp open(initial) Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp initial->starting Jun 28 21:16:06 rtr00 /bsd: pppoe0: phase establish Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp up(starting) Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp starting->req-sent Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp output <conf-req id=0x5 len=14 05-06-d2-4f-8e-af-01-04-05-d4> Jun 28 21:16:06 rtr00 /bsd: pppoe0 (8864) state=3, session=0x2ee output -> 84:26:2b:a2:3c:da, len=22 Jun 28 21:16:06 rtr00 /bsd: pppoe0: lcp input(req-sent): <conf-req id=0xa7 len=19 01-04-05-d4-03-05-c2-23-05-05-06-1a-89-24-a4-00-00-00-00-00-00-00-00-00-00-00-20-85-80-10-ff-1c-cb-c5> ### .. If anyone has any suggestions, or seen anything similar previously, I'm all ears. Going to open a case with the ISP as well. Thanks, Ed
