cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2876
Views
0
Helpful
4
Replies

Cisco 877: ADSL drops when launching Emule (or generally opening many connections quickly)

MassimoPascucci
Level 1
Level 1

I have been using a cisco 877 router at home for more than a year and I've always been quite happy with it, but I've stumbled upon a very strange issue after an IOS update.

I was using IOS 15.0(1)M until last week, when I decided to configure the router as a VPN server (both for PPTP and L2TP/IPSEC) in order to be able to connect to my home network from outside; then I realized that IOS has a nasty bug on PPTP VPNs (it just ignores the ppp encrypt mppe auto instruction), so I updated it to the latest 15.1 release I could find, 15.1(3)T1. Everything worked.

Until I launched Emule with some heavy download, and the connection dropped. And didn't come up again, even after a clear interface ATM 0: only rebooting the router solved the problem. Which, upon launching Emule again, again happened.

The problem seems to be related to opening lots of connections at the same time; "simple" heavy load (like downloading a big file at full speed) doesn't do any harm to the line, and configuring Emule to use a smaller number of connections and opening it more slowly seems to mitigate the problem, which anyway keeps happening after a while.

The strangest thing is, this is definitely related to the IOS version. It didn't happen before the upgrade, and I confirmed it stops happening if I reload the previous IOS on the router. Out of curiosity, I also tested some other IOS releases: 15.1(1)T, 15.0(1)M5 and even 12.4(24)T5. It always happens, only 15.0(1)M seems to prevent it... but it also seems to hate VPN encryption. And let's not even start talking about 15.1(4)M: I tried it and I wasn't ever able to succesfully authenticate a VPN connection.

Of course, when tried different IOS releases, the router's configuration always stayed the same. Here is it (stripped of personal details):

no service pad
service timestamps debug datetime localtime
service timestamps log datetime localtime
service password-encryption
!
hostname Cisco877
!
boot-start-marker
boot system flash c870-advipservicesk9-mz.151-3.T1.bin
boot-end-marker
!
logging buffered 1048576
!
aaa new-model
aaa authentication login default local-case
aaa authentication ppp default local
aaa authorization console
aaa authorization exec default local
aaa session-id common
!
clock timezone WEST 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 2:00
clock save interval 8
!
dot11 syslog
!
ip source-route
ip cef
ip domain name <ISP DOMAIN NAME>
ip name-server <ISP DNS SERVER>
ip name-server <ISP DNS SERVER>
ip name-server <ISP DNS SERVER>
login on-failure log
login on-success log
no ipv6 cef
!
multilink bundle-name authenticated
!
vpdn enable
!
vpdn-group VPN_CLIENTS
! Default L2TP VPDN group
! Default PPTP VPDN group
accept-dialin
  protocol any
  virtual-template 1
no l2tp tunnel authentication
l2tp tunnel timeout no-session 15
!
password encryption aes
!
username <USERNAME> privilege 15 password 7 <PASSWORD>
!
ip ssh version 2
!
crypto pki token default removal timeout 0
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key 6 <KEY> address 0.0.0.0 0.0.0.0
crypto ipsec transform-set VPN_TS esp-3des esp-sha-hmac
mode transport
crypto dynamic-map VPN_DYN_MAP 1
set nat demux
set transform-set VPN_TS
crypto map VPN_MAP 1 ipsec-isakmp dynamic VPN_DYN_MAP
!
interface ATM0
no ip address
no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
pvc 8/75
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
!
!
interface FastEthernet0
spanning-tree portfast
!
interface FastEthernet1
spanning-tree portfast
!
interface FastEthernet2
spanning-tree portfast
!
interface FastEthernet3
spanning-tree portfast
!
interface Virtual-Template1
ip unnumbered Vlan1
ip nat inside
ip virtual-reassembly in
peer default ip address pool VPN_POOL
ppp encrypt mppe auto
ppp authentication ms-chap-v2 ms-chap chap
!
interface Vlan1
ip address 192.168.42.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface Dialer0
ip address negotiated
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username <ISP USERNAME> password 7 <ISP PASSWORD>
crypto map VPN_MAP
!
ip local pool VPN_POOL 192.168.42.240 192.168.42.249
ip forward-protocol nd
ip http server
ip http access-class 2
ip http authentication aaa
no ip http secure-server
!
ip dns server
!
ip nat inside source list 1 interface Dialer0 overload
! These two static NATs are for Emule
ip nat inside source static tcp 192.168.42.42 24242 213.203.153.23 24242 extendable
ip nat inside source static udp 192.168.42.42 24242 213.203.153.23 24242 extendable
ip route 0.0.0.0 0.0.0.0 Dialer0
!
logging esm config
logging trap debugging
access-list 1 permit 192.168.42.0 0.0.0.255
access-list 2 permit 192.168.42.0 0.0.0.255
dialer-list 1 protocol ip permit
!
control-plane
!
line con 0
exec-timeout 0 0
no modem enable
line aux 0
line vty 0 4
access-class 2 in
exec-timeout 0 0
transport input ssh
!
scheduler max-task-time 5000
ntp logging
ntp server <PUBLIC NTP SERVER>

