WS-26-400-AC random reboot

[mhoppes]

I have a WS-26-400-AC that has been in service about 2 months. Yesterday (on a clear blue day) it just rebooted. Power has been confirmed good and stable. Nothing else connected to the UPS rebooted, the UPS does not register any events.

The switch just dropped everything attached to it and shows an uptime indicating it rebooted. It is running 1.4.8.

Any ideas what this might have been?

[sirhc]

The "only" reason it would reboot is power interruption or a loop condition / broadcast packet storm

SUGGESTION - UPGRADE FIRMWARE

Your firmware is WAY out of date - why would you run a 1+ year old firmware?

Use version v1.5.0rc5

FIXED/CHANGED
- Fixed I2C service to deal with errors better to prevent reboots with WS-12-250-DC and WS-26-500-DC - RC2 & RC3
Note: The attempt to fix I2C in RC2 was a failure and caused worse issues.
It was rushed out too fast with not enough testing.
If you downloaded v1.5.0rc2 DELETE IT AND NEVER USE IT AGAIN
We spent almost a week testing the I2C in RC3 and feel we got it right this time.

- Fixed sending CDP frames tagged with VID 1 if the management VLAN is not VID 1 - RC1
- Fixed SNMP walk failing if VLANs are not in numerical order - RC1
- Fixed using hash mark in SMTP password - RC1
- Fixed using hash mark in RADIUS password - RC1
- Fixed issues with Loop Protection on SFP ports - RC1
- Fixed intermittent telemetry error on Device/Status TAB mostly seen with WS-26-500-DC - RC1
- Fixed power TAB where shutdown time set to 12 AM would immediately turn off poe on that port - RC4
- Fixed ST/RSTP bridge priority change would not update properly - RC4
- Fixed cli issue on ws-8-150-dc model's now allowing one to set the power restart/shutoff from cli - RC5
- Fixed scheduled portbounce to no longer trigger unexpected link status change email - RC5
- Extended length for URL resource for SMTP recipient address - RC5

ENHANCEMENTS
- Optimized code to reduce CPU utilization especially needed for the WS-26-500-DC - RC1 <= CRITICAL
- Changed watchdog to wait for Startup + Interval seconds before checking again after watchdog is triggered - RC1
- Added log entry to report if the switch rebooted due to watchdog timer - RC1
- Added lldpRemPortId, lldpRemPortIdSubtype, and lldpRemPortDesc to LLDP-MIB - RC1
- Added cdpCacheDevicePort to CISCO-CDP-MIB - RC1
- Added popover for POE enabled ports on 'Watts' column to show power usage on each pair for VH ports - RC1
- Added root bridge id to STP log message - RC1
- Added Low Voltage notification for DC model's to contain the threshold and the present value in the log/email - RC5
- SNMP Contact and Location character limit increased from 26 to 255 characters - RC4
- Improved the units ability to deal with network loops while loop protection, flow control, and STP are disabled to not cause unit to reboot - RC5

KNOWN ISSUES
- WEB UI issues when not at 100% Zoom on browser especially on VLAN TAB
- Some language templates need help - please private message Eric Stern to help
- IGMP snooping over VLANS, MSTP, and ERPS are still being developed

RC1 Released 3/19/2018
RC2 Released 3/22/2018
RC3 Released 4/3/2018
RC4 Released 4/30/2018
RC5 Released 5/25/2018

[mhoppes]

I have a few switches running 1.1.8 :) Uptime sometimes demands not installing updates.

That being said - why would a traffic loop cause a switch to reboot?

Thank you for posting a suggestion to update WITH the reason why an update might fix the issue. Too many times vendors just say "Update" as if that might solve any random issue.

[sirhc]

It gets very complicated but MOST managed switches not just ours will reboot during a loop as it causes MILLIONS of packets per second to be sent to the linux shell running the UI/CLI and the watchdog which forces a reboot as the small cpu gets overwhelmed and can not respond to the watchdog in the core so the core thinks the shell is locked up.

[mhoppes]

Ok. So why are the ports losing power during the reboot? Wouldn’t a software reboot just take down the core?

[sirhc]

Ok. So why are the ports losing power during the reboot? Wouldn’t a software reboot just take down the core?

Matt I have no idea, did you upgrade to v1.5.0 which prevents a reboot from a loop broadcast storm?

Normally in situations like this at my WISP I like to eliminate as much as possible in as few steps as possible.

If I was you I would:
Upgrade to v1.5.0 which should eliminate a loop broadcast storm as the cause.
If problem still there swap switch out with spare.
If problem goes away then RMA old unit but if problem is still there then your down to possibly someone gaining or trying to gain access to switch so setup a SYSLOG server to see if someone is messing with the switch by reviewing logs.

You can also setup the Access Control List to limit what IPs can talk to the switch.

The switch will power down and back up POE ports from a cold boot. I just posted the other day that every so often even a designated reboot from say a firmware upgrade will think it is a cold reboot and power cycle the POE ports. We know it is there and can happen very infrequently but have never been able to figure out why but it is currently low on the priority list as it happens so infrequently and is hard to replicate and there is no serious adverse effects other than a longer boot time.

I talked about it here: viewtopic.php?f=17&t=3837#p24575