• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1388
  • Last Modified:

Troubleshooting a (seemingly) ropy DSL connection

Hi There experts.

I have a good knowledge of Cisco routers NAT e.t.c., but a very poor knowledge of ADSL technology and i need some assistance in troubleshooting a Cisco DSL (870 Series I seem to remember) router.

In october 2010, the router started dropping its connection. The actions I took were to eliminate patching issues (by repatching and even then taking the thing down to the telecomms entry point to plug it in there) and then start to diagnose using cisco commands. I honestly can't remember what commands I ran at the time but I ended up with the following debug logs which implied an issue on the line.

000064: *Jun 28 00:31:49.035 UTC: DSL(ATM0): sleep 5 seconds
000065: *Jun 28 00:31:54.035 UTC: DSL(ATM0): Send ADSL_OPEN command.
000066: *Jun 28 00:31:54.035 UTC: DSL(ATM0): Using preferred open mode
000067: *Jun 28 00:31:54.035 UTC: DSL(ATM0): Using ITU sync first for 5 secs, then ANSI/ITU sync alternatively
 for 2 secs
000068: *Jun 28 00:31:54.035 UTC: DSL(ATM0): Using subfunction 0x0
000069: *Jun 28 00:31:54.035 UTC: LOCAL:Max noise margin for power cutoff 31
000070: *Jun 28 00:31:54.035 UTC: DSL(ATM0): GPCI[0] 0x5
000071: *Jun 28 00:31:54.035 UTC: DSL(ATM0): GPCI[1] 0x9
000072: *Jun 28 00:31:54.035 UTC: DSL(ATM0): GPCI[2] 0x1
000073: *Jun 28 00:31:54.035 UTC: DSL(ATM0): GPCI[3] 0x0
000074: *Jun 28 00:31:54.035 UTC: DSL(ATM0): Sent extended command 0x3
000075: *Jun 28 00:31:56.535 UTC: DSL(ATM0): 1: Modem state = 0x9
000076: *Jun 28 00:31:59.035 UTC: DSL(ATM0): 2: Modem state = 0x9
000077: *Jun 28 00:32:01.535 UTC: DSL(ATM0): 3: Modem state = 0x10
000078: *Jun 28 00:32:04.035 UTC: DSL(ATM0): 4: Modem state = 0x10
000079: *Jun 28 00:32:06.535 UTC: DSL(ATM0): 5: Modem state = 0x10
000080: *Jun 28 00:32:09.051 UTC: DSL(ATM0): 6: Modem state = 0x10
000081: *Jun 28 00:32:11.551 UTC: DSL(ATM0): 7: Modem state = 0x10
000082: *Jun 28 00:32:12.455 UTC: DSL(ATM0): Received response: 0x22
000083: *Jun 28 00:32:12.455 UTC: DSL(ATM0): Open failed: Req. min. rate + noise margin + PSD not possible on the line -- retrying

We continued to troubleshoot, putting in a different router and then eventually, when the problem wouldn't go away, a totally different model of DSL router (a Netgear if I remember rightly). The netgear held the connection well however BT (telecomms provider) had in between times done some "testing" on the line and had told us that there was no issue. My comment at the time was that if we plugged the Cisco 870 back in, it would probably hold the connection now also. Much to the amazement of the customer, i was right - and we ran the same router with the same config for another 4 months without fault.

Well the problem has now started happening again and I need some pointers for a way to prove that this is either a telecomms issue (i.e. a BT issue) or a router issue - I don't mind which - but I don't really know where to start with it.

Could someone give me some pointers on this? Cheers in advance.


4 Solutions
Aaron TomoskySD-WAN SimplifiedCommented:
Call a local telecoms guy. They can check voltages, db loss, snr, and other stuff on the line. It is just a phone line after all.
Common for ADSL accounts to have a "rip and rebuild"...which is some internal code for a procedure to provision the account again.  Speakeasy was helpful, and 100% truthful about what they were doing, and how they coordinated testing with the telco whose line was leased.  The ISP would tell me what the telco was doing, what the test results were, and what they were looking for.

The telco-provided lines I've had to troubleshoot, ATT or Verizon, they never said what was going on.  Just "we're testing the line, and everything's fine on our side".  Then, the circuit would magically start working without our doing anything.  Deceptive on their part, because something _was_ obviously wrong.  But, the circuit would come back up and we could get back to work.

At one home, I had the telco trim back a neighbor's tree and replace the line to the house.  The test numbers were within expectations, but the line would drop whenever there was wind and the drop to the house moved.  So, a "good" test result must be taken with a grain of salt.
Gerwin Jansen, EE MVETopic Advisor Commented:
I experienced something similar, just happened to be a bad connection in the wall socket where the phone line got into my room. I opened the socket, reconnected the wires properly and my issue got fixed. This being a DSL connection, I assume you got your splitter connected properly and that it is not broken.
I don't use the "free" splitters in commercial.  They're cheap, and I've had to replace half of them for failure or breakage because they hang dangerously from the wall jack.

I've used a Wilcom ADSL POTS filter/splitter a few times with zero problems.  Wall-mount with screws, then tack down your lines.  They'll never shake loose.  You'll also have a good testing point, as the contacts are very accessible.
prodriveitAuthor Commented:
Hmmmm, thanks for the input guys. I was looking for a more "Cisco" way of determining what was up - but maybe I'm lookinig for answers where there are none. I'll spread the points across all 4 contributions as they are all equally useful.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

KuppingerCole Reviews AlgoSec in Executive Report

Leading analyst firm, KuppingerCole reviews AlgoSec's Security Policy Management Solution, and the security challenges faced by companies today in their Executive View report.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now