Cisco 887VA-K9 ADSL Up, but no routing

[Andrew Chance]

Hi,

I've a recurring intermittent issue with an 887VA router, in that it all works perfectly, ACL's in place, traffic routing all OK - then with no changes and no drop in the DSL - all external routing stops. Its as if the DSL itself drops, but I can shutdown and bring the DSL interface up. I can see the line establish the link, and come back all good. But still I get no external access.

If I reload the entire router however, it all comes good - no changes in config.

I can post config if required. <edit - config posted>

Thoughts ?

[Peter Paluch]

Hi,

Perhaps the configuration would be a good start. This is an intermittently and randomly appearing problem, and so far, there does not seem to be any pattern or indication toward a specific reason. So if possible, please be so kind to post your sanitized config.

Just wondering - when this issue occurs, is there anything unusual visible in the common outputs, such as logging messages, show ip route output (such as missing default route), show ip interface brief (such as no IP address assigned to the Dialer interface, the associated Virtual-Access interface missing or not in up/up state), show pppoe session (no PPPoE session active), show ppp all (no active PPP sessions)? Any clue of a similar kind can be extremely helpful.

Best regards,
Peter

[Leo Laohoo]

Hello Peter, 

Haven't seen you for a long time.  Where have you been hiding?

[Peter Paluch]

Hi Leo,

Oooh, I've been hiding behind my work at my uni ;) Seriously, though, this has been a busy term. It's coming to a close, though, that's why I am back here :)

I have missed this so much!!!

Best regards,
Peter

[Leo Laohoo]

this has been a busy term

I agree.  Been busy too!

[Andrew Chance]

Hi Peter,

Thanks for the response. I've added the config to my original post.

As for any IP info, I don't have that currently, but when it happens again I will update. To be honest, the primary thought was "what gets it running fastest", and my monitoring app was set to reload the router when  it still showed DSL sync, but no external access. Now disabled.

Thanks,

Andrew

[Andrew Chance]

Hi,

5 days later and it happened again. Looks like the PPP drops, and doesn't come back up again. Results from the router confirm that as below :

BLACSINTERNET#sho ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S*    0.0.0.0/0 is directly connected, Dialer1
      192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.2.0/24 is directly connected, Vlan1
L        192.168.2.1/32 is directly connected, Vlan1


BLACSINTERNET#sho ip int br
Interface                  IP-Address      OK? Method Status                Protocol
ATM0                       unassigned      YES NVRAM  down                  down
ATM0.1                     unassigned      YES unset  down                  down
Dialer1                    unassigned      YES IPCP   up                    up
Ethernet0                  unassigned      YES NVRAM  administratively down down
FastEthernet0              unassigned      YES unset  up                    up
FastEthernet1              unassigned      YES unset  up                    up
FastEthernet2              unassigned      YES unset  up                    down
FastEthernet3              unassigned      YES unset  up                    down
NVI0                       unassigned      YES unset  administratively down down
Virtual-Access1            unassigned      YES unset  up                    up
Virtual-Access2            unassigned      YES unset  down                  down
Vlan1                      192.168.2.1     YES NVRAM  up                    up


BLACSINTERNET#sho pppoe session
BLACSINTERNET#sho ppp all
Interface/ID OPEN+ Nego* Fail-     Stage    Peer Address    Peer Name
------------ --------------------- -------- --------------- --------------------
BLACSINTERNET#

Is there a preferred IOS to use for this router ?

Thanks,

Andrew

[Peter Paluch]

Andrew,

The ATM interface is down/down. That is the primary clue for me, as it suggests that the DSL line went down and didn't come back.

We have to check the DSL controller information. Can you post the output of the following commands?

show dsl interface atm0
show controller atm0

Best regards,
Peter

[Andrew Chance]

Hi Peter,

Previously the DSL hasn't dropped - and if I run a shut / no shut on the interface, I could see the DSL lose and regain sync, but still the PPP never came back up. I've since got the line back up and connected again - so the results below are a little skewed, but could be worthwhile as a baseline. :

Interface: ATM0, Hardware: MPC/AOE ATMSAR, State: up
IDB: 0x0178D220  Instance: 0x0179E15C  PHY Inst: 0x00000000  us_bwidth: 384
Slot:    0         Unit:     0         pkt Size: 4528
Sar ctrl queue: max depth = 0, current queue depth = 0,
                drops = 0, urun cnt = 0, total cnt = 0

VC TX ring stats:
VCD  VPI  VCI  Tx_ring_High_Watermark  Tx_ring_Low_Watermark   Queue_Depth
==========================================================================
1    8    35             128                124                0

VC QoS Summary
--------------
  Active            Scheduled
VCD VPI VCI  COS ST     COS       PCR(c)  PCR(a)  SCR/MCR(c)  SCR/MCR(a)
--------------------------------------------------------------------------
1    8   35    0        UBR       384     384     n/a         n/a

OAM statistics (vcd/count/drop)
-------------------------------
1/0/0  2/0/0  3/0/0  4/0/0
Misc Oam Drops: 0

ATM Encap Mapping
                                                Tx Congestion
Entry MAC address    VPI/VCI   VCD sts       set        clr     fastsend   safestart    drops
-----------------------------------------------------------------------------------------------
  0   c022.5000.0001  8/35      1   0          0          0     193726       1929          0

I can only run the show controller atm0, but if you wanted a show controllers vdsl 0 instead :

BLACSINTERNET#sho controllers vdsl 0
Controller VDSL 0 is UP

Daemon Status:           Up

                        XTU-R (DS)              XTU-C (US)
Chip Vendor ID:         'BDCM'                   'BDCM'
Chip Vendor Specific:   0x0000                   0xA3F5
Chip Vendor Country:    0xB500                   0xB500
Modem Vendor ID:        'CSCO'                   '    '
Modem Vendor Specific:  0x4602                   0x0000
Modem Vendor Country:   0xB500                   0x0000
Serial Number Near:    FGL1903207T C887VA-K 15.4(3)M5
Serial Number Far:
Modem Version Near:    15.4(3)M5
Modem Version Far:     0xa3f5

Modem Status:            TC Sync (Showtime!)

DSL Config Mode:         AUTO
Trained Mode:   G.992.1 (ADSL) Annex A
TC Mode:                 ATM
Selftest Result:         0x00
DELT configuration:      disabled
DELT state:              not running

Full inits:             2
Failed full inits:      9
Short inits:            0
Failed short inits:     0

Firmware        Source          File Name
--------        ------          ----------
VDSL            embedded        VDSL_LINUX_DEV_01212008

Modem FW  Version:      130205_1433-4.02L.03..d23j
Modem PHY Version:      A2pv6C035j.d23j
Trellis:                 ON                       ON
SRA:                     disabled                disabled
 SRA count:              0                       0
Bit swap:                enabled                 enabled
 Bit swap count:         158                     1
Line Attenuation:        52.0 dB                 31.5 dB
Signal Attenuation:      52.0 dB                  0.0 dB
Noise Margin:             6.1 dB                 24.0 dB
Attainable Rate:        5224 kbits/s             1200 kbits/s
Actual Power:            19.9 dBm                11.5 dBm
Total FECC:             8058736                  0
Total ES:               242                      0
Total SES:              199                      0
Total LOSS:             0                        0
Total UAS:              240                      240
Total LPRS:             0                        0
Total LOFS:             0                        0
Total LOLS:             0                        0


                  DS Channel1     DS Channel0   US Channel1       US Channel0
Speed (kbps):             0             4352             0               384
SRA Previous Speed:       0                0             0                 0
Previous Speed:           0             4352             0               384
Total Cells:              0         24766892             0                 0
User Cells:               0          5404852             0                 0
Reed-Solomon EC:          0          1363225             0                 5
CRC Errors:               0            13231             0                 0
Header Errors:            0                3             0                 1
Interleave (ms):       0.00            16.00          0.00              2.00
Actual INP:            0.00             2.96          0.00              0.94

Training Log :  Stopped
Training Log Filename : flash:vdsllog.bin

Again this is all current on a working connection. When it fails again, I can get the failed state also.

Really appreciate your help with this - whilst I can get the config in and working normally, this is very much outside of what I know.

Thanks,

