«

Hello,

my attempt to migrate a BT A-DSL line (using the Max service) from a
Linksys ADSL2MUE to a Cisco 877W today were not every succesful. The
configuration of the Cisco worked in general:
- The A-DSL link was established at the expected speed.
- The PPP session was established and the Cisco got the correct
IPv4 address assigned.
- IPv4 and IPv6 routing worked fine.

There were however problems:
1.) A lot of noise on the phone line.
2.) The Cisco kept reconnectiong every few minutes after a not very
help error message like this:

%LINK-3-UPDOWN: Interface ATM0, changed state to down

The configuration for the A-DSL interface looks like this:

interface ATM0
no ip address
ip access-group 101 in
no atm ilmi-keepalive
pvc 0/38
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
dsl operating-mode auto
!

interface Dialer0
ip address negotiated
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ipv6 address autoconfig
ipv6 enable
no cdp enable
ppp authentication chap callin
ppp chap hostname ***
ppp chap password 0 ***
!

Is there a way to force the Cisco to ADSL1 and not try ADSL2 or ADSL2+?
I wonder whether my microfilter can't deal with that very well.

Kind regards

--
Matthias Scheler http://zhadum.org.uk/

Matthias Scheler wrote:
> Hello,
>
> my attempt to migrate a BT A-DSL line (using the Max service) from a
> Linksys ADSL2MUE to a Cisco 877W today were not every succesful. The
> configuration of the Cisco worked in general:
> - The A-DSL link was established at the expected speed.
> - The PPP session was established and the Cisco got the correct
> IPv4 address assigned.
> - IPv4 and IPv6 routing worked fine.
>
> There were however problems:
> 1.) A lot of noise on the phone line.
> 2.) The Cisco kept reconnectiong every few minutes after a not very
> help error message like this:
>
> %LINK-3-UPDOWN: Interface ATM0, changed state to down
>
> The configuration for the A-DSL interface looks like this:
>
> interface ATM0
> no ip address
> ip access-group 101 in
> no atm ilmi-keepalive
> pvc 0/38
> encapsulation aal5mux ppp dialer
> dialer pool-member 1
> !
> dsl operating-mode auto
> !
>
> interface Dialer0
> ip address negotiated
> ip virtual-reassembly
> encapsulation ppp
> dialer pool 1
> dialer-group 1
> ipv6 address autoconfig
> ipv6 enable
> no cdp enable
> ppp authentication chap callin
> ppp chap hostname ***
> ppp chap password 0 ***
> !
>
> Is there a way to force the Cisco to ADSL1 and not try ADSL2 or ADSL2+?
> I wonder whether my microfilter can't deal with that very well.
>
> Kind regards
>

Hello,

dependant on your ios and/or router :

dsl operating-mode ?

adsl2 adsl2 mode
adsl2+ adsl2+ mode
ansi-dmt ANSI full rate mode <<<<<<<<<<<<< try this for ADSL "1"
auto auto detect mode
itu-dmt ITU full rate mode <<<<<<<<<<<<< or that

Regards,

--
Luc

In addition to Luc's comments I have seen this happen on 877 with IOS
12(1) - I think the Cisco website says you need 12(3) onwards to support
ADSL2 etc...is your IOS the latest?

J

