Disconnect idle vty sessions

[willemvwyk]

Hi

I have idle sessions on a 3640 and I have tried the disconnect session number, the username, the ip address, but no luck.

As can be seen from the below some sessions have been connected for weeks now. Is there a command I can use without reloading the router?

R01#sh user

Line User Host(s) Idle Location

129 aux 0 Modem Autoconfigure 00:00:00

*130 vty 0 user1 idle 00:00:00 192.168.255.37

131 vty 1 user2 idle 1w6d 192.168.200.178

132 vty 2 user3 idle 1w5d 192.168.200.190

133 vty 3 user2 idle 5d19h 192.168.200.170

134 vty 4 user2 idle 5d02h 192.168.200.189

Interface User Mode Idle Peer Address

thanks

wvw

[kerek]

Hi,

Try with clear line

Hope it helps, rate if does,

Krisztian

[ehayric1320]

A reboot of our core unfortunately was the ONLY thing that was able to clear up the issue for us.

[shawnadmin]

This also worked for me.  Funny I have a Lenovo / Juniper switch, and this command is not even documented in the reference document

[Richard Burts]

wvw

Would I be correct in assuming that your 3640 is configured to disable the inactivity timeout for vty lines? (no exec-timeout or exec-timeout 0)

I believe that the most effective way to disconnect idle sessions is to have the inactivity timeout running. You can set it to some fairly long interval if you want long lived telnet sessions. But if there is some timeout value specified then the idle sessions get disconnected.

HTH

Rick

[pouya.cisco]

I have a slightly different situation here, all lines are exhausted on a C3750 and I cannot telnet/ssh in to clear the lines. Unfortunately, exec-timeout was NOT set. Considering the switch is out of reach in the middle of whoop whoop, can anyone think of any options other than console access or system restart? The switch responds to ping, and it is located around 6 hours drive from our closest office.

Thanks,

P

[Georg Pauwen]

Hello,

if you are lucky the switch is configured for HTTP access. If not...reload is really your only option.

[Richard Burts]

HTTP access is a good solution. Another alternative to consider is the possibility that the device is configured with write access for SNMP. This is the other alternative for remote management that does not depend on the vty lines.

HTH

Rick

[Joseph W. Doherty]

Another method I believe that keeps lost sessions from hanging around

service tcp-keepalives-in

service tcp-keepalives-out

[mostafa-khalil]

Internet_Router#sh tcp brief    

TCB                 Local Address           Foreign Address        (state)

630B8690            x.x.x.x.23                 x.x.x.x.52089         ESTAB

then :

clear tcp tcb 630B8690

[YoSoyYorch]

2019 still works

[dmasiello]

try a:

clear line vty #

to be more specific

[ehayric1320]

We are experiencing a very similar issue on our 6509 VSS, there are 22 sessions all used up and we cannot delete them or clear them. Some have been idle for over 6 weeks and it is becoming a real issue because this our core and we cannot SSH in and have to console in when this happens.

I have tried clearing each line, setting exec timeout 0 to no avail. I believe another engineer said he deleted the VTY lines and recreated them when this issue first arose but it will not let me do that saying that they are in use yet it still does it! Very weird behavior, I would like to reboot but for obvious reasons that is an all else fails option.

[Richard Burts]

I do not understand your comment about exec timeout 0. But my point in the original thread was that exec-timeout 0 will cause this problem. And I believe that exec-timeout 120 (or pick some other number greater than zero) should fix it.

Other suggestions in this thread, especially sh tcp brief and "clear tcp tcb 630B8690", and "clear line vty #"  seem promising.

If you try these and none of them work then I suggest that you post the configuration, beginning at line vty, and also post the output of show line.

HTH

Rick 

[CSCO11851432]

it works 

thank u