Andrew

[Peter Paluch]

Hi Andrew,

Thanks for the output.

Well, it seems that either the DSL line is getting noisy, or that your router's DSL modem is deteriorating. The attenuation and noise margin values are not good at all - attenuation is at 52 dB, noise margin is at 6.1 dB. While there are differences in the recommended ranges for these values, the attenuation should be below 50 dB, ideally below 40 dB, and the noise margin should be above 8 dB, ideally above 10 dB (my home ADSL line operating at an attainable rate of around 14500 Kbps has a downstream attenuation of 30 dB and a noise margin of 10.3 dB).

I'd suggest you call your telco and ask them to come to your premises and do a thorough DSL line test using a line tester. If their tester shows significantly better values than the ones displayed by your router then it's possible that your router is slowly dying (I've seen a Cisco 800 series router's DSL interface gradually degrade to the point of dropping off the DSL link daily). In that case, it would be useful to test another router on the line to see if it performs better. If, however, telco confirms these values then they have to do something about your link, as otherwise, it is going to be unreliable.

Best regards,
Peter

[Andrew Chance]

Hi Peter,

The values are a downside of being ~7klms from the local exchange, and there have been multiple calls to the ISP (with flow on to the backhaul provider). Whilst they are slightly better, I am at the mercy of distance vs attenuation. I used to see disconnections (and loss of sync) 10-15 times per day, I am now down to 1 or 2 per week following the last telco visit.

The noise margin does fluctuate, anywhere from low 6's to mid - high 8's, alongside a sync rate of 4Mb -> 6.5Mb.

However, the issue is the loss of PPP, without the loss of DSL sync - and even if the DSL is forced to resync, the PPP is still not reconnected. Yet if the device has a full reboot, PPP is connected again. So whilst there are inherent DSL issues which my monitoring sees, I am still at a loss regarding the PPP reconnection.

Is there a way of forcing a PPP reconnect through the CLI ?

Thanks,

Andrew

[Peter Paluch · Accepted solution]

Andrew,

I see. As for restarting the PPP session, you could try entering clear ppp all or clear ppp all termreq and see if that causes the PPP to come up more readily. Also, it would be most useful if you had debug ppp negotiation configured at that time - that would allow us to see if PPP negotiation frames are being sent and received, and perhaps whether the problem can be traced down here.

Best regards,
Peter

[Peter Paluch]

Hi Andrew,

Is there anything new in this matter? I suppose that the link is currently holding.

Anyway, you wrote:

However, the issue is the loss of PPP, without the loss of DSL sync - and even if the DSL is forced to resync, the PPP is still not reconnected.

I am not sure about the DSL not losing sync - above, in the show ip interface brief output you have posted, the ATM interface was clearly down/down so that would constitute a loss of DSL sync as well, would it not?

In any case, the PPP should have come up after the DSL came up. The debug ppp negotiation will be very useful once this issue kicks in again - we really need to see if your router is attempting any reconnection in PPP and is getting any responses from the other side. The suggested commands clear ppp all and clear ppp all termreq are also relevant.

Best regards,
Peter

[Andrew Chance]

Hi Peter,

Apologies - a hard week at work this week...

I've not had a recurrence of the issue so far, partially down to repeated disconnections typical of my line during poorer weather.

To address the DSL not losing sync, when I ran the show ip interface brief it did show down/down, yet when I ran a show controllers vdsl 0 at the same time, that was up and showing line sync. Performing a shut / no shut on that caused the line rate to change following a resync, but still no active PPP as far as I could tell.

I can continue to monitor and try the clear ppp all (termreq) with the debug on as well. I had this on recently and lost sync, so I could see active PPP requests and it is all currently business as usual.

One of my other concerns is that due to the repeated disconnection / resync issues I'll burn through yet another device (so far its been a Belkin, Linksys, and two 877's) - all of which started to fail to gain sync on my line, and when tested on another - also failed there.

Kind regards,

Andrew

[Andrew Chance]

I've had continued issues again this week, with all the same symptoms (loss of PPP, yet shows in sync via SNMP and show controllers vdsl 0). Have just updated IOS to 15.5(3)M so will see how that goes.