"Luc" <> wrote in message
news:eiilu3$2dsr$...
> Matthias Scheler wrote:
>> Hello,
>>
>> my attempt to migrate a BT A-DSL line (using the Max service) from a
>> Linksys ADSL2MUE to a Cisco 877W today were not every succesful. The
>> configuration of the Cisco worked in general:
>> - The A-DSL link was established at the expected speed.
>> - The PPP session was established and the Cisco got the correct
>> IPv4 address assigned.
>> - IPv4 and IPv6 routing worked fine.
>>
>> There were however problems:
>> 1.) A lot of noise on the phone line.
>> 2.) The Cisco kept reconnectiong every few minutes after a not very
>> help error message like this:
>>
>> %LINK-3-UPDOWN: Interface ATM0, changed state to down
>>
>> The configuration for the A-DSL interface looks like this:
>>
>> interface ATM0
>> no ip address
>> ip access-group 101 in
>> no atm ilmi-keepalive
>> pvc 0/38 encapsulation aal5mux ppp dialer
>> dialer pool-member 1
>> !
>> dsl operating-mode auto !
>>
>> interface Dialer0
>> ip address negotiated
>> ip virtual-reassembly
>> encapsulation ppp
>> dialer pool 1
>> dialer-group 1
>> ipv6 address autoconfig
>> ipv6 enable
>> no cdp enable
>> ppp authentication chap callin
>> ppp chap hostname ***
>> ppp chap password 0 ***
>> !
>>
>> Is there a way to force the Cisco to ADSL1 and not try ADSL2 or ADSL2+?
>> I wonder whether my microfilter can't deal with that very well.
>>
>> Kind regards
>>
>
> Hello,
>
> dependant on your ios and/or router :
>
> dsl operating-mode ?
>
> adsl2 adsl2 mode
> adsl2+ adsl2+ mode
> ansi-dmt ANSI full rate mode <<<<<<<<<<<<< try this for ADSL "1"
> auto auto detect mode
> itu-dmt ITU full rate mode <<<<<<<<<<<<< or that
>
> Regards,
>
> --
> Luc

In article <de287$454cf8f8$53d9a63f$>,
"jamie" <> writes:
> In addition to Luc's comments I have seen this happen on 877 with IOS
> 12(1) - I think the Cisco website says you need 12(3) onwards to support
> ADSL2 etc...

I don't need ADSL2+ yet. My line is only ADSL1. I'm just wondering whether
the ADSL2+ support in the hard- and software cause my stability problems.

> is your IOS the latest?

It's pretty new:

Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 12.4(9)T1, RELEASE SOFTWARE (fc2)

Kind regards

--
Matthias Scheler http://zhadum.org.uk/

Matthias Scheler wrote:

> I'm just wondering whether
> the ADSL2+ support in the hard- and software cause my stability problems.


yes, I have seen this symptom on low-quality PSTN line. Please send to
us the result of 'sh dsl interface atm0' ........

Best regards,

--
Luc

In article <eij2f9$2jqk$>,
Luc <> writes:
> yes, I have seen this symptom on low-quality PSTN line.

Considering the fact that it's 15m to the exchange and that my previous
router (Netgear DG834G), my current modem (Linksys ADSL2MUE) and the
Cisco 877W all connect at the maximum speed that BT's Max DSL can provide
I don't think my line qualifies as a low-quality PSTN line.

> Please send to us the result of 'sh dsl interface atm0' ........

Because I'm not using the Cisco at the moment I'm not sure whether the
output is accurate:

jumpgate#show dsl int atm0
ATM0
Alcatel 20190 chipset information
Line not activated: displaying cached data from last activation
ATU-R (DS) ATU-C (US)
Modem Status: Showtime (DMTDSL_STOP)
DSL Mode: ITU G.992.1 (G.DMT) Annex A
ITU STD NUM: 0x03 0x1
Vendor ID: 'STMI' 'ALCB'
Vendor Specific: 0x0000 0x0000
Vendor Country: 0x0F 0x0F
Capacity Used: 82% 99%
Noise Margin: 1.0 dB 5.0 dB
Output Power: 16.5 dBm 12.0 dBm
Attenuation: 10.0 dB 4.0 dB
Defect Status: LCDf LOS LOF LCDf
Last Fail Code: None
Watchdog Counter: 0x7D
Watchdog Resets: 0

Selftest Result: 0x00
Subfunction: 0x00
Interrupts: 15357 (0 spurious)
PHY Access Err: 0
Activations: 8
LED Status: OFF
LED On Time: 100
LED Off Time: 100
Init FW: embedded
Operation FW: embedded
FW Version: 2.5.42

Interleave Fast Interleave Fast
Speed (kbps): 0 8128 0 832
Cells: 0 118 0 64884
Reed-Solomon EC: 0 0 174 187
CRC Errors: 0 1797 286 1096
Header Errors: 0 1428 291 743
Total BER: 0E-0 0E-0
Leakage Avarage BER: 0E-0 2E-0

