One for the BT/DSL experts! Sync keeps dropping, no-one knows why...

Soldato
Joined
18 Oct 2002
Posts
7,139
Location
Ironing
Following on from a previous thread where I was asking about line stats and whether they were all good, I've got a more interesting problem with my fairly new DSL line.

Short story: ISP are AAISP (awesome), line is a BT 21CN, router is a Cisco 877. Router worked fine for the last 2.5 years on a Be Line in London.

Problem: The ATM0 interface randomly goes down for about 10 minutes at a time, before coming back up again. This happens ~5-10 times per day.

Here's a connection graph of the last three days provided by AAISP. The purple bits are no connection.
grapho.png


I switched on debug logging for the ATM interface on the router, as well as debugging dialer and PPP events. Here's what happens when the connection drops:

Code:
Mar  1 07:18:44 talkbot 6447: talkbot: 006379: *Apr 18 05:14:22.516 BST: DSL(ATM0): Defect: LOM
Mar  1 07:18:44 talkbot 6448: talkbot: 006380: *Apr 18 05:14:22.516 BST: DSL(ATM0): Defect: LOS LOF: retraining
Mar  1 07:18:44 talkbot 6449: talkbot: 006381: *Apr 18 05:14:22.516 BST: DSL(ATM0): Received response: 0x41
Mar  1 07:18:44 talkbot 6450: talkbot: 006382: *Apr 18 05:14:25.016 BST:  atmsar_atm_lineaction(ATM0): state=0
Mar  1 07:18:44 talkbot 6451: talkbot: 006383: *Apr 18 05:14:25.016 BST:  atmsar_1a_teardown_vc(ATM0): vc:1 vpi:0 vci:38
Mar  1 07:18:44 talkbot 6452: talkbot: 006384: *Apr 18 05:14:25.016 BST: ATM0.1 VC 0/38 Current Total Active VC Count 0
Mar  1 07:18:44 talkbot 6453: talkbot:
Mar  1 07:18:44 talkbot 6454: talkbot: 006385: *Apr 18 05:14:25.016 BST: ATM(): IP multicast cache invalidated for ATM0.1
Mar  1 07:18:44 talkbot 6455: talkbot: 006386: *Apr 18 05:14:25.016 BST: ATM: PVC removed, ATM0.1 VCD 1 (0/38)
Mar  1 07:18:44 talkbot 6456: talkbot: 006387: *Apr 18 05:14:25.016 BST: DSL: SM: [DMTDSL_SHOWTIME -> DMTDSL_RE_OPEN]
Mar  1 07:18:44 talkbot 6457: talkbot: 006388: *Apr 18 05:14:25.016 BST: DSL(ATM0): Send ADSL_CLOSE command.
Mar  1 07:18:44 talkbot 6458: talkbot: 006389: *Apr 18 05:14:25.016 BST: DSL(ATM0): Sent command 0x4
Mar  1 07:18:44 talkbot 6459: talkbot: 006390: *Apr 18 05:14:25.548 BST: DSL(ATM0): Received response: 0x25
Mar  1 07:18:44 talkbot 6460: talkbot: 006391: *Apr 18 05:14:25.548 BST: DSL(ATM0): Connection closed
Mar  1 07:18:44 talkbot 6461: talkbot: 006392: *Apr 18 05:14:25.548 BST: DSL: SM: [DMTDSL_RE_OPEN -> DMTDSL_DO_OPEN]
Mar  1 07:18:44 talkbot 6462: talkbot: 006393: *Apr 18 05:14:25.552 BST: DSL(ATM0): Send ADSL_OPEN command.
Mar  1 07:18:44 talkbot 6463: talkbot: 006394: *Apr 18 05:14:25.552 BST: DSL(ATM0): Using subfunction 0x0
Mar  1 07:18:44 talkbot 6464: talkbot: 006395: *Apr 18 05:14:25.552 BST: LOCAL:Max noise margin for power cutoff 31
Mar  1 07:18:44 talkbot 6465: talkbot: 006396: *Apr 18 05:14:25.552 BST: DSL(ATM0): GPCI[0] 0x0
Mar  1 07:18:44 talkbot 6466: talkbot: 006397: *Apr 18 05:14:25.552 BST: DSL(ATM0): GPCI[1] 0x0
Mar  1 07:18:44 talkbot 6467: talkbot: 006398: *Apr 18 05:14:25.552 BST: DSL(ATM0): GPCI[2] 0x11
Mar  1 07:18:44 talkbot 6468: talkbot: 006399: *Apr 18 05:14:25.552 BST: DSL(ATM0): GPCI[3] 0x0
Mar  1 07:18:44 talkbot 6469: talkbot: 006400: *Apr 18 05:14:25.552 BST: DSL(ATM0): Sent extended command 0x3
Mar  1 07:18:44 talkbot 6470: talkbot: 006401: *Apr 18 05:14:25.988 BST: DBS is not configured on ATM0.1 vc 0/38
Mar  1 07:18:44 talkbot 6471: talkbot:
Mar  1 07:18:44 talkbot 6472: talkbot: 006402: *Apr 18 05:14:25.988 BST: DBS is not configured on ATM0.1 vc 0/38
Mar  1 07:18:44 talkbot 6473: talkbot:
Mar  1 07:18:44 talkbot 6474: talkbot: 006403: *Apr 18 05:14:25.992 BST: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
Mar  1 07:18:44 talkbot 6475: talkbot: 006404: *Apr 18 05:14:25.996 BST: %DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1
Mar  1 07:18:44 talkbot 6476: talkbot: 006405: *Apr 18 05:14:25.996 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down
Mar  1 07:18:44 talkbot 6477: talkbot: 006406: *Apr 18 05:14:27.017 BST: %LINK-3-UPDOWN: Interface ATM0, changed state to down
Mar  1 07:18:44 talkbot 6478: talkbot: 006407: *Apr 18 05:14:27.017 BST:  atmsar_atm_lineaction(ATM0): state=0
Mar  1 07:18:44 talkbot 6479: talkbot: 006408: *Apr 18 05:14:28.017 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to down
Mar  1 07:18:44 talkbot 6480: talkbot: 006409: *Apr 18 05:14:28.053 BST: DSL(ATM0): 1: Modem state = 0x9
Mar  1 07:18:44 talkbot 6481: talkbot: 006410: *Apr 18 05:14:30.553 BST: DSL(ATM0): 2: Modem state = 0x9
Mar  1 07:18:44 talkbot 6482: talkbot: 006411: *Apr 18 05:14:31.429 BST: ATM0: atmsar_vc_dlcx
Mar  1 07:18:44 talkbot 6483: talkbot: 006412: *Apr 18 05:14:33.053 BST: DSL(ATM0): 3: Modem state = 0x9
Mar  1 07:18:46 talkbot 6484: talkbot: 006413: *Apr 18 05:14:35.554 BST: DSL(ATM0): 4: Modem state = 0x9
Mar  1 07:18:48 talkbot 6485: talkbot: 006414: *Apr 18 05:14:36.574 BST: DSL(ATM0): Received response: 0x22
Mar  1 07:18:48 talkbot 6486: talkbot: 006415: *Apr 18 05:14:36.574 BST: DSL(ATM0): Open failed: The ATU-C and ATU-R are not configured for a common mode of operation -- retrying

