cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8333
Views
32
Helpful
16
Replies

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

mitchen
Level 2
Level 2

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!)

1 Accepted Solution

Accepted Solutions

Jody,

Guessing the PPPoA config details can be a little mess, as the encapsulation can also be AAL5SNAP (seen that a couple of years back), and in that case, the configuration would be:

default interface ATM0
!
interface ATM0
no ip address
no ip directed-broadcast
no ip mroute-cache
pvc 0/38
 encapsulation aal5snap
 protocol ppp dialer 
 dialer pool-member 2

 

Just in case this one would work... As PPPoE currently runs over this ATM connection, it is more probable that if PPPoA happens to also be supported, it is going to use SNAP instead of MUX (PPPoE always goes in SNAP to my best knowledge).

Best regards,
Peter

View solution in original post

16 Replies 16

mitchen
Level 2
Level 2

Shameless bump for this one as we are still no further with re-establishing this connection!  Has anyone ever experienced similar and have any idea where the problem may reside?

On our part, we have tried 3 different routers (including 2 different models of Cisco router) on this line and none of them can establish PPP (although, it had been working without issue for several years until a few weeks ago when it just suddenly stopped working overnight)   We have also tried these routers - same configuration and authentication details on another line at a nearby site - and ALL worked ok, without a problem, established PPP and ADSL connectivity.

We have also replaced all internal cabling, microfilters etc.

We have had the line provider (BT) visit the site several times and they say there is no problem with the line.

I'm not too sure what actions the ISP themselves have taken other than to pass back to BT.

But scratching my head as to a) what else we can do now and b) where the problem lies? (is it with the ISP or is it with BT or could there still be an onsite issue that we have somehow missed ourselves?)

The router can sync with the exchange but then cannot establish PPP.

If anyone has any thoughts on this, it would be appreciated!  Thanks.

ghostinthenet
Level 7
Level 7

There are a few things to look into.

First of all, I would turn on "debug pppoe packet" and "debug ppp authentication" to see what's going on with your PPPoE requests. You should see PADI and PADO packets being sent and received at a minimum. If you're only seeing PADI and no PADO, your requests aren't being responded to and you should have a look at your PVC configuration. If you're getting PADI and PADO, look at the PPP authentication lines to see if your credentials are being rejected.

A couple of questions that might get us closer to finding the answer:

  1. Your provider wouldn't have bumped you up from ADSL to VDSL, would they? If so, an ATM interface-based configuration won't work and we need to move to a virtual Ethernet interface configuration. Can you post the output of "show controllers vdsl 0" to this question to be sure?
  2. Can you post the output of "show running-config interface ATM0" and the same for any ATM0 subinterfaces and relevant Dialer interfaces that you have? Definitely strike out the authentication username and password portions.

Hi Jody,

thanks for the suggestions.  Here's what I see from the ppp debugs (but I'm not sure how to interpret?)

Jan  6 14:50:22.838: pppoe_send_padi:
contiguous pak, size 74
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 FF FF
         FF FF FF FF BC 16 65 96 9B 00 88 63 11 09 00 00
         00 10 01 01 00 00 01 03 00 08 0C 00 00 01 00 00
         04 A3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00 ...
Jan  6 14:50:22.878: PPPoE 0: I PADO  R:0030.8810.000b L:bc16.6596.9b00 0/38  ATM0.1
contiguous pak, size 71
         BC 16 65 96 9B 00 00 30 88 10 00 0B 88 63 11 07
         00 00 00 33 01 03 00 08 0C 00 00 01 00 00 04 A3
         01 02 00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73
         2D 62 61 73 2D 42 32 32 36 45 34 37 30 39 45 30
         31 34 5A 01 01 00 00
Jan  6 14:50:24.885: OUT PADR from PPPoE Session
contiguous pak, size 85
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 00 30
         88 10 00 0B BC 16 65 96 9B 00 88 63 11 19 00 00
         00 33 01 03 00 08 0C 00 00 01 00 00 04 A3 01 02
         00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73 2D 62
         61 73 2D 42 32 32 36 45 ...
Jan  6 14:50:35.125: OUT PADR from PPPoE Session
contiguous pak, size 85
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 00 30
         88 10 00 0B BC 16 65 96 9B 00 88 63 11 19 00 00
         00 33 01 03 00 08 0C 00 00 01 00 00 04 A3 01 02
         00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73 2D 62
         61 73 2D 42 32 32 36 45 ...

Jan  6 14:50:45.364: OUT PADR from PPPoE Session
contiguous pak, size 85
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 00 30
         88 10 00 0B BC 16 65 96 9B 00 88 63 11 19 00 00
         00 33 01 03 00 08 0C 00 00 01 00 00 04 A3 01 02
         00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73 2D 62
         61 73 2D 42 32 32 36 45 ...
