03-07-2012 02:42 AM - edited 03-04-2019 03:34 PM
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 ?
03-07-2012 02:58 AM
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
03-07-2012 03:13 AM
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
03-07-2012 05:42 AM
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
03-07-2012 06:24 AM
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
03-07-2012 07:15 AM
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
03-07-2012 09:28 AM
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
03-08-2012 12:03 AM
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.
03-08-2012 01:36 AM
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
03-21-2012 11:09 AM
The link is permanently up. No issues so far ... Strange.
Sent from Cisco Technical Support iPhone App
06-01-2012 02:51 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide