Frequent loss of authentication but not DSL

[#1]

I've got a ticket open on this one, but the more the merrier! It's only been on the go for a week or so!! Ever since I was transferred back from Tiscali LLU to BT IPStream on 27th July I've had frequent data flow problems (usually complete cessation) but without loss of the DSL signal. I've had the DMT utility running most days, and today I actually caught the little blighter doing it!
What seems to be happening is that the route through to the PN authentication server is dropping out, as indicated by no data flowing on the network meter and inability to browse. The DSL signal is relatively steady apart from a tiny glitch in the SNR at the instant it happens (see attached snapshot, the orange vertical line at about 10.42), but the Internet light on the router is out. If I enter the router's front page it gives me the option to reconnect via a button, and on clicking it, it tries and eventually returns to the same page (with the Connect button) but without connecting.
The router's error log is showing.
ADSL Sync Pass
ATM OAM F5 Segment Ping Pass
ATM OAM F5 End-to-end Ping Pass
PPP Server Connection Fail
ISP Authentication Fail
Assigned IP Address Fail
Ping Default Gateway Fail.
My router is a BT Voyager 2110, which is designed around BT IPStream Max apparently. Their excellent helpline is telling me that the router will handshake with the ISP Authentication server every five seconds if it detects a loss of internet connection (as opposed to DSL signal) and will keep doing that until it gets one. The ISP authentication server should, they say, return a handshake when it gets my login details and then we're in. This doesn't seem to be happening. The only way I can log back in is to do a hard reboot on the router and then everything's fine for a few hours. It looks as though the route through to PN is not working properly.
I've actually gone to the trouble of getting hold of a second router and this does exactly the same thing, so I very much doubt it's my kit. Could it be that the backhaul from the exchange to PN, or even the PN authentication server, is scrambling the handshake data somehow? Could it be anything to do with the fact that doing a hard reboot connects through a different gateway (and hence a clean connection)? Both routers have the latest firmware installed.
Any help will be gratefully received!!  I dread to think what my max. sustainable data rate will be after all this!  Thanks.

[#2]

Hi nozzer,
I've given the faults team a nudge, we should get this raised to BT for you today and hopefully ask them to proactively monitor for drops in PPP. You should get an update to your ticket shortly.

[#3]

I've seen this happening too - several drops a day of Authentication without ADSL losing sync.  After that the modem/router attempts to re-authenticate but always fails - the only way to get back (for me) seems to be to pull the plug on the router, wait a while then power-up. Tried several routers - same problem. (But all were Belkin - so a firmware fault common to all is possible). 
Not sure if it is related to your problem, but it does sound the same. (I'm on PAYG 15GB)
I did notice that I had NO such problems all the time I was connected via the BT RIN trial - as soon as I got dumped off that (because the trial was finally pulled), the drops re-appeared. 
HTH with any tracing at PN.

[#4]

Thank God it's not just me then!!  Both my Voyager 2110's do it and I borrowed a Netgear DG834, which was the same. MUST be something to do with the authentication path because I think the Voyagers and the Netgear use different chipsets? Pulling the plug is the current answer for me also; can't be good for the equipment in the long run.
PN have now referred it to BT (thanks to orbrey!) so I'll post any results. I've had two loss of auth's today in close succession. Wouldn't be so bad if the router signed itself in again. Tiscali wasn't such a stable line speed-wise (that did lose sync on occasions) but it certainly didn't do this.

[#5]

It sounds like the same problem, doesn't it?  It has occurred to me in the past that the ppp drops may simply have been due to rebalancing of the gateways at PN and the real problem was simply that the router was unable to re-authenticate correctly.  If the router reconnected automatically I probably wouldn't even notice the drops.  Perhaps PN (or BT) had set some kind of a minimum period between login requests being accepted by the radius server in an attempt to minimise the hit when a large number of accounts are dropped (due to a failure or rebalancing) and all try to re-authenticate at the same time.  Perhaps our routers are trying to login too rapidly and are being ignored on every attempt.  The only problem with that theory is if I hit the "disconnect" button in the control panel, I think that the router stops trying to login until I click "connect" - but that still doesn't work 
Anyway, If PN or BT do make any progress tracing your fault, please post back here.

[#6]

NGNet...  was your problem occurring during the 10-day training period by any chance? It's probably just a complete coincidence (  ) but exactly 10 days since my IPStreamMax service was commissioned, the problem seems to have gone away (to the exact hour actually!!!). It's possible that someone somewhere has tweaked something with a sharp stick I suppose.
And a question for a PN team member ..  this fault has meant that I've had to do many hard reboots of the router, all during the training period. My MSR has slowly reduced presumably because the training process has interpreted the shut-downs as instability although I've not actually lost DSL sync once. The MSR is now at 4Mbps, whereas on Tiscali it was stable at 8Mbps. I'll leave it at this value for now until the fault is sorted, but in principle, is it possible for the MSR to be manually reset to a higher figure by PN, or even have the training process restarted after the fault is fixed?

[#7]

No, my line has been on Max for several years now.  However, I've not seen any ppp drops today either - so maybe someone at PN has optimised something with a big stick.  Then again I have had periods of several days when the connection stayed up before. We'll see.

[#8]

A few more thoughts...
When you lose connection - theres 3 "places" where you can lose it
1. Your ISP can disconnect you - (you lose the PPP session).
2. It can occur between the exchange and the RAS (ATM session) (authentication part 1).
3. You can also lose sync (between your home and the exchange).
I am certainly not losing DSL sync, so item 3 is out. My router's error log (see above) shows that the ATM pings are passing so item 2 is out (I'm not totally sure that this is 100% correct but intuition would seem to indicate that it is). So...   item 1...    are the PN techs absolutely sure that the authentication server(s) are behaving? It seems to me that maybe the reason my router won't reconnect is that perhaps the authentication server thinks I am still connected for some reason, and therefore won't let me in again unless I physically switch the router off and on again (ie force a DSL resync).
And I do recall that way back in 2006 a large number of PN users who were on Tiscali LLU suffered exactly this for many weeks. It eventually turned out to be one of the PN Gateway servers (LLU customers were successively put on to different gateways to try to isolate the problem and eventually the rogue server was isolated, beaten up and taken to the scrapyard). See the last entry on this thread.
http://usergroup.plus.net/forum/index.php/topic,3347.105.html
Has any tweaking been done on the gateways recently...  especially overnight on Thursday 6th. This is when this problem seemed to settle down with only one loss of PPP session since then (as opposed to several a day).

[#9]

Quote from: nozzer

Has any tweaking been done on the gateways recently...  especially overnight on Thursday 6th. This is when this problem seemed to settle down with only one loss of PPP session since then (as opposed to several a day).

I've looked back through our change control logs and the only thing that springs out at me is some work we did on one of the RADIUS databases on the 6th. This was to add additional tunnel end points (basically inserting a few database table entries) for our next two 622 central pipes and the second WBMC host link (neither of which are live). I can't see how this would have affected anything.
Just a thought, but have you tried giving this a go?

[#10]

Thanks Bob, I shall give it a spin and report back. My PPP problems started at the exact instant I was transferred from the Tiscale LLU back to BT on 27th July, so the work you mention doesn't seem to be related. There do seem to be quite a few users with this problem now.

[#11]

Can anyone who is familiar with this please have a quick gander at page 13, section 4.4.2.10 "PPPoE Aspects". Doesn't this imply that BT IPStream Max is actually compatible with PPPoE? (reference Bob Pullen's suggestion above).
http://www1.btwebworld.com/sinet/386v3p0.pdf

[#12]

Yes PPPoE can be used as I have used it but it's normally used if you run the modem in bridge mode which pass all traffic to a single point, either a router or PC. Then the router/PC is configured for PPPoE and does the login/authentication. It's not meant to be used by the modem.

[#13]

Quote

Yes PPPoE can be used as I have used it but it's normally used if you run the modem in bridge mode

Is that Bridge QoS? If so, how is it set up on this router (Voyager 2110), ie what values?
EDIT..  cancel that! I've found the answer. 

[#14]

Does this sound familiar?
http://forums.thinkbroadband.com/ukonline/3682222-frequent-disconnects-on-ipstream.html?vc=1
http://forum.kitz.co.uk/index.php?action=printpage;topic=5448.0
..  plus many more on Google! They all refer to a lost PPP session without sync loss. What's BT up to?

[#15]

Hi all,
Have you tried changing the connection to PPPoE / LLC at all? Bob's had some luck with this (as I think he posted earlier). This would hint at some kind of large scale firmware upgrade on the exchange kit - just a guess there but it's the most likely explanation at the moment.