[c-nsp] Cisco 6509-E SSH and Telnet not allowing connections

[Lukas Tribus]

Hello,


On Sat, 27 Feb 2021 at 20:03, Lee Starnes <lee.t.starnes at gmail.com> wrote:
>
> Hello all,
>
> Ran into an issue that I can't seem to resolve and really don't want to
> reboot the chassis. Have 1 of our 6509-e units that has decided it is not
> going to allow connections to it via ssh or telnet. I can get access via
> console. When trying to connect, you do not get connection refused. You
> just hang for several seconds before getting a connection timed out
> message.
>
> On the switch, I show no connection attempts.
>
> A check to see if the ssh server is running and have any connections shows
> normal.
> #sh ip ssh
> SSH Enabled - version 1.99
> Authentication timeout: 120 secs; Authentication retries: 3
> #sh ssh
> %No SSHv1 server connections running.
> %No SSHv2 server connections running.
>
> Doing debugs, I see nothing show up for connection attempts. Also if I
> attempt to connect to itself from itself it also just hangs before getting
> a connection timed out message. I would expect the normal response of
> connection refused when trying to connect to itself.
>
> There is an ACL in place on the VTY lines and even removing that, still
> gets the same results. I have removed the input transport on the vty lines
> and then read added them.
>
> Is there anything else I can try before having to reboot/switch to the
> standby SUP?
>
> This was all working normally until sometime around 4am. and nothing was
> logged before or after the issue started other than my login via console
> and various changes/commands issued in an attempt to debug/resolve this
> issue.

show users
show line
show line summary
show tcp brief | inc \.23 |\.22 ||Foreign

How many VTY lines are actually configured?

I'm thinking about hung VTY sessions. Use "clear line ..." and "clear
tcp tcb ..." to kill orphan sessions and TCP connections. You can also
try raising the number of VTY lines.



> There is an ACL in place on the VTY lines and even removing that, still
> gets the same results. I have removed the input transport on the vty lines
> and then read added them.

Instead of removing and adding "input transport" again, try removing
the line vty section (in its entirety), and reconfigure it from
scratch.



Lukas