PPP negotiation problems

nikolay-shopik · ‎07-11-2007

Hi everyone,

I run into some unknown problems when doing simple PPPoE configuration. When my dialer get's ip address it's disconnects in next few seconds and start ppp negotiation from begining. Here is debug below with ppp negotionaion and sss events debuging on.

I'm running on 2811 this one and I tried same simple config on 851 and its' work and there no such lines like SSS.

Any ides why it's wrong?

here is part of my config

interface FastEthernet0/1

no ip address

duplex auto

speed 10

pppoe enable

pppoe-client dial-pool-number 1

interface Dialer0

bandwidth 153

ip address negotiated

encapsulation ppp

dialer pool 1

no cdp enable

ppp chap hostname mobile

ppp chap password 0 internet

paolo bevilacqua · ‎07-11-2007

Hello,

The SSS lines are not the apparent cause of the problem. The misunderstanding happens here:

Jul 11 15:40:48.373: Vi3 IPCP: I CONFACK [ACKsent] id 2 len 10

Jul 11 15:40:48.373: Vi3 IPCP: Address 83.217.58.185 (0x030653D93AB9)

Jul 11 15:40:48.373: Vi3 IPCP: State is Open

Jul 11 15:40:48.373: Di0 IPCP: Install negotiated IP interface address 83.217.58.185

%LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

Jul 11 15:40:49.377: Di0 IPCP: Install route to 212.119.106.133

Jul 11 15:40:49.377: Vi3 IPCP: Add link info for cef entry 212.119.106.133

Jul 11 15:40:54.192: Vi3 LCP: I CONFREQ [Open] id 1 len 21

Jul 11 15:40:54.192: Vi3 LCP: ACCM 0x00000000 (0x020600000000)

Jul 11 15:40:54.192: Vi3 LCP: AuthProto CHAP (0x0305C22305)

Jul 11 15:40:54.192: Vi3 LCP: MagicNumber 0x3A0C623F (0x05063A0C623F)

Jul 11 15:40:54.192: Vi3 IPCP: State is Closed

The router has received ACK for IP address, all is good and route is installed. Then the remote begins LCP again, without an apparent reason. See CONFREQ with status [Open].

It would be interesting to see the same trace taken with the working 851 to compare.

nikolay-shopik · ‎07-12-2007

Here is debug taken from 851 there it's working just fine. I put full trace including shutdown command

paolo bevilacqua · ‎07-12-2007

Has the 851 trace been taken on the same circuit ?

The thing is that the BRAS (ISP router) is starting negotiation again approx 5 secs after it was successfully negotiated. This could be caused only by a change of state on the ATM / VC level. But we have no visibility on that, because the ADLS line is terminated in the ISP modem/bridge.

I'm not sure how I would continue debugging this. Perhaps the ISP would collaborate taking a trace on their side ? I understand that it is unlikely.

nikolay-shopik · ‎07-12-2007

This is not a ADSL line it's 3G EVDO box. And it's taken from diferent places - so I have to check at same places to make sure have same condition.

It was worked some time ago.

And what most interested thing is what I can establish PPPoE session from computer just fine in same place.

paolo bevilacqua · ‎07-13-2007

Can you monitor the evdo box in some way ?

The only think that can make the ISP restarting PPP, would be something like carrier loss or circuit error.

But I don't see that happening in the trace.

nikolay-shopik · ‎07-13-2007

Not really it's running linux embended with very limited functional but I've give a try to see logs in it.

Just this moment I'm writing this message on connected PPPoE session on my apple mac, and cisco2811 stays just right on me.

I let you know if I find something interested.

paolo bevilacqua · ‎07-13-2007

Ok, can you put an ethereal or tcpdump between evdo box and router ?

As I said I see the failure coming from evdo box but perhaps a trace could revel something more.

nikolay-shopik · ‎07-13-2007

I have no idea how to put wireshark between evdo box and my cisco if it will be router PPPoE won't work because its Layer 2 as you know. Only way is get somewhere hub instead of switch ;)

If you know how to accomplish more easy let me know.