Can´t access a switch via telnet and SSH

[danilopasiani1]

Hello,

I have a problem.

I enable kron in my switch and after that a lost connect with switch via SSH and Telnet.

I can connect only via console.

Someone known what happened ?

I put this config.

CORE-4500(config)#kron policy-list Backup-config

CORE-4500(config-kron-policy)#cli show running-config | redirect ftp://10.30.0.1/CORE-4500

CORE-4500(config)#kron occurrence weekly-Backups01 at 23:50 Tue recurring

CORE-4500(config-kron-occurrence)#policy-list Backup-config

[Mark Malone]

Hi a Kron job should not break remote access , did anything appear in logging around the time you created the kron job

can you still ping the ip address from your remote device your connecting from that you would ssh too make sure reachability is still there

Are the ssh key still there -- show ip ssh

If you can still ping it and the keys are valid , run debug ip ssh and then try and connect to the device and see what the debug shows

[Richard Burts]

I agree with Mark that the Kron job as shown should not have any impact on remote access. When you attempt to telnet or SSH do you get any response (login prompt or can not connect error message) or does the attempt to telnet or SSH just hang? If you can login via console then the output of show line might be helpful.

Is it possible that you have configured exec-timeout 0 on the vty? I have seen this situation and it can result in all the vty being busy with old sessions and attempts to telnet or SSH will fail.

HTH

Rick

[danilopasiani1]

Hi Richard,

When I attempt to telnet or SSH after user and password just hang.

[Richard Burts]

I will repeat my question about whether it is possible that you have turned off inactive session timeout by using no exec-timeout or by using exec-timeout 0?

I will add a request that you connect to the console and get a copy of the running config. It would be nice to see all of the config but if that is problematic post the part of the config starting at line console.

HTH

Rick

[danilopasiani1]

Hi,

I am sending the config from my switching.

line con 0
privilege level 15
logging synchronous
login authentication console
stopbits 1
line vty 0 4
exec-timeout 3 0
privilege level 15
authorization exec rad-author
accounting exec rad-acct
login authentication rad-authen
length 0
transport input telnet ssh
line vty 5 15
authorization exec rad-author
accounting exec rad-acct
login authentication rad-authen
transport input telnet ssh

One thing strange.

• CORE-4500#who

Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
2 vty 1 srv_cisco_ idle 2w4d 10.100.1.211
3 vty 2 srv_cisco_ idle 2w4d 10.100.1.211
4 vty 3 srv_cisco_ idle 2w3d 10.100.1.211
5 vty 4 srv_cisco_ idle 2w3d 10.100.1.211
6 vty 5 srv_cisco_ idle 2w2d 10.100.1.211
7 vty 6 srv_cisco_ idle 2w2d 10.100.1.211
8 vty 7 srv_cisco_ idle 2w1d 10.100.1.211
9 vty 8 srv_cisco_ idle 2w1d 10.100.1.211
10 vty 9 srv_cisco_ idle 2w0d 10.100.1.211
11 vty 10 srv_cisco_ idle 2w0d 10.100.1.211
12 vty 11 srv_cisco_ idle 1w6d 10.100.1.211
13 vty 12 srv_cisco_ idle 1w6d 10.100.1.211
14 vty 13 srv_cisco_ idle 1w5d 10.100.1.211
15 vty 14 srv_cisco_ idle 1w5d 10.100.1.211
16 vty 15 dpribeiro idle 1w4d 10.34.8.4

Interface User Mode Idle Peer Address

• CORE-4500#sh tcp brief
  TCB Local Address Foreign Address (state)
  8D5EC850 10.251.116.162.179 10.251.116.161.59841 ESTAB
  

• I saw that and tried to clear line VTY but I couldn't it.

[Richard Burts]

Thanks for the additional information. It does suggest that the issue is that all of the vty lines are busy, which is what I was aiming at when I asked about exec-timeout. Perhaps the output of show line might have something helpful?

Have you tried to clear individual vty lines? I think there is a way to clear the TCP session which might free up sessions.

HTH

Rick

[danilopasiani1]

I am sending the show line.

CORE-4500#sh line
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
* 0 CTY - - - - - 0 0 0/0 -
1 VTY - - - - - 1955 0 0/0 -
* 2 VTY - - - - - 229 0 0/0 -
* 3 VTY - - - - - 111 0 0/0 -
* 4 VTY - - - - - 72 0 0/0 -
* 5 VTY - - - - - 38 0 0/0 -
* 6 VTY - - - - - 31 0 0/0 -
* 7 VTY - - - - - 16 0 0/0 -
* 8 VTY - - - - - 15 0 0/0 -
* 9 VTY - - - - - 12 0 0/0 -
* 10 VTY - - - - - 7 0 0/0 -
* 11 VTY - - - - - 5 0 0/0 -
* 12 VTY - - - - - 7 0 0/0 -
* 13 VTY - - - - - 3 0 0/0 -
* 14 VTY - - - - - 4 0 0/0 -
* 15 VTY - - - - - 2 0 0/0 -
* 16 VTY - - - - - 7 0 0/0 -

• I did that below and nothing happened

CORE-4500#clear line 16
[confirm]
[OK]
CORE-4500#clear line vty 15
[confirm]
[OK]

It doesn't clear the lines.

[Richard Burts]

Thanks for the additional information. Following up on the show tcp brief what interface is associated with IP address 10.251.116.162? And is this router running BGP on that interface?

Also do you know what (and where) is at address 10.100.1.211?

HTH

Rick

[danilopasiani1]

The IP address 10.251.116.162 is a BGP session.

interface Vlan972
vrf forwarding Partner
ip address 10.251.116.162 255.255.255.252

The IP address 10.100.1.211 is from Cisco ISE.

I can´t clear the session. I would not like reboot the switch core.

[Richard Burts]

Thanks for the additional information. This explains the output of show tcp brief and verifies that this is normal and is not related to your difficulty with SSH and telnet.

I am curious about all the vty being tied up with 10.100.1.211. I am wondering if there might be any possibility that your changes to create the kroon job might have caused some communication to ISE from the switch? Does ISE report any issues with this switch?

HTH

Rick

[danilopasiani1]

Hi Richard,

Unfortunately I had to reboot the switch.

After that the sessions cleaned and the connections are working fine.

Unfortunately I have not found the root cause.

Thanks for help

[danilopasiani1]

Hi,

Just for information,

The problem happened again,

I did upgrade from IOS version 03.05.03 to 03.06.06 and the problem was fixed.

[Richard Burts]

Thanks for posting back to the forum with the update. It is interesting that the problem appears to be a bug in the software.

HTH

Rick

[Joseph W. Doherty]

I think there is a way to clear the TCP session which might free up sessions.

Related global commands to auto clear disconnected TCP sessions:

service tcp-keepalives-in
service tcp-keepalives-out