Jan  6 14:50:55.603: OUT PADR from PPPoE Session
contiguous pak, size 85
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 00 30
         88 10 00 0B BC 16 65 96 9B 00 88 63 11 19 00 00
         00 33 01 03 00 08 0C 00 00 01 00 00 04 A3 01 02
         00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73 2D 62
         61 73 2D 42 32 32 36 45 ...
Jan  6 14:51:05.843: OUT PADR from PPPoE Session
contiguous pak, size 85
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 00 30
         88 10 00 0B BC 16 65 96 9B 00 88 63 11 19 00 00
         00 33 01 03 00 08 0C 00 00 01 00 00 04 A3 01 02
         00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73 2D 62
         61 73 2D 42 32 32 36 45 ...
Jan  6 14:51:16.114: OUT PADR from PPPoE Session
contiguous pak, size 85
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 00 30
         88 10 00 0B BC 16 65 96 9B 00 88 63 11 19 00 00
         00 33 01 03 00 08 0C 00 00 01 00 00 04 A3 01 02
         00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73 2D 62
         61 73 2D 42 32 32 36 45 ...
Jan  6 14:51:26.353: [0]PPPoE 0: O PADT  R:0000.0000.0000 L:0000.0000.0000 0/38  ATM0.1
contiguous pak, size 74
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 00 00
         00 00 00 00 00 00 00 00 00 00 88 63 11 A7 00 00
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00 ...
Jan  6 14:51:46.576: pppoe_send_padi:
contiguous pak, size 74
         00 01 09 00 AA AA 03 00 80 C2 00 07 00 00 FF FF
         FF FF FF FF BC 16 65 96 9B 00 88 63 11 09 00 00
         00 10 01 01 00 00 01 03 00 08 0C 00 00 01 00 00
         04 A3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00 ...
Jan  6 14:51:46.608: PPPoE 0: I PADO  R:0030.8810.000b L:bc16.6596.9b00 0/38  ATM0.1
contiguous pak, size 71
         BC 16 65 96 9B 00 00 30 88 10 00 0B 88 63 11 07
         00 00 00 33 01 03 00 08 0C 00 00 01 00 00 04 A3
         01 02 00 1F 62 72 61 73 2D 72 65 64 37 2E 6C 73
         2D 62 61 73 2D 42 32 32 36 45 34 37 30 39 45 30
         31 34 5A 01 01 00 00

 

Provider wouldn't have bumped us from ADSL to VDSL - but here's the output of show controller vdsl 0:

 

Controller VDSL 0 is UP

Daemon Status:           Up

                        XTU-R (DS)              XTU-C (US)
Chip Vendor ID:         'BDCM'                   'IFTN'
Chip Vendor Specific:   0x0000                   0x71C8
Chip Vendor Country:    0xB500                   0xB500
Modem Vendor ID:        'CSCO'                   '    '
Modem Vendor Specific:  0x4602                   0x0000
Modem Vendor Country:   0xB500                   0x0000
Serial Number Near:    FCZ1111C08V C887VAG 15.2(4)M
Serial Number Far:
Modem Version Near:    15.2(4)M
Modem Version Far:     0x71c8

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
Trellis:                 ON                       ON
SRA:                     disabled                        disabled
 SRA count:              0                       0
Bit swap:                enabled                         enabled
 Bit swap count:         1                       8
Line Attenuation:        54.5 dB                 31.5 dB
Signal Attenuation:      54.5 dB                  0.0 dB
Noise Margin:             6.7 dB                 11.0 dB
Attainable Rate:        2132 kbits/s             888 kbits/s
Actual Power:            16.7 dBm                12.7 dBm
Total FECC:             546                      0
Total ES:               6                        0
Total SES:              0                        0
Total LOSS:             0                        0
Total UAS:              486                      486
Total LPRS:             0                        0
Total LOFS:             0                        0
Total LOLS:             0                        0

Full inits:             14
Failed full inits:      1
Short inits:            0
Failed short inits:     1

Firmware        Source          File Name (version)
--------        ------          -------------------
VDSL            user config     flash:vdsl.bin-A2pv6C035d_d23j (10)

Modem FW  Version:      110802_1752-4.02L.03.A2pv6C035d.d23j
Modem PHY Version:      A2pv6C035d.d23j
Vendor Version:


                  DS Channel1     DS Channel0   US Channel1       US Channel0
