Showing results for 
Search instead for 
Did you mean: 

ssh not getting logged out even after exec-timeout expiry

Hello guys,

I have got a couple of problems with Cisco Prime Infrastructure and the Nexus 7000 switches.

I am becoming locked out of the Nexus (via ssh to the vty) as all (default)16 sessions are being hung by Cisco Prime Infrastructure.  I can see this using a "show users" (from someone who us already logged in) – the dedicated Cisco Prime Infastructure account is using all the session slots.  I realise we can increase the session-limited but I don't think this will help as the other sessions will get filled up.

A connected issue is that the exec-timeout is not working – if I ssh on and leave my putty window open it will stay connected indefinitely even if I type no commands to the window.  So the NXOS is not clearing this after 30 mins as it should.

Nexus config:

line vty

  session-limit 16

  exec-timeout 30

Cisco Prime Infrastructure Details:

ver: 1.3 (

Virtual Appliance

Cisco Nexus 7000 Details:

LDN-40-A# sho ver

Cisco Nexus Operating System (NX-OS) Software

TAC support:


Copyright (c) 2002-2013, Cisco Systems, Inc. All rights reserved.

The copyrights to certain works contained in this software are

owned by other third parties and used and distributed under

license. Certain components of this software are licensed under

the GNU General Public License (GPL) version 2.0 or the GNU

Lesser General Public License (LGPL) Version 2.1. A copy of each

such license is available at and


  BIOS:      version 2.12.0

  kickstart: version 6.2(2)

  system:    version 6.2(2)

  BIOS compile time:       05/29/2013

  kickstart image file is: bootflash:///n7000-s2-kickstart.6.2.2.bin

  kickstart compile time:  7/9/2013 20:00:00 [08/22/2013 04:51:27]

  system image file is:    bootflash:///n7000-s2-dk9.6.2.2.bin

  system compile time:     7/9/2013 20:00:00 [08/22/2013 08:07:03]


  cisco Nexus7000 C7009 (9 Slot) Chassis ("Supervisor Module-2")

  Intel(R) Xeon(R) CPU         with 32745068 kB of memory.

  Processor Board ID JAF2255BCLD

  Device name: LDN-40-A

  bootflash:    2007040 kB

  slot0:              0 kB (expansion flash)

Kernel uptime is 64 day(s), 3 hour(s), 54 minute(s), 34 second(s)

Would you please help with this?

Kind Regards,

Vinod Arya
Cisco Employee

There are known issues for Nexus and Prime :

CSCue74597 N7K: Stale SSH sessions are seen if client is not sending close ack.

CSCui76897 PI 1.3.1 CA is not cleaning up the CLI Session with N7k & N5k

**Rating Encourages contributors, and its really free. **

-Thanks Vinod **Rating Encourages contributors, and its really free. **

Hi all

It is interesting to see that Allan has this problem in a N7000 with NX-OS 6.2(2), as that release is stated to contain a fix for CSCue74597. To me, this suggests that the fix may not be working as intended.

I would appreciate if someone from Cisco could comment on this as I have a customer with the exact same problem...

Also, I wonder why this issue is not corrected in the Prime Infrastructure product as the bug-description seems to suggest that it is indeed Prime Infrastructure (and LMS) that fails to send the ACK triggering the error.

Best Regards

Niels Friis-Hansen

If you check CSCui76897 that says the older bug though is addressed on 6.2 and 7.0 releases, but this time it is form PI side, which is not releasing lines.

This will be addressed with PI 2.1.

The other bug was just for reference for older releases of NX-OS, in case affected in network.



**Support Conributors. RATE them. **

-Thanks Vinod **Rating Encourages contributors, and its really free. **

Just a further clarification to Niels response. There seems to be two issues here:

1. The issue where ssh sessions don't expire even though there's config for them to expire as follows:

line vty

  session-limit 16

  exec-timeout 30

2. The Prime Infrastructure bug where it doesn't clean up ssh sessions and just keeps creating new ones (which is exactly what we're seeing) which should be fixed in 2.1.

Issue 2 would be fixed by the correct resolution to issue 1.

So as Niels says, it looks like there's still an issue with vty session in 6.2...