Intermittent SSH/Telent issue to CISCO

DevilWAH

Hi,

I have this same issue on 2 X 3650C switches.

The config for the VTY lines is identical across all my devices, very basic, using local login and a username / password with privilege 15 access.

I can ping the management address and run SNMP commands to the devices. But since upgrading the IOS 99% of the time I can't get a SSH connections going. I know there are no ACL configured on the switches, and it only happens on two that are running 15.1(1). PAcket capture shows that the switch never replies to the first SYN packet of the TCP stream.

Strange this is that if I reboot the switch SSH will work once. but after that it stops and I can't connect again. I have looked using SNMP and all the VTY lines are free. The real issue is that these switches are in a high bio security building so getting to them is a nightmare. And tonight they jsut wont let me in all I want to do is log in and reboot them back to IOS 12 which was working fine.

Just strange the intermittent nature of it, definitely not duplicate IP's.

networker050184

A bug in your version perhaps?

pevangel

Memory issues? Have you opened a TAC case?

phoeneous

Which ios version?

Which version of ssh?

What happens when you telnet?

What does the log say?

Have you enabled any debugs?

DevilWAH

networker050184 wrote: »

A bug in your version perhaps?

I think this is what it is.

What is particularly annoying is that to get to the switch requires 2 showers and a 3 day quarantine period! that and I can't take in a laptop, or if I do its never coming out!

In the end I realised that after a reboot it will work for one log in if you do it straight away, but leave it 5 minutes or log out and you are stuck again.

Annoyingly the switches do not be default allow reboot via SNMP, so have to pull the configs down, update the snmp settings, then push them back so I could remotely kick of a reload.

Pull config 

snmpset -c prvtcommunity -v 2c 172.18.48.56 1.3.6.1.4.1.9.9.96.1.1.1.1.2.335 i 1snmpset -c prvtcommunity -v 2c 172.18.48.56 1.3.6.1.4.1.9.9.96.1.1.1.1.3.335 i 4
snmpset -c prvtcommunity -v 2c 172.18.48.56 1.3.6.1.4.1.9.9.96.1.1.1.1.4.335 i 1
snmpset -c prvtcommunity -v 2c 172.18.48.56 1.3.6.1.4.1.9.9.96.1.1.1.1.5.335 a 192.168.1.46
snmpset -c prvtcommunity -v 2c 172.18.48.56 1.3.6.1.4.1.9.9.96.1.1.1.1.6.335 s 3560inside
snmpset -c prvtcommunity -v 2c 172.18.48.56 1.3.6.1.4.1.9.9.96.1.1.1.1.14.335 i 1


push config


snmpset -c prvtcommunity -v 2c 172.18.48.56  1.3.6.1.4.1.9.9.96.1.1.1.1.2.337 i 1
snmpset -c prvtcommunity -v 2c 172.18.48.56  1.3.6.1.4.1.9.9.96.1.1.1.1.3.337 i 1
snmpset -c prvtcommunity -v 2c 172.18.48.56  1.3.6.1.4.1.9.9.96.1.1.1.1.4.337 i 4
snmpset -c prvtcommunity -v 2c 172.18.48.56  1.3.6.1.4.1.9.9.96.1.1.1.1.5.337 a 192.168.1.46
snmpset -c prvtcommunity -v 2c 172.18.48.56  1.3.6.1.4.1.9.9.96.1.1.1.1.6.337 s 3560inside
snmpset -c prvtcommunity -v 2c 172.18.48.56  1.3.6.1.4.1.9.9.96.1.1.1.1.14.337 i 1


The last oid element (337,335) is a random number to create a table entry, this will time out after 5min or once completed.


and
snmpset -v2c -c prvtcommunity 172.18.48.56 .1.3.6.1.4.1.9.2.9.9.0 i 2
(will reboot the device)

Once I could log in once, I still ahve the old ISO (version12) on the boxes so just updated the boot variable and reloaded once again. I could not find a way to set the boot variable via SNMP as its no longer part of the running config. Always fun to play with a bit of CLI SNMP though

DevilWAH

pevangel wrote: »

Memory issues? Have you opened a TAC case?

A TAC case?? when I could be having such fun working it out my self

When things need to be fixed ASAP then I raise a TAC, but with this it was not affecting users so learn more by working it out myself.

pevangel

Working it out yourself by asking a forum for help?

I'm just messing with you. I know exactly what you mean.

Have you considered that it might be a memory issue? I had an issue somewhat similar to yours and it was due to a memory leak.

DevilWAH

What I know is that its a bug in that IOS version, or at least it seems to be. Put on version 15.1(1) and I get the isseue, revert to 12.2 and it goes away

Frustratingly all these models of switches are in side high bio-security which makes testing tough. I want to upgrade them so my 802.1x config is consistent across site. but going to have to be very careful with this one.