Until recently, at work, we had two lines which were bonded using MLPPP, this has worked flawlessly for over a year, come to the beginning of this week when one line wouldn't connect due to the wrong endpoint discriminator, after many tests and time on both my, and my ISP's (Entanet) part we came to the conclusion that one line had switched to another node.
Enta have attempted to rectify this by forcing both lines on to the same LNS, whilst this does work and enabled the lines to bond, the upload speed takes a massive hit for no discernible reason. Both line sync at around 3.5mbit and 832kbps upload, when the lines are tested in isolation (before the LNS is forced) they test as you would expect, as soon as Entanet forces the LNS the upload speed crumbles to just 190kbps, this is not a line fault or equipment fault as I've spent all morning with Enta swapping things around, trying different logins and what not. The issue is directly related to forcing the lines connect to a specific LNS, what is strange however that is even the line that's on the correct LNS to start with also suffers the upload speed hit.
Thanks for reading this far, and so we continue...
Level 2 support at Enta have only encountered this 3 times before, they've spoken with BTW but they refuse to rectify the node issue because it would involve disconnecting a large number of customers (yet when they need to move people they just do it?), initial thoughts are the line has been moved due to capacity issues.
This leaves me with a couple of solution, neither of which are straight forward. One of our lines has a redcare service on it and one is just a normal phoneline. The solution would be to provide a new line, the new line will terminate at one of the two locations that our existing ones do, whichever line is the 'odd one out' would be terminated, but by doing this we risk that the 'odd one out' is going to be the redcare line which entails more expense getting the redcare moved over and a visit from the alarm engineer.
As a side note the lines were testing with a PSTN fault of 'discon network' intermittently but this wasn't affecting my phones or line sync, I reported it to BT and the fault is now cleared according to their faults website.
The second option is to keep the lines as they are but move to a load balanced solution, the only problem with this is we will not be able to utilise the full bandwidth without multi-threading our transfers, it also makes QoS a little trickier as we have VoIP phones and we need to reserve a portion of bandwidth so that they don't begin to 'break up' under heavy network loads.
We do perform a lot of single threaded transfers and we do ideally need the MLPPP solution to work as it once did, there are no other services available to us and there's no date for FTTC (which I might add would solve everything as the cab is only down the road).
Sorry for such a massive post but there's a lot that's gone on that can't simply be condensed into two or three sentences.
Thanks for any suggestions you might have.
Edited by PiKe (Thu 14-Jun-12 14:26:30)