Unresponsive GUI or SSH

[dwebster]

We purchased 5 brand new ws-250-DC's out of the 3 we have used, we are getting an unresponsive GUI or ssh access every few days. We have 30+ major distribution sites and only the last three on 1.5.5 are having these issues.
There are five ports being used, 3 48v HV for Mimos A5c's and one for fiber and one copper as a backup to the fiber that is disabled unless needed.
The odd thing is that I've noticed it only happens when the Mimosa's are connected at gigabit, there are no errors on the port but if I set them to 100mf-auto it seems fine and the switch then become responsive, i know when it's happening because typically one of the A5C's will go offline but the port shows up when i can get in. It isn't the fiber because i've tried the copper port as well and it was tested on the tower prior to being hooked up and the netonix typically pings all while this is going on. We are using a Tycon Power systems controller for DC power and they are hooked up to the load side at 48volts. Has anyone seen this happening with these switches?
Should i downgrade the software, anyone have previous software anyone have a link to 1.5.1 or anything in the high 1.4's, since i can't find it on the forums?

[Stephen]

I can post a link to try downgrading if you wish but we really try to avoid that because security patches/maclist's etc are updated on every update.

Can you try having these switches point to a syslog server to log what might be occurring during these spurts of inaccessibility?
There's not much I can do without more information.

[dwebster]

Is there a way to look at this through the logs on the device or the log interface doesn't show syslogs and connecting it to a syslog server is a must?

[Stephen]

No not necessarily you can easily see the switch logs by going to Device->Logs tab sub menu in the web UI.
Or you can ssh in or use an rs232 serial port to check the logs with the command 'show logs' or watch them live by dropping into the linux shell and tailing the log via:

Code: Select all

cmd
tail -f /var/log/messages


I was suggesting a syslog server because just because you've lost access to the switch's administration console doesn't mean the switch can't access the syslog server and it might be easier to correlate what's going on in the switch during the time's when access has been lost.

But when you get access back you should still be able to see the log history.

[dwebster]

I only loose the interface when the devices are connected at a gig in ports 1-4 on 3 switches, if you would like remote access i can get you connected via my laptop. Currently i have two devices connected on ports 9 and 11 with no issues at a gig, but these are brand new switches and have never seen this issue on any of our other towers except again the new deployments/the last batch. We have 1 of 4 switches we installed in this batch working and have had zero issues with, every single location is the exact same.

admin@Tower_Netonix_-_Ramrod:/www# tail -f /var/log/messages
Apr 22 11:52:39 UI: Configuration changed by admin (::ffff:162.251.179.10)
Apr 22 11:52:39 UI: Port 3 Name: changed from 'A5C Omni Old' to 'Port 3'
Apr 22 11:52:39 UI: Port 4 Name: changed from 'Bad Port' to 'Port 4'
Apr 22 11:52:39 UI: Port 9 Name: changed from 'Port 9' to 'A5C West'
Apr 22 11:52:41 syslogd exiting
Apr 22 11:52:42 syslogd started: BusyBox v1.19.4
Apr 22 11:52:48 UI: Configuration changed by admin (::ffff:162.251.179.10)
Apr 22 11:52:48 UI: Port 4 Link: changed from '100M-Auto' to 'Auto'
Apr 22 11:52:50 syslogd exiting
Apr 22 11:52:51 syslogd started: BusyBox v1.19.4

[Stephen]

Well if it has something to do with the configuration probably the best way for me to check would to have the config file and to load it onto a switch in my lab to see if I can replicate the behavior. Would you mind PMing me a backup of one of the offending switches? (if there are any access credentials, please set them back to admin, admin so I can access the internals)