How can I fix this without reloading the buggy IOS I was using before?

If you need any debug information, feel free to ask and I'll provide it.

This is the current show version:

Cisco IOS Software, C870 Software (C870-ADVIPSERVICESK9-M), Version 15.1(3)T1, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2011 by Cisco Systems, Inc.
Compiled Sun 27-Mar-11 12:37 by prod_rel_team

ROM: System Bootstrap, Version 12.3(8r)YI6, RELEASE SOFTWARE

Cisco877 uptime is 34 minutes
System returned to ROM by reload at 19:55:24 CEST Wed Jul 6 2011
System restarted at 19:56:23 CEST Wed Jul 6 2011
System image file is "flash:c870-advipservicesk9-mz.151-3.T1.bin"
Last reload reason: Reload Command

<snip>

Cisco 877 (MPC8272) processor (revision 2.0) with 236544K/25600K bytes of memory.
Processor board ID FCZ1124217M
MPC8272 CPU Rev: Part Number 0xC, Mask Number 0x10
4 FastEthernet interfaces
1 ATM interface
1 Virtual Private Network (VPN) Module
128K bytes of non-volatile configuration memory.
53248K bytes of processor board System flash (Intel Strataflash)

And this is the current output of show dsl interface ATM 0:

ATM0
Alcatel 20190 chipset information
                ATU-R (DS)                      ATU-C (US)
Modem Status:    Showtime (DMTDSL_SHOWTIME)
DSL Mode:        ITU G.992.1 (G.DMT) Annex A
ITU STD NUM:     0x01                            0x1
Vendor ID:       'STMI'                          'GSPN'
Vendor Specific: 0x0000                          0x0008
Vendor Country:  0x0F                            0xFF
Chip ID:         C196 (0)
DFE BOM:         DFE3.0 Annex A (1)
Capacity Used:   77%                             80%
Noise Margin:    14.5 dB                         14.0 dB
Output Power:    18.5 dBm                        12.0 dBm
Attenuation:     30.5 dB                         16.5 dB
FEC ES Errors:    0                               0
ES Errors:        1                               1
SES Errors:       0                               0
LOSES Errors:     0                               0
UES Errors:       0                               0
Defect Status:   None                            None
Last Fail Code:  None
Watchdog Counter: 0x78
Watchdog Resets: 0
Selftest Result: 0x00
Subfunction:     0x00
Interrupts:      4123 (0 spurious)
PHY Access Err:  0
Activations:     1
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

                 Interleave             Fast    Interleave              Fast
Speed (kbps):          8608                0           640                 0
DS User cells:        24118                0
US User & Idle cells:                               3245456                0
Reed-Solomon EC:         20                0             0                 0
CRC Errors:               1                0             3                 0
Header Errors:            1                0             0                 0
Total BER:                5969E-13               0E-0
Leakage Average BER:      5969E-13               0E-0
                        ATU-R (DS)      ATU-C (US)
Bitswap:               enabled            enabled

LOM Monitoring : Disabled

DMT Bits Per Bin
000: 0 0 0 0 0 0 2 3 6 7 8 9 9 9 9 A
010: A A A A A A A 9 9 8 8 8 8 0 0 0
020: 0 7 9 9 9 B B C C C C C D D D D
030: D D D D D D C D D D D D D D D D
040: 0 D D D C D C C C C C C C C C C
050: C C C C C C C C C C C C C C C 2
060: C C C C C B C C C C C C B C C C
070: C B B B B B B B B B B B B B B B
080: B B B B B B B B B B B B B B B B
090: B B B B B B B B B B B B B B B B
0A0: B B B B B B B B B A A A A A A A
0B0: A A A A A A A A A A A A A A A A
0C0: A A A A A A A A A A A A A A A A
0D0: A A A A A 9 9 9 9 9 9 9 9 9 9 9
0E0: 9 9 9 9 9 9 9 8 9 9 9 9 9 9 9 9
0F0: 8 8 9 9 8 8 8 9 9 9 8 8 8 8 7 6

DSL: Training log buffer capability is not enabled

Also, any suggestion at fine-tuning the router would be greatly appreciated; I can currently reach 7M/512K top speed, on a very stable line.

Thanks for any help

1 Accepted Solution

