From: Mat W. <ma...@ma...> - 2007-10-12 00:20:46
|
Hi Ryan, We see this every now and then, more so on DSL services. Sometimes a DSL service will drop its PPP session on the CPE end and cycle so quickly, that is - fire up another PPP session, that sometimes the BRAS/LAC ends up recycling the same L2TP session. Hence, you get LCP ConfigReq coming into a PPP session on L2TPNS that's trying to close it. Cisco's are much friendlier to this type of phenomenon and just accept the new LCP and bring the PPP Virtual Interface back up. We keep an eye on our logs for these types of services, as we generally only see a few each month. Regards, Mat Ryan Barnes wrote: > I've seen quite a few posts on this in the archives, but haven't run > across any fixes... > On a recent code upgrade to this new revision from an older one we are > now seeing tons of hung sessions which we are having to manually > clear. PPP Phase is Established but LCP is stuck at Closing. Any > subsequent attempts to connect result in successful authentication, > but the user is unable to pass any data. > > Session 803: > User: <user> > Calling Num: > Called Num: > Tunnel ID: 2 > PPP Phase: Establish > * LCP state: Closing* > IP address: 2xx.xxx.xxx.xxx > Unique SID: 244752 > Opened: 12125 seconds > Idle time: 22 seconds > Bytes In/Out: 88719/0 > Pkts In/Out: 803/0 > MRU: 1492 > Rx Speed: 149760000 > Tx Speed: 149760000 > Intercepted: no > Walled Garden: no > Throttled: YES (128kbps/256kbps) > Rate Credit Queued | ByteIn PackIn ByteSent > PackSent PackDrop PackDelay > TBFI#1315 131072 32768 0 | 0 0 > 0 0 0 0 > TBFO#1316 262144 65484 0 | 14306 99 > 14306 99 0 0 > > Does anyone have a similar problem, and if so, is there a fix for > this, or are we stuck with either downgrading our code, or cron'ing a > job to root through our log files to kill sessions? This seems to > affect a wide variety of devices/modems/operating systems. > > Oct 11 11:02:48 hostname server[2336]: 02/3524 Login by user at > 2xx.xxx.xxx.xx from 2xx.xxx.xxx.xx (provider) > Oct 11 11:02:48 hostname server[2336]: 02/3524 Unexpected LCP code > TerminateAck > Oct 11 11:02:50 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:02:51 hostname server[2336]: 02/3524 Unexpected LCP code > TerminateAck > Oct 11 11:03:10 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:03:31 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:03:51 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:04:11 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:04:32 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:04:52 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:05:12 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > Oct 11 11:05:33 hostname server[2336]: 02/3524 LCP: ignoring ConfigReq > in state Closing > > Any suggestions? I notice a few of you have been experiencing this > problem for quite some time.... > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ------------------------------------------------------------------------ > > _______________________________________________ > L2tpns-users mailing list > L2t...@li... > https://lists.sourceforge.net/lists/listinfo/l2tpns-users > |