Kind regards

--
Matthias Scheler http://zhadum.org.uk/

"Matthias Scheler" <> wrote in message
news:454d258d$0$632$...
> In article <eij2f9$2jqk$>,
> Luc <> writes:
>> yes, I have seen this symptom on low-quality PSTN line.
>
> Considering the fact that it's 15m to the exchange and that my previous
> router (Netgear DG834G), my current modem (Linksys ADSL2MUE) and the
> Cisco 877W all connect at the maximum speed that BT's Max DSL can provide
> I don't think my line qualifies as a low-quality PSTN line.
>
>> Please send to us the result of 'sh dsl interface atm0' ........
>
> Because I'm not using the Cisco at the moment I'm not sure whether the
> output is accurate:
>
> jumpgate#show dsl int atm0
> ATM0
> Alcatel 20190 chipset information
> Line not activated: displaying cached data from last activation
> ATU-R (DS) ATU-C (US)
> Modem Status: Showtime (DMTDSL_STOP)
> DSL Mode: ITU G.992.1 (G.DMT) Annex A
> ITU STD NUM: 0x03 0x1
> Vendor ID: 'STMI' 'ALCB'
> Vendor Specific: 0x0000 0x0000
> Vendor Country: 0x0F 0x0F
> Capacity Used: 82% 99%
> Noise Margin: 1.0 dB 5.0 dB
> Output Power: 16.5 dBm 12.0 dBm
> Attenuation: 10.0 dB 4.0 dB
> Defect Status: LCDf LOS LOF LCDf
> Last Fail Code: None
> Watchdog Counter: 0x7D
> Watchdog Resets: 0
>
> Selftest Result: 0x00
> Subfunction: 0x00
> Interrupts: 15357 (0 spurious)
> PHY Access Err: 0
> Activations: 8
> LED Status: OFF
> LED On Time: 100
> LED Off Time: 100
> Init FW: embedded
> Operation FW: embedded
> FW Version: 2.5.42
>
> Interleave Fast Interleave
> Fast
> Speed (kbps): 0 8128 0
> 832
> Cells: 0 118 0
> 64884
> Reed-Solomon EC: 0 0 174
> 187
> CRC Errors: 0 1797 286
> 1096
> Header Errors: 0 1428 291
> 743
> Total BER: 0E-0 0E-0
> Leakage Avarage BER: 0E-0 2E-0
>
> Kind regards
>
> --
> Matthias Scheler http://zhadum.org.uk/

The downstream noise margin @ 1.0 dB is very low and likely causing the
disconnects. Ideally it should be around 6.0 dB at a minimum.

The DSLAM hardware at the exchange should learn to stabilise your line over
a period of 10 days (if I remember correctly) by automatically reducing the
downstream syncronisation rate (you're currently running at the maximum line
speed of 8128 kbps), which in turn will increase your downstream noise
margin (SNR ~ Signal-to-Noise Ratio).

If for some reason the DSLAM fails to negotiate a stable speed over time I
believe you can contact your ISP and request a higher noise margin be
manually specified (say, 10 dB) to force stability at the expense of maximum
line rates.

In article <454da33b$0$2432$>,
"user" <user@localhost> writes:
> The downstream noise margin @ 1.0 dB is very low and likely causing the
> disconnects. Ideally it should be around 6.0 dB at a minimum.

I see. 6.0 dB is what the old Netgear DG834G reported.

> The DSLAM hardware at the exchange should learn to stabilise your line over
> a period of 10 days (if I remember correctly) by automatically reducing the
> downstream syncronisation rate (you're currently running at the maximum line
> speed of 8128 kbps), which in turn will increase your downstream noise
> margin (SNR ~ Signal-to-Noise Ratio).

I do *not* think it is is related to the line:
- I have BT-Max since April this year. I never had any problems to operate
the line at 8Mb/Sec with the Netgear DG834G or the Linksys ADSL2MUE.
I only bought the Cisco because I wanted a router with IPv6 support
to get rid of the seperate Unix box acting as firewall.
- After the Cisco 877W failed to provide stable A-DSL service yesterday
I switch back to the Linksys ADSL2MUE. It connected at 8Mb/Sec
immediately and hasn't lost the connection since. I've even run "ping"
at a 5 second interval against my ISP's "ping server" overnight. It
didn't lose a single packet.

So whatever causes the problem is related to the Cisco. My best guess
that it is somehow not working well with both microfilters I tried.

I must say that I'm somewhat disappointed that a "high-end DSL router"
obviously struggles to provide the same quality of service as a ten
times cheaper DSL modem.

Kind regards

--
Matthias Scheler http://zhadum.org.uk/

Matthias Scheler wrote:
> In article <454da33b$0$2432$>,
> "user" <user@localhost> writes:
> > The downstream noise margin @ 1.0 dB is very low and likely causing the
> > disconnects. Ideally it should be around 6.0 dB at a minimum.
>
> I see. 6.0 dB is what the old Netgear DG834G reported.
>
> > The DSLAM hardware at the exchange should learn to stabilise your line over
> > a period of 10 days (if I remember correctly) by automatically reducing the
> > downstream syncronisation rate (you're currently running at the maximum line
> > speed of 8128 kbps), which in turn will increase your downstream noise
> > margin (SNR ~ Signal-to-Noise Ratio).
>
> I do *not* think it is is related to the line:
> - I have BT-Max since April this year. I never had any problems to operate
> the line at 8Mb/Sec with the Netgear DG834G or the Linksys ADSL2MUE.
> I only bought the Cisco because I wanted a router with IPv6 support
> to get rid of the seperate Unix box acting as firewall.
> - After the Cisco 877W failed to provide stable A-DSL service yesterday
> I switch back to the Linksys ADSL2MUE. It connected at 8Mb/Sec
> immediately and hasn't lost the connection since. I've even run "ping"
> at a 5 second interval against my ISP's "ping server" overnight. It
> didn't lose a single packet.
>
> So whatever causes the problem is related to the Cisco. My best guess
> that it is somehow not working well with both microfilters I tried.
>
> I must say that I'm somewhat disappointed that a "high-end DSL router"
> obviously struggles to provide the same quality of service as a ten
> times cheaper DSL modem.

If you have support raise a TAC case.

I have seen several issues with 877 and ADSL. Cisco are in fact
publishing
ADSL firmware updates independently of IOS.

FW Version: 2.5.42
The latest is something like 3.0.10 and 2.6.4 is available.
This has been discussed in an earlier thread.

I think that 12.4(9)T2 may be available too.

There is clear evidence of line issues, noise margin as mentioned
already and actual line errors.

Interleave Fast Interleave
Fast
Speed (kbps): 0 8128 0
832
Cells: 0 118 0
64884
Reed-Solomon EC: 0 0 174
187
CRC Errors: 0 1797 286
1096
Header Errors: 0 1428 291
743
Total BER: 0E-0 0E-0
Leakage Avarage BER: 0E-0 2E-0


Reed-Solomon EC are a count of successful Error Correction
events. I guess CRC and Header errors indicate cases
that Error Correction has failed.

I have had success by manually configuring the dsl operating mode.

Your unit seems to be using:-
DSL Mode: ITU G.992.1 (G.DMT) Annex A

So set it to:-
dsl operating mode itu.dmt


I would try them all until I found one that worked.

I suspect that BT usually support several different ones.


Many parameters (incliding speed) are set at the Provider end only as
I understand it.

Interestingly the Downstream direction is reporting errors in both
Interleave
and Fast mode suggesting negotiation difficulties.

I agree that it is odd that Cisco seem to be having trouble
providing ADSL kit that works as well as consumer level kit seems to.

Comments similar to yours are something that I have come
across quite a bit recently (only with 857/877 I think) not with 837
but they are almost obsolete now (certainly for 8M I would guess).

Finally you can turn on the DSL training log. It produces a lot of
output none of which makes much sense to me but you never know
there might be a clue in there. I have read that enabling logging
increases the time to train up.

I deal with say 20 sites.

877 is otherwise rather nice and I have not yet failed
to get one going (IIRC).

You can get the latest ADSL firmware for 800 series direct from
Cisco's FTP site:
(you do not currently need CCO access)

ftp://ftp.cisco.com
PUblic, Access, 800 , DSL firmware.

There are instructions there, but bacically rename the file to
ADSL_ALC_20190.bin and copy it to the routers Flash & reboot.

cheers,

Peter.


wrote:
> Matthias Scheler wrote:
> > In article <454da33b$0$2432$>,
> > "user" <user@localhost> writes:
> > > The downstream noise margin @ 1.0 dB is very low and likely causing the
> > > disconnects. Ideally it should be around 6.0 dB at a minimum.
> >
> > I see. 6.0 dB is what the old Netgear DG834G reported.
> >
> > > The DSLAM hardware at the exchange should learn to stabilise your line over
> > > a period of 10 days (if I remember correctly) by automatically reducing the
> > > downstream syncronisation rate (you're currently running at the maximum line
> > > speed of 8128 kbps), which in turn will increase your downstream noise
> > > margin (SNR ~ Signal-to-Noise Ratio).
> >
> > I do *not* think it is is related to the line:
> > - I have BT-Max since April this year. I never had any problems to operate
> > the line at 8Mb/Sec with the Netgear DG834G or the Linksys ADSL2MUE.
> > I only bought the Cisco because I wanted a router with IPv6 support
> > to get rid of the seperate Unix box acting as firewall.
> > - After the Cisco 877W failed to provide stable A-DSL service yesterday
> > I switch back to the Linksys ADSL2MUE. It connected at 8Mb/Sec
> > immediately and hasn't lost the connection since. I've even run "ping"
> > at a 5 second interval against my ISP's "ping server" overnight. It
> > didn't lose a single packet.
> >
> > So whatever causes the problem is related to the Cisco. My best guess
> > that it is somehow not working well with both microfilters I tried.
> >
> > I must say that I'm somewhat disappointed that a "high-end DSL router"
> > obviously struggles to provide the same quality of service as a ten
> > times cheaper DSL modem.
>
> If you have support raise a TAC case.
>
> I have seen several issues with 877 and ADSL. Cisco are in fact
> publishing
> ADSL firmware updates independently of IOS.
>
> FW Version: 2.5.42
> The latest is something like 3.0.10 and 2.6.4 is available.
> This has been discussed in an earlier thread.
>
> I think that 12.4(9)T2 may be available too.
>
> There is clear evidence of line issues, noise margin as mentioned
> already and actual line errors.
>
> Interleave Fast Interleave
> Fast
> Speed (kbps): 0 8128 0
> 832
> Cells: 0 118 0
> 64884
> Reed-Solomon EC: 0 0 174
> 187
> CRC Errors: 0 1797 286
> 1096
> Header Errors: 0 1428 291
> 743
> Total BER: 0E-0 0E-0
> Leakage Avarage BER: 0E-0 2E-0
>
>
> Reed-Solomon EC are a count of successful Error Correction
> events. I guess CRC and Header errors indicate cases
> that Error Correction has failed.
>
> I have had success by manually configuring the dsl operating mode.
>
> Your unit seems to be using:-
> DSL Mode: ITU G.992.1 (G.DMT) Annex A
>
> So set it to:-
> dsl operating mode itu.dmt
>
>
> I would try them all until I found one that worked.
>
> I suspect that BT usually support several different ones.
>
>
> Many parameters (incliding speed) are set at the Provider end only as
> I understand it.
>
> Interestingly the Downstream direction is reporting errors in both
> Interleave
> and Fast mode suggesting negotiation difficulties.
>
> I agree that it is odd that Cisco seem to be having trouble
> providing ADSL kit that works as well as consumer level kit seems to.
>
> Comments similar to yours are something that I have come
> across quite a bit recently (only with 857/877 I think) not with 837
> but they are almost obsolete now (certainly for 8M I would guess).
>
> Finally you can turn on the DSL training log. It produces a lot of
> output none of which makes much sense to me but you never know
> there might be a clue in there. I have read that enabling logging
> increases the time to train up.
>
> I deal with say 20 sites.
>
> 877 is otherwise rather nice and I have not yet failed
> to get one going (IIRC).