Speed (kbps):             0             1664             0               704
SRA Previous Speed:       0                0             0                 0
Previous Speed:           0             1600             0               736
Total Cells:              0          2786872             0                 0
User Cells:               0               68             0                 0
Reed-Solomon EC:          0              546             0                 0
CRC Errors:               0                9             0                 0
Header Errors:            0               10             0                 0
Interleave (ms):       0.00             8.00          0.00              8.00
Actual INP:            0.00             1.12          0.00              1.28

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

 

And here's the output from the ATM and dialer interfaces:

interface ATM0
 no ip address
 ip flow ingress
 no atm ilmi-keepalive
end
!
!
interface ATM0.1 point-to-point
 ip flow ingress
 pvc 0/38
  pppoe-client dial-pool-number 2
 !
end
!
!
interface Dialer2
 description OUTSIDE
 ip address negotiated
 ip access-group firewall in
 ip mtu 1492
 ip flow ingress
 ip nat outside
 ip inspect DEFAULT100 out
 ip virtual-reassembly in
 encapsulation ppp
 dialer pool 2
 dialer-group 2
 ppp authentication chap callin
 ppp chap hostname ###removed###
 ppp chap password ###removed###
 no cdp enable
 crypto map dcvpn
end

 

As I say though, config-wise, everything should be correct - the same router works fine on another line (which should also confirm the authentication details are correct - at least in as far as it matches what the ISP have on their RADIUS)

 

Any further thoughts?

 

You're on old-fashioned G.992 ADSL, which explains the slow speed negotiation (1.6Mb up and .7Mb down) and means we don't have to worry about VDSL.

The PPPoE debugs look interesting. You're sending the PADI initiation and receiving a PADO offer, but when you send the PADR requests to the provider, you're not getting a response and the session is never completing.

Are you actually using BT as your ISP or are you using an ADSL reseller? I'm wondering if this is a PPPoA service rather than a PPPoE service.

Hi Jody,

Please allow me to join.

I'm wondering if this is a PPPoA service rather than a PPPoE service.

If this was a true PPP over ATM service (PPPoA), we wouldn't be seeing any of the PPPoE negotiation (PADI/PADO/PADR/PADS/PADT). PPPoA is simply about putting PPP frames directly into ATM+AAL5, with no intermediate Ethernet layer anywhere inbetween.

Definitely, your assessment of the situation regarding the PPPoE Active Discovery process is correct: the router and the access concentrator are able to talk to each other but when the router tries to request a Session ID from the access concentrator by its PADR message, that one is never replied to.

However, because mitchen mentions that on a different line, the same configuration works nicely, I tend to believe that we are probably dealing with a problem that the PPPoE client's MAC address is only permitted on a particular DSL link, or that there is some kind of limit on the number of sessions for a particular client's MAC. At this point, I think the most prudent course of action would be to call the ISP and ask for assistance, explaining that the device was moved from one ADSL line to another, and while the router trains to DSLAM nicely and is able to talk via PPPoE to the access concentrator, it never gets past the initial PADI/PADO sequence; the PADR is unreplied.

Best regards,
Peter

Hey Peter:

Thanks very much for the input.

That's a fair assessment and definitely a worthwhile course of action. I only ask about the PPPoE/PPPoA possibility because some providers that wholesale to other resellers have been known to offer both services depending on the reseller. BT in particular has used both.

Mitchen, can you give your ISP a call and see which they use? If they're PPPoE, you'll need to work with them to see why they're not responding to PADR. If they're using PPPoA, you'll need to do some reconfiguration to change the framing of your connection.

Jody

Yeah, the line is good old G992 ADSL because we originally had an older Cisco 877 ADSL router on it which didn't behave too well with ADSL2+!  (Must stress this connection was working fine for several years before just suddenly stopping in the middle of the night a few weeks ago - so nothing has "changed" from our side of things, and we have only tried replacing routers/cabling etc in light of the problem)

 

BT are not the ISP, we do use an ADSL reseller.  Now, I'm not 100% certain on this but casting my mind back, I THINK that it is a PPPoA service rather than PPPoE but that we configure the encapsulation for PPPoE anyway (I'm sure there's a reason for this but I can't remember off the top of my head at the moment, too much festive whisky affecting my brain I think!)

Anyway, we have hundreds of other sites configured in the same way and working without issue and, as I say, this one WAS working ok until fairly recently so I wouldn't have thought that was likely to be the problem cause?  Happy to be corrected if you think otherwise though?

 

If all of your other connections with the same provider are PPPoE, I would follow Peter's advice and get on the phone with the ISP. Let them know that your PPPoE session isn't completing because they're not responding to PADR packets. If they try to steer you to an authentication issue, make it clear that you're not getting that far.

If you want to try PPPoA as a shot in the dark to see if it works, you can make the following change:

