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?
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
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.
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.
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.
Internet_Router#sh tcp brief
TCB Local Address Foreign Address (state)
630B8690 x.x.x.x.23 x.x.x.x.52089 ESTAB
clear tcp tcb 630B8690
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.
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.
This worked for me too.
Luckily I got one session.. and able to clear all other idle sessions.
If no luck, get console access and clear sessions.
I am looking for a CCNP R+S certified Technical Service Engineer to come onboard at one of my client sites in Reading.
You will be responsible for leading the technical relationship of one or more clients on a tactical day to day basis, liaising closely and supporting, where appropriate, strategic initiatives led by the client account team.
The following core technical skills are pre-requisites for the role: -
Monetary package is up to 70K (Bonus inclusive)