cleaning vty session.
in [Cisco]
|
From: AM on 29 Jan 2007 17:14 Sam Wilson wrote: > In article <gFpvh.10246$422.142715(a)twister2.libero.it>, AM <am(a)am.am> > wrote: > > >>Bod43(a)hotmail.co.uk wrote: >> >> > Why don't you post a session log >> >>>showing what it not working. >>> >>>i.e. >>> >>>sh line >>>sh tcp n >>>clear line n >>>sh line ! and we will see that the clear has failed. >>> >>>You WILL need to be "Enabled". >>> >> >>Thanks bod43, >> >>I'm still on the way. >>Maybe the following output clarifies what's happening on that router: >> >>---------------------------------------------------------------------------- >>[ example deleted ] >> >>I hope this clarify better what the situation is. >>By all methods the command doesn't warn that the "deletion" wasn't applied >>and the session still persist to be up, or at >>least in those state. >>Thanks a lot for your time. > > > For what it's worth we have 6500s which have shown a similar problem. > Here's an example from the logs: > > wg4>sh user > Line User Host(s) Idle Location > 1 vty 0 idle 1y4w customer-LZC-static-224-72.cablered.com.mx Who is it? You are lucky that someone monitors your switch so long ;-) > * 2 vty 1 idle 00:00:02 [a local address] > > hard. There was no obvious damage to the routers. My fears are that unclear sessions could grow. And I managed that router only by remote. I reached the maximum number of vty logins and only due to the fact that someone on the site was asked to connect a console cable to a computer I could enter the router. But that's a workaround and the router is not supposed to be reached via a console cable throughout its life. I increased the number of vty session available hoping to be always lucky. Anyway I learned to clearly exit the session before it gets frozen or stuck. Thanks Alex
From: AM on 29 Jan 2007 17:17 Sam Wilson wrote: > In article <gFpvh.10246$422.142715(a)twister2.libero.it>, AM <am(a)am.am> > wrote: > > wg4>sh user > Line User Host(s) Idle Location > 1 vty 0 idle 1y4w customer-LZC-static-224-72.cablered.com.mx Who is it? You are lucky that someone monitors your switch so long ;-) > * 2 vty 1 idle 00:00:02 [a local address] > > hard. There was no obvious damage to the routers. My fears are that unclear sessions could grow. And I managed that router only by remote. I reached the maximum number of vty logins and only due to the fact that someone on the site was asked to connect a console cable to a computer I could enter the router. But that's a workaround and the router is not supposed to be reached via a console cable throughout its life. I increased the number of vty session available hoping to be always lucky. Anyway I learned to clearly exit the session before it gets frozen or stuck. Thanks Alex
From: Sam Wilson on 30 Jan 2007 05:34 In article <45BE71D7.1010604(a)am.am>, AM <am(a)am.am> wrote: > Sam Wilson wrote: > > > > For what it's worth we have 6500s which have shown a similar problem. > > Here's an example from the logs: > > > > wg4>sh user > > Line User Host(s) Idle Location > > 1 vty 0 idle 1y4w > > customer-LZC-static-224-72.cablered.com.mx > > Who is it? You are lucky that someone monitors your switch so long ;-) A cable attached home system in Mexico? We were flattered. Not. "sh tcp vty 0" showed only a handful of packets exchanged and a huge number of retransmits. Looks like a bug in IOS' TCP - failing to clear the call after retransmission failure. > > * 2 vty 1 idle 00:00:02 [a local address] > > > > hard. There was no obvious damage to the routers. > > My fears are that unclear sessions could grow. And I managed that router only > by remote. ... I think we only ever saw them on VTYs configured with "no exec-timeout". > ... I reached > the maximum number of vty logins and only due to the fact that someone on the > site was asked to > connect a console cable to a computer I could enter the router. But that's a > workaround and the > router is not supposed to be reached via a console cable throughout its life. > I increased the number > of vty session available hoping to be always lucky. > Anyway I learned to clearly exit the session before it gets frozen or stuck. Were your execs configured to timeout? That's usually the default so unless you reconfigured them or you are running an image with a different default then this may not be the same problem. Sam
From: AM on 30 Jan 2007 08:57 Sam Wilson wrote: > In article <45BE71D7.1010604(a)am.am>, AM <am(a)am.am> wrote: > > I think we only ever saw them on VTYs configured with "no exec-timeout". I think I can give further details on the topic. I have used the router 2611 as a jump to get connected to another device. Most of the time the "pending" sessions belongs to sessions that saw a starting a SSH client towards other devices. So the problem could reside on it. I enabled the time-out on sessions but even so I'm seeing the number of pending session increasing. HTH Alex
From: Aaron Leonard on 30 Jan 2007 12:37 A few general comments in this area: exec-timeout affects vty sessions that are sitting at the exec prompt. If the vty session is running an ssh/telnet client session, then the session-timeout would be appliable instead. TCP keepalives in and out are a good idea if you want to keep your lines clean. Otherwise you can get clogged up with old idle TCP sessions whose peers have vanished. There have existed some bugs where a vty can get stuck, and "clear line" is no avail. Aaron --- ~ Sam Wilson wrote: ~ > In article <45BE71D7.1010604(a)am.am>, AM <am(a)am.am> wrote: ~ ~ > ~ > I think we only ever saw them on VTYs configured with "no exec-timeout". ~ ~ I think I can give further details on the topic. ~ ~ I have used the router 2611 as a jump to get connected to another device. ~ Most of the time the "pending" sessions belongs to sessions that saw a starting a SSH client towards other devices. ~ So the problem could reside on it. ~ I enabled the time-out on sessions but even so I'm seeing the number of pending session increasing. ~ ~ HTH Alex
First
|
Prev
|
Pages: 1 2 Prev: Cisco SDM Java Applet StackOverflowError Next: Spurious interrupts on a 2821 |