In reply to a post by Andrue:

The router is a Cisco 154x and has an Alcatel chipset which the ISP agent said probably doesn't help.

Is this model correct? Is it still a current and supported model?

Cisco had some problems with their lower range (e.g. 8xx & 18xx) routers and those using a HWIC-1-DSL with ADSL2+, for which they released some updates.

Make sure your ISP is using recommended firmware and appropriate hardware for ADSL2+

The following has some more information:
http://www.cisco.com/en/US/prod/collateral/routers/p...
http://www.cisco.com/en/US/prod/collateral/routers/p...
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ds...

Bonding doesn't provide redundancy or resilience, you should use load balancing for that.

In reply to a post by MrSaffron:

There was a 1 hour segment of mixed red and blue 6:40 to 7:15am today and what looks to be fairly standard busy office until the early evening.

In theory there ought to have been nothing running at that time. We're a small office of engineers and I arrive first - at a couple of minutes before 7:15 today. I power cycled the router because I had no connectivity when I got in.

My Broadband Ping

It isn't normal (or wasn't until a month or so ago) for us to get any such blocks. If you look around 2pm you can see the result of me and a colleague applying Windows updates to two new machines that arrived in the office. Quite a bit of blue but not much red.

Edited by Andrue (Thu 11-Oct-12 11:12:02)

In reply to a post by WWWombat:

In reply to a post by Andrue:

In reply to a post by Andrue:

It's being tested now. So far the results are intriguing. I unplugged just one line and didn't bother to reboot the modem (it's a single modem with dual cards). Throughput has dropped (well duh) but that's all. No errors, no horrible ping.

I plugged the line back in, waited a minute then unplugged the other one. That caused a reaction. Killed the connection in fact. I've rebooted the modem now and it's back (on just the other line).

By "Killed", I guess you mean that the TBB graph went totally red? Rather than the red/blue combination?

Yup. I also plugged the original line back in and it didn't help.

So I agree that the 'red+blue' combo doesn't actually mean 'no connection' but it does mean 'unusable connection'. The mystery is why it happens and why it seems tied to 21CN.

I've just spent five minutes downloading Ubuntu (well running the download, anyway). I'm now going to plug the first line back in so that both lines are active. I won't reboot the modem though.

Edit: The router detected and and seamlessly increased our bandwidth back to the dizzy heights of 3.2/0.7.

Edited by Andrue (Thu 11-Oct-12 11:25:42)

Try saturating your upstream too

In reply to a post by MrSaffron:

Try saturating your upstream too

Okay I just did that. Aside from slightly slowing down browsing it didn't really do much.

My Broadband Ping

The red block is because our ISP asked us to turn the router off for 15 minutes to clear some stale sessions. They say there should be no problem reconfiguring our router to ADSL but they want to see how it runs for a few more hours.

I would try forcing ADSL or ADSL2 modulation like a few others here have mentioned

This seems to stabilise ADSL2+/21CN connections for those on longer lines.

In reply to a post by FRS_Plunderer:

In reply to a post by Chrysalis:

openreach do the home visits and probably provide stats from those visits on what they think are home wiring faults.

And your evidence that the stats are wrong is?

your evidence of them been right?

my view is based on a few things.

1 - my personal experience.
2 - aaisp's point of view.
3 - the long line policy from openreach where if a line is long a proper investigation isnt even carried out.

Do Cisco routers of this class really not have the SNMP Line MIB? Do "quality" ISPs really not have support people who know how to access it and plot it with MRTG and the like? We know BTwholesale are incapable of (or unwilling to do) that kind of thing, but then what are they capable of...

Get a look at the line error rate, sync speed, and SNR margin. Raw, rather than several levels of layering away, as the effects seen at IP level inevitably are.

Looking at IP-level figures is, as you have already pointed out, not an ideal way to debug a possible lower-layer (line level) problem, which the TCP layer will do its very bestest to mask (yes I know PING isn't TCP, but...).