no interface ATM0.1
!
default interface ATM0
!
interface ATM0
no ip address
no ip directed-broadcast
no ip mroute-cache
pvc 0/38
 encapsulation aal5mux ppp dialer 
 dialer pool-member 2

If that doesn't immediately bring the connection up, back out to what you previously had and get on the phone with the ISP.

Backing out can be accomplished as follows:

default interface ATM0
!
interface ATM0
no ip address
no ip directed-broadcast
no ip mroute-cache
pvc 0/38
  pppoe-client dial-pool-number 2

Hi Jody,

yeah, i gave PPPoA a go just after you suggested it earlier just on the off-chance but, alas, no joy with that either.

 

Jody/Peter - thanks for your input on this.  I still have the call open with the ISP but not getting anywhere fast (hence my questions on here!) but I'll get back to them with the details you have assisted me with on the PPPoE interactions and see if that can help them to pinpoint the problem cause.

 

Thanks once again for your assistance.

 

Jody,

Guessing the PPPoA config details can be a little mess, as the encapsulation can also be AAL5SNAP (seen that a couple of years back), and in that case, the configuration would be:

default interface ATM0
!
interface ATM0
no ip address
no ip directed-broadcast
no ip mroute-cache
pvc 0/38
 encapsulation aal5snap
 protocol ppp dialer 
 dialer pool-member 2

 

Just in case this one would work... As PPPoE currently runs over this ATM connection, it is more probable that if PPPoA happens to also be supported, it is going to use SNAP instead of MUX (PPPoE always goes in SNAP to my best knowledge).

Best regards,
Peter

Hey Peter:

Good catch! I don't do PPPoA nearly as often as PPPoE, so the details tend to get missed.

Thanks!

Jody

Hi guys,

 

well, this has me baffled - I tried the AAL5SNAP encapsulation suggested by Peter and, what do you know, it worked! PPP established, IP assigned and ADSL connectivity resumed!

However, I'm very confused as to a) why we would suddenly need to change it to PPPoA when it had been happily configured as PPPoE for several years (and, as I said before, we have literally hundreds of other sites configured as PPPoE without issue)

Can anyone suggest what would be the cause of this?  What is more worrying for me is that if this should suddenly start to happen on any of our other connections!

Thanks.

Mitchen,

Why the sudden change to PPPoA - I honestly do not know, and this is a question only BT and your ISP can answer. The change of access technology is absolutely outside your reach and you could not do anything to either cause or prevent it. It is the BT or ISP who must have made a change.

Following the general architecture of the DSL service, the data you are sending to the DSL network are processed according to the following generic steps:

  1. Packets are encapsulated into PPP frames on your router
  2. If PPPoE is used, an additional Ethernet+PPPoE encapsulation takes place
  3. ATM AAL5 encapsulation is performed on the resulting frames and the AAL5 PDUs are carried in ATM cells to the DSLAM over the local phone loop
  4. Depending on the DSLAM capabilities your modem talks to, it either acts as an ATM switch and forwards the ATM cells to a BRAS, or it takes out the encapsulated PPP or PPPoE frames and forwards them to the BRAS using some kind of pseudowire technology (L2TP, MPLS)
  5. BRAS forwards the frames further to your ISP based on your credentials you have used to login to the network; the tunnel is almost universally L2TP

The steps 3 and 4 are the most probable places where a configuration change could have taken place. Either the DSLAM you're talking to on this particular line is currently forwarding your ATM cells to a differently configured BRAS than before (a BRAS that runs PPPoA instead of PPPoE), or the BRAS itself must have changed. Simply put, it appears that on this particular line using this particular ATM VPI/VCI, you are talking to a different service than before, and it is the result of how the DSLAM and BRAS are configured. Why is that - only the BT and ISP can answer. I would even say that BT is more responsible for this, as the BRAS is still a device owned and operated by BT.

It would be very good if you could have a skilled technician from BT to come at your site, and you demonstrate the difference between the two lines you have available. The BT guy should then compare step-by-step going over the local loop, DSLAM ports, their config, the forwarding config etc., to find out where the configuration of the DSL service starts to differ on these two lines.

Best regards,
Peter

Hi Peter,

thanks very much for your assistance on this and in particular your detailed explanations - that has been extremely useful in a) helping me resolve this problem and b) increasing my understanding of things.  Same goes for Jody and Mohamed - really appreciate your valuable input, in my mind, that's exactly what this forum is all about!

Peter - I would love to get that skilled technician from BT to site that you mentioned but easier said than done in my experience so I won't hold my breath!  However, I will certainly push the ISP/BT for more information on exactly what has happened here - if I do manage to find out anything interesting then I will be sure to post back with the info.

Thanks again for all your help, gents.

 

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: