cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5263
Views
27
Helpful
15
Replies
Highlighted
Explorer

Strange issue - unable to establish PPP with Cisco 887 VAG router on one particular ADSL line

I have a strange problem that I’m struggling to get to the bottom of with my ISP and wondered if anyone could help.

 

We have a site with an older Cisco 877 ADSL router which was working happily until a few weeks ago when the connection dropped suddenly (out-of-hours at 2am if that’s of any significance – made me think most likely something carrier/ISP related?)    When connectivity was lost, the router could sync with the BT exchange (we are in the UK) but could not establish PPP.

 

We logged fault with our ISP – after some to’ing and fro’ing, they passed it onto BT and their engineers visited site, they fixed “a line fault” (we don’t get much detail on what was actually fixed) but we still could not establish connectivity – same thing, solid CD light but no PPP.

 

So, we replaced the router with another 877 – same again, solid CD but no PPP.  We replaced all the cables and microfilter etc but no difference. 

 

We tried a different Cisco router (a newer Cisco 887VAG) which, as I understand, uses a different modem chipset but no matter – PPP could still not be established.  We tested this router on another ADSL line with the same ISP and it worked without issue, using the same ADSL account details, it was able to establish connectivity.  So we figured this must still be a BT/ISP issue.

 

Since then we’ve had BT out again twice but they say there is no fault.  The ISP say there is no issue with them.  But we still cannot establish ADSL connectivity on this line, despite having tried 3 different ADSL routers and despite the fact the routers work with the same account details on another ADSL line.

 

The 887VAG router we have currently connected has 3G backup so that is keeping us going in the meantime and also means I can login to the router remotely to check on the ADSL status. 

 

But I’m struggling to pinpoint where the problem may lie.   Strangely, if I turn on PPP negotiation and authentication debug then I’m not actually seeing any output from it at all?

 

Yet, the ATM interface is up and shows packets being sent and received:

 

ATM0 is up, line protocol is up

  Hardware is MPC ATMSAR, address is bc16.6596.9b00 (bia bc16.6596.9b00)

  MTU 1600 bytes, sub MTU 1600, BW 704 Kbit/sec, DLY 520 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ATM, loopback not set

  Keepalive not supported

  Encapsulation(s): AAL5

  4 maximum active VCs, 1024 VCs per VP, 1 current VCCs

  VC Auto Creation Disabled.

  VC idle disconnect time: 300 seconds

  Last input 00:00:28, output 00:00:07, output hang never

  Last clearing of "show interface" counters 6d23h

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: Per VC Queueing

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     23886 packets input, 1676964 bytes, 0 no buffer

     Received 0 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     56469 packets output, 4418592 bytes, 0 underruns

     0 output errors, 0 collisions, 6 interface resets

     0 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out


Does anyone have any ideas on where the problem may be and what more I can do to troubleshoot and provide the relevant evidence to our ISP (assuming it is an ISP/BT issue though the fact the same router works ok with the exact same details etc would seem to indicate it must be their issue!)

15 REPLIES 15
Highlighted
Rising star

Mitchen,

Depending on the Access media used by your Telco, if the ATM encaps config solves your issue, then your DSLAM at the Site is acting as ATM Switch.

Depending on the Access media , DSLAM Type, there are different types of Access methodologies, its either Ethernet or ATM to carry out your PPP Session.

The DSLAM sends out your PPP frames encapsulated into ethernet or ATM Cells to L2TP Access Concentrator of your telco. The L2TP Access Concentrator strips the PPP header from the session and encapsulate the frames with L2TP header and carries out the session to your ISP (LNS) where the L2TP session gets terminated.

 

This is How xDSL works from the Client side to the ISP side through the Telco.