Disconnect idle vty sessions

Unanswered Question
Sep 10th, 2007
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (9 ratings)
Loading.
ehayric1320 Wed, 07/22/2015 - 16:16
User Badges:

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

Richard Burts Mon, 09/10/2007 - 03:38
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Wed, 07/19/2017 - 23:51
User Badges:

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 Thu, 07/20/2017 - 00:38
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 WAN

Hello,

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

Richard Burts Tue, 07/25/2017 - 15:14
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 Mon, 09/10/2007 - 08:36
User Badges:
  • Super Bronze, 10000 points or more

Another method I believe that keeps lost sessions from hanging around


service tcp-keepalives-in

service tcp-keepalives-out

mostafa-khalil Tue, 01/28/2014 - 23:20
User Badges:

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

ehayric1320 Tue, 10/07/2014 - 12:52
User Badges:

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 Tue, 10/07/2014 - 14:46
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

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 

Jobish James Tue, 07/12/2016 - 23:49
User Badges:

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.


Jobish James

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: -

 

  • Experience diagnosing complex issues through packet capture analysis (Wireshark, tcpdump, snoop, Sniffer Pro)
  • Hands on experience including but not limited to:
  • Cisco switches, routers and Firewalls
  • Juniper switches and routers
  • F5 Big-IP and Cisco ACE load balancers
  • Check Point Firewalls
  • Palo Alto (can be taught)

 

Monetary package is up to 70K (Bonus inclusive)

Actions

This Discussion