pppoE dialup link dead

[Dan Jay]

Dear all,

I'm in an issue w/ on of our ISPs. We're using an ADSL line as a secondary ligh load line ( 16 MBit, /w PBR in place to

separate the 80 and 443 from the business-critical applications running via a SDSL link. ).

I am on a 2611 XM with IOS 12.2, mated to a D-Link 321B modem running in transparent mode.

After running smoothly for weeks, for a few days now, every night some time between 2 AM and 4 AM the link would die with the dialer showing:

Virtual-Access1 is up, line protocol is down

  Hardware is Virtual Access interface

  MTU 1500 bytes, BW 100000 Kbit, DLY 100000 usec,

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

  Encapsulation PPP, loopback not set

  Interface is bound to Di2 (Encapsulation PPP)

  LCP ACKrcvd

  Closed: BRIDGECP, IPCP, CCP, CDPCP, LLC2, BACP, IPV6CP

To my knowledge, the only option to bring it up again is to reload the box ( if any other workaround applies, please say so... ).

Taking into acount that the router is our DHCP server and the date gets reset to 1994, interesting effects are the outcome of resetting the box.

Well, the ISP have checked their gear and keep saying that these report a "port error" ( quite unspeicific ) and blame me that I have a wrong

config in place - which is here:

interface Dialer2

description ecotel Bridge

ip address negotiated

no ip proxy-arp

ip mtu 1492

ip nat outside

encapsulation ppp

no ip split-horizon

dialer pool 1

dialer redial interval 5 attempts 10

dialer string "*99#"

dialer hold-queue 10

dialer vpdn

dialer-group 1

fair-queue 64 256 0

no cdp enable

ppp authentication chap pap callin

ppp pap sent-username ** password ***

ppp ipcp dns accept

ppp ipcp address accept

end

Can someone point me in the right direction on what exactly to debug for should the link quit ?

[Peter Paluch]

Hello Dan,

Interesting. I assume that there is no DSL card in your 2600XM router, rather, you are running a PPPoE client on its Ethernet interface, and the DSL modem is the standalone device you've mentioned. Am I correct?

As the first thing to try, can you please remove the ppp authentication chap pap callin command from your Dialer interface? That command is not necessary at all - it appears in official Cisco howtos but it's basically misplaced in this configuration and should not be used on your part.

Another suggestion: when the connection breaks, can you issue the debug ppp negotiation command and capture the output that appears on the console? (It can also be directed to your Telnet/SSH session using the terminal monitor command). If your router engages into PPP negotiation with the remote device, we should be seeing messages showing us what exactly is going on.

Best regards,

Peter

[Dan Jay]

Hi Peter,

thanks for your input. Yes, you're right; there is no DSL WIC in there; just the 2 default Ethernet ports ( and a ISDN 4-BRI NM fitted which is not being used at all anymore ).

I have removed the ppp auth commands.

I have set the debug commands as suggested.

Do you have an idea on how I could trigger the dialin manually right now ? shut/noshut doesn't work, the protocol does

not come up. ( Resetting the modem behind it yields the same. )

Dan

[Peter Paluch]

Hello Dan,

You mean, the PPPoE is down right now? I would try shutting down the Ethernet interface and activating it again. And also, I would try running the debug pppoe events in addition to the debug configured earlier to see if the PPPoE discovery process is working at all.

Best regards,

Peter

[Dan Jay]

Hi Peter,

I reloaded the box, the link came up again. Quite a bunch of output is sent to my kiwi install right now.

Currently debug is set to:

Dial on demand:

  Dial on demand events debugging is on

PPP:

  PPP detailed event debugging is on

  PPP authentication debugging is on

  PPP protocol errors debugging is on

  PPP protocol negotiation debugging is on

Let's see what happens tonight and if we can spot the suspect; I' ll post the outcome tomorrow.

Thanks,

Dan

[Peter Paluch]

Hello Dan,

Hmmm, I see. Please also activate the PPPoE debugs as suggested in my last response. Did you try to have those debugs activated also before the reboot? Was no message produced, even if bouncing the ethernet interface?

Thank you!

Best regards,

Peter

[Dan Jay]

Could not do that as reloading causes the box to forget its debug settings. The link came up by itself as usual much faster than I could have entered any debug commands. Flipping the Interface didn't bring anything.

Sent from Cisco Technical Support iPhone App

[Dan Jay]

Just a quick heads-up: The box didn't exit tonight. I reloaded yesterday around 2 PM local time, let's see what happens after 24 hours....asides, the log is full with entries like

03-08-2012    09:01:06    Local7.Debug    12094: 17:46:49: Vi1 EVT: Packet [0] 1 0x829D8480

Nothing critical. Will keep you updated.

[Peter Paluch]

Hello Dan,

Thank you very much. It is good to know that the link remained stable today but I am not yet willing to accept that the removal of the single command did the trick. Let's wait for another couple of days - but I am sure very much interested in knowing how it turns out!

Best regards,

Peter

[Dan Jay]

The link is permanently up. No issues so far ... Strange.

Sent from Cisco Technical Support iPhone App

[Dan Jay]

The link failed again 4 Times in a Row last week, mostly in the morning hours. I brought it back up via Clearing the Virtual access interface. The ISP isn't willing to Support a cisco Box on CPE side of Things so I guess i'm Lost on this One. There is no debug as the dialer interface and its corresponding Ethernet-ifc are alive when the link dies. The virtual-Access loses its L3, thus killing the Transport atop of it. SNAFU

Sent from Cisco Technical Support iPhone App