O Canada! > Canadian > Canadian Broadband > Caneris MLPPP (4xDSL) + 5 months support = 0.37Mbps.

reply to CanerisErik

Re: Caneris MLPPP (4xDSL) + 5 months support = 0.37Mbps.

reply to CanerisErik
Erik,

Now I am getting perfectly normal results.

»www.speedtest.net/result/1747643561.png

What did you change?

Eric

Dude, Caneris has access to my router ... both the web interface and via ssh. Try to keep up.

Also, I believe my lines can be isolated at the Caneris LNS.

reply to edykstra

We've had a similar issue with a customer recently where his DSL lines would have 2-3 different BASes available and each of them would be in completely different cities. As a result you'd end up with packets going in completely different directions. As much as it was "supposed" to work it was slowing things down considerably. After figuring that out we basically had him program his client to select a specific BAS for all his lines and his slow speed issues went away.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )

Are there really situations where a PADI requests in multiple BAS offering a PADO ?

I was under the impression that each DSLAM was assigned to one BAS. (but that 2 adjacent DSLAMs could be assigned to different BAS).

reply to jfmezei

Interesting. In my case, I have always had the same BAS when doing traces and never seen PADOs coming from multiple sources.

But switching from one bell line to another (wet to dry, or changing appartment in same building) yielded a different BAS.

reply to edykstra
Very early this morning, and about 12:30AM, the MLPPP device showed ALL lines were disconnected. I found this because it was the first place I went to check once I realized I had been disconnected from the Internet.

I clicked 'Re-connect' and they came back up.

Why? This is a production environment, I can't have it going off line whenever it wants like this, even if it is rare.

I've tried many 'setups'. Once, I had dedicated servers a supposedly reputable firm. Then I got an email, that one of my servers had been hacked, and that I needed to resolve the issue within 4 hrs, or they would take my servers off-line. My only option then, would be their $200/hr tech support.

I scrambled. Got a Linux guru on it, and he said that while it was impossible to tell in such a short time without auditing tools having been installed, if someone had hacked the server, he could see NO EVIDENCE of any traffic etc. being blasted from my server.

So, in the end, we decided to tell the provider we were satisfied the issue was resolved. They 'checked' and confirmed all was well. I didn't even bother to let them know we did NOTHING.

I immediately began steps to move elsewhere and ultimately self-host. It isn't that hard, but apparently simple phone lines are.

a PPPoE environment is not "production quality". You can paliate this by having a good router that will automatically re-establish connections after a failure. (which is very hard because of Bell's lock-out mechanism designed to block you if you make constant attempst to reconnect until the line is fixed).

You could get an HSA line. More expensive, but is at ethernet level. No PPPoE session to worry about. So if line goes down, it isthe same as unplugging an ethernet cable from a switch. Traffic automatically flows again once you reconnect it.

reply to edykstra

Erik,

I know. But this was at 12:30AM on Feb 6, not Feb 5.

Eric

Here we go again!

Took me hours to get back on-line after pathetically SLOW speeds, but at least I am on-line now.

Speed is still pathetic though: »www.speedtest.net/result/1846005538.png

NOTHING has changed on my end. So, this is either Bell, or Caneris.

I think speed is the symptom, not the root cause. For example, using the MLPPP router diagnostics screen, I can't even get a single result on ping/traceroute for 4.2.2.1 (Google.)

So, what is likely going on, is that the network is somehow preventing DNS lookups.

WHY!

reply to edykstra
Well - an update for everyone.

I enjoyed approximately 2 months of trouble free MLPPP service at speeds that were as expected. Then, as if if someone 'flipped a switch', the speed dropped down to 0.4Mbps up and down.

With the 'issue' back, I informed Caneris to see if we could take advantage of this to learn what was going on.

Erjon from Caneris made a site visit on Friday. He arrived with a brand new MLPPP router flashed with the latest firmware. Erjon expected that all he had to do, was change the username/password to my account, and swap it out with the existing one, and test. We completely unplugged my LAN during this, to eliminate any possible variables/issues there.

However, more than 2 hours later and Erjon had made zero progress. The results of all the troubleshooting to this point are not conclusive, but we've now decided it is either;

1. The TP-Link 8816 bridges are older models that are incompatible with the recent versions of OpenWRT.
2. Bell is sensing the traffic is MLPPP and slowing it to a crawl.

Both options seem very unlikely. The only 'upside' to the site-visit from Erjon is that he now concedes that there is nothing I am doing wrong and that there is a 'problem' that is out of my control. Caneris will continue to work through this with me.

Early next week, Caneris is shipping 4 TP-Link bridges they know to work well. I will swap those out and test.

We fully expect that the new bridges will change nothing, but then at least we will have tried everything, and we can focus on policing Bell.

Does anyone have any ideas/feedback on what could be going on here?

Thanks,

Eric

Have you done tests on each individual link without MLPPP to ensure the link themselves are capable of the expected speeds ?