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)
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:
description ecotel Bridge
ip address negotiated
no ip proxy-arp
ip mtu 1492
ip nat outside
no ip split-horizon
dialer pool 1
dialer redial interval 5 attempts 10
dialer string "*99#"
dialer hold-queue 10
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
Can someone point me in the right direction on what exactly to debug for should the link quit ?
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.
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. )
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.
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 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.
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?
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
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  1 0x829D8480
Nothing critical. Will keep you updated.
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!