It then cycles through the last few steps repeatedly for about 10 minutes, constantly getting the error "ATU-C and ATU-R are not configured for a common mode of operation". After about 10 minutes, it just seems to connect again.

IOS software verision is: Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1).

sh dsl atm0:

Code:
talkbot#sh dsl int at0
ATM0
Alcatel 20190 chipset information
                ATU-R (DS)                      ATU-C (US)
Modem Status:    Showtime (DMTDSL_SHOWTIME)
DSL Mode:        ITU G.992.5 (ADSL2+) Annex M
ITU STD NUM:     0x03                            0x2
Chip Vendor ID:  'STMI'                          'IFTN'
Chip Vendor Specific:  0x0000                    0x71B9
Chip Vendor Country:   0x0F                      0xB5
Modem Vendor ID: 'CSCO'                          '    '
Modem Vendor Specific: 0x0000                    0x0000
Modem Vendor Country:  0xB5                      0x00
Serial Number Near:    FCZ123464EX
Serial Number Far:
Modem VerChip ID:        C196 (3) capability-enabled
DFE BOM:         DFE3.0 Annex M (3)
Capacity Used:   99%                             90%
Noise Margin:     8.0 dB                         10.5 dB
Output Power:    19.5 dBm                        12.5 dBm
Attenuation:     42.5 dB                         19.0 dB
FEC ES Errors:    0                               0
ES Errors:        1                               1
SES Errors:       1                               0
LOSES Errors:     1                               2
UES Errors:       0                              155
Defect Status:   None                            None
Last Fail Code:  None
Watchdog Counter: 0xA5
Watchdog Resets: 0
Selftest Result: 0x00
Subfunction:     0x00
Interrupts:      161464 (0 spurious)
PHY Access Err:  0
Activations:     19
LED Status:      ON
LED On Time:     100
LED Off Time:    100
Init FW:         init_AMR-4.0.015_no_bist.bin
Operation FW:    AMR-4.0.015.bin
FW Source:       embedded
FW Version:      4.0.15


BT Wholesale have done a test and confirmed there's no fault on the circuit. I'm plugged into the test socket on the master faceplate using a microfilter I know works. AAISP think that it's a router problem, but I'm sceptical of this given that it's worked faultlessly for the last 3 years and wouldn't break just because I've moved house.

I've heard rumours that certain Cisco DSL FW versions didn't get on with certain DSLAMs, would it be worth my while flashing a different IOS or FW version to see if that sorts it?

Any ideas what it could be?
 
You may not want it to be your router ..... but it may be it

It would not be the first time that something did not survive a house move

Swap in another router (borrow a friends if you do not have a spare one)

If the problem persists try another micro filter

You could also disable any internal wiring from the master socket to eliminate
the internal wiring picking up noise ( I gained 1.5Mb/s from disconnecting it)
 
Its the router, infact its a known issue with no real solution.

My old 877 was perfectly fine on 8Mb BT broadband - the Alcatel modems in these can't properly hack the ADSL 2 and 2+ speeds - especially on annex M. As Yamahahahahaha says try the newer firmware as you might get luckily. Realistically though it probably won't help - it didn't for me and now Im stuck on my crappy Be modem :( I tried most of the old 2.x and 3.x firmwares. for the 4.x range I tried .15 and .18 with no luck

- Pea0n
 
Just loading the 4.0.18 firmware now. Had to hunt to find it as Cisco only list 4.0.17 as the latest.
 
Had this exact same issue with my BeBox (Thomson) and Be recently. Would drop 2-5 times per day and resync at half speed. I upgraded my router's firmware and it's fine now. Would suggest you try the same or maybe look at a different router.

Hope you manage to sort it!
 
Any luck el growse?

I replaced the firmware at 1pm yesterday, and at the same time requested removal of Annex M from the line.

I saw a couple of drops at about 6pm yesterday, and an email from AAISP telling me they'd done an AdminReset on the line. Since then, it's not gone down, so (touchwood) it's a bit more stable.

Reserving conclusions until I shove some decent load on the line tonight though.
 
I didn't think that the 877 supported Annex M?

ah, here we go from the Cisco site.
877: ADSL over analog telephone lines (ADSL2/ADSL2+ Annex A and Annex M (except UK Mask))

You need a 887VA for UK Annex M support (need to chase this at work tomorrow, as we have been having some odd problems with 857's of late on BT lines).
Cisco 887VA-M supports UK Annex M table 11.
 
I completely missed the Annex M part.

derfderfley is completely correct in saying that 877's do not support UK Mask Annex M, even the 877-M. Some ISPs will offer non-UK Mask Annex M.

You may need to drop back to an Annex A service to get stability, or use another box for internet and bridge it into the Cisco.
 
I've forced the ATM0 interface to ADSL2 (rather than ADSL2+). I've had another drop-out earlier today, although it was very short.

I've also cancelled the Annex M on the line, although I'm not sure if that's been done yet, dsl atm 0 shows this:

Code:
Alcatel 20190 chipset information
                ATU-R (DS)                      ATU-C (US)
Modem Status:    Showtime (DMTDSL_SHOWTIME)
DSL Mode:        ITU G.992.3 (ADSL2) Annex M
ITU STD NUM:     0x03                            0x2
Chip Vendor ID:  'STMI'                          'IFTN'
Chip Vendor Specific:  0x0000                    0x71B9
Chip Vendor Country:   0x0F                      0xB5
Modem Vendor ID: 'CSCO'                          '    '
Modem Vendor Specific: 0x0000                    0x0000
Modem Vendor Country:  0xB5                      0x00
Serial Number Near:    FCZ123464EX
Serial Number Far:
Modem VerChip ID:        C196 (3) capability-enabled
DFE BOM:         DFE3.0 Annex M (3)
Capacity Used:   97%                             100%
Noise Margin:     7.5 dB                          6.0 dB
Output Power:    19.0 dBm                        12.5 dBm
Attenuation:     42.5 dB                         19.0 dB
 
In both of the snippets of "sh dsl int atm0" you've posted your perilously close to 100% capacity on the downstream. I suspect this is the real cause of your problem, your attenuation figures are OK, but your downstream noise margin is probably a bit marginal for cisco kit, they seem to like 10db+ on most lines.

What sort of speeds it it training up at?

As a quick example my 857 stats. This line will train up at around 11-12Mbps downstream when synced at ADSL2+ but is only really stable at around 5-6Mbps downstream;

Code:
Modem Status:    Showtime (DMTDSL_SHOWTIME)
DSL Mode:        ITU G.992.1 (G.DMT) Annex A
ITU STD NUM:     0x01                            0x1
Vendor ID:       'STMI'                          'BDCM'
Vendor Specific: 0x0000                          0x544D
Vendor Country:  0x0F                            0xB5
Chip ID:         C196 (0)
DFE BOM:         DFE3.0 Annex A (1)
Capacity Used:   64%                             80%
Noise Margin:    12.5 dB                         13.0 dB
Output Power:    20.0 dBm                        12.5 dBm
Attenuation:     34.0 dB                         20.5 dB
Defect Status:   None                            None
Last Fail Code:  None
Watchdog Counter: 0x48
Watchdog Resets: 0
Selftest Result: 0x00
Subfunction:     0x00
Interrupts:      8254 (0 spurious)
PHY Access Err:  0
Activations:     1
LED Status:      ON
LED On Time:     100
LED Off Time:    100
Init FW:         init_AMR-3.0.014_no_bist.bin
Operation FW:    AMR-3.0.014.bin
FW Source:       embedded
FW Version:      3.0.14

                 Interleave             Fast    Interleave              Fast
Speed (kbps):          5760                0           832                 0
Cells:             26333312                0      14717636                 0
hmm, must update my adsl firmware again (I'd not bothered after the last one got zapped by lightning).
 
Back
Top Bottom