Accepted Solutions

inaxeon123
Level 1
Level 1

Did you ever get to the bottom of this?

EDIT: occurrences of 15.0(1)M in this post actually refer to 15.0(1)M4

I seem to be having symptoms very similar to this, indeed 15.0(1)M is that one magic release that just seems to work. Nothing else on the 15.x brach can stay connected under load.

My scenario has these things in common:

* Good quality line

* 'clear interface atm0' does not restore the connection

* VC drops under load, a few minutes after link up

* Always requires reboot, cannot recover at runtime

* Only 15.0(1)M works

* Cisco 877

* DSL line does not drop in this process, only ATM0.1 goes down, and stays down.

But what's interesting is how different my scenario is too. Your ISP has a GlobespanVirata based DSLAM, Mine is Broadcom with G.992.5M. My config is also significantly more complex, and is based on Ethernet over ATM, with no dialer interface.

I've tried (with no effect):

* Several versions of ADSL firmware

* Every version of 15.x after 15.0(1)M

* Extensive fiddling with ATM configuration

I've also spend a lot of time examining ATM debug output but everything outputted just equates to "connection dead" no hints as to why it went down.

I found this post after looking at my ATM debug output:

https://supportforums.cisco.com/thread/2093373

I believe this person may also having a similar issue.

Unfortunately the release notes as to what exactly changed after 15.0(1)M are vague, certainly, I haven't been able to find the smoking gun. I find it highly unlikely that IOS 15.x is bust for every person on my ISP in the UK. There must be a logical explanation for this! It also appears very likely that this breakage has been backported to some newer 12.4 releases too!

View solution in original post

4 Replies 4

inaxeon123
Level 1
Level 1

Did you ever get to the bottom of this?

EDIT: occurrences of 15.0(1)M in this post actually refer to 15.0(1)M4

I seem to be having symptoms very similar to this, indeed 15.0(1)M is that one magic release that just seems to work. Nothing else on the 15.x brach can stay connected under load.

My scenario has these things in common:

* Good quality line

* 'clear interface atm0' does not restore the connection

* VC drops under load, a few minutes after link up

* Always requires reboot, cannot recover at runtime

* Only 15.0(1)M works

* Cisco 877

* DSL line does not drop in this process, only ATM0.1 goes down, and stays down.

But what's interesting is how different my scenario is too. Your ISP has a GlobespanVirata based DSLAM, Mine is Broadcom with G.992.5M. My config is also significantly more complex, and is based on Ethernet over ATM, with no dialer interface.

I've tried (with no effect):

* Several versions of ADSL firmware

* Every version of 15.x after 15.0(1)M

* Extensive fiddling with ATM configuration

I've also spend a lot of time examining ATM debug output but everything outputted just equates to "connection dead" no hints as to why it went down.

I found this post after looking at my ATM debug output:

https://supportforums.cisco.com/thread/2093373

I believe this person may also having a similar issue.

Unfortunately the release notes as to what exactly changed after 15.0(1)M are vague, certainly, I haven't been able to find the smoking gun. I find it highly unlikely that IOS 15.x is bust for every person on my ISP in the UK. There must be a logical explanation for this! It also appears very likely that this breakage has been backported to some newer 12.4 releases too!

Just to clarify the previous post, the release which works good is 15.0(1)M4 although I've now tested everything back to 15.0(1)M and they all work. So it's when we go from 15.0(1)M4 to 15.0(1)M5 that this problem turns up. Versions 15.0(1)M5 all the way through to 15.1(4)M1 are bust. I haven't experimented with any 'T' releases.

I notice that in 15.0(1)M5, the version number of IOS and router model number is now included under the "Serial Number Near" heading of the "show dsl interface atm0" command, so there's definitely been some meddling with the DSL code between these versions. No specific mention in the release notes though.

I never got to the bottom of this, but I can confirm version 15.0(1)M4 is the last one in the 15.0 branch where this problem doesn't happen; this is the version I'm using now, I've been using it for some months and the connection is completely stable under any load. Although some more releases did come up in the meantime, I didn't try any one of them. Maybe I'll do some more tests in the future, but for now I'm keeping the only firmware I know for sure works.

MassimoPascucci
Level 1
Level 1

The problem is finally resolved in 15.1(4)M3. Looks like it might be related to this bug:

CSCtq88777

Symptoms: VDSL controller and ATM interface remains up, however ATM PVC becomes inactive and virtual interface goes down.

Conditions: The symptom is observed when the ATM PVC becomes inactive causing the virtual interface to go down.

Workaround: Use a VBR-NRT value that is lower than trained upstream speed.

If this is the case , it should then be also fixed in 15.1(3)T3.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: