This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Does the switch log all reboots after either a soft reboot or a hard reboot? Over the last week, the switch was rebooted several times and power was removed a couple times. However, I see only one entry about a Cold Start on October in our diagnostic logs .
We had a power loss event that affected some equipment in the rack and I'm trying to determine if the Netgear switch lost power during this event. Is that possible?
For time storing, it is normal if we don’t write synced time to a persistent storage. For such system, usually it will boot up with date 1970 (Jan 1st) and sync to the current time after software is brought up fully.
I see you have a GSM4230P, I just power cycled a GSM4230UP in my network here using the power button (I switched the power button off, I waited for 6 seconds to let the switch discharge completely, and I switched the power button back on again). After the reboot of that switch, here's what the logs are showing below. You should research log entries with "Cold Start Unit..." after the boot, and with "witch was reset due to power disruption or unexpected restart" at the beginning of the restart/boot:
<189> Dec 18 11:57:08 M4250-UP-1 TRAPMGR[SNMPCfgTask]: traputil.c(814) 388 %% NOTE Cold Start: Unit: 0 <189> Dec 18 11:56:22 M4250-UP-1 TRAPMGR[boxs_Req]: traputil.c(814) 381 %% NOTE Fan state change alarm: Unit: 1 Fan ID: 4 Event: 3 - Operational <189> Dec 18 11:56:22 M4250-UP-1 TRAPMGR[boxs_Req]: traputil.c(814) 379 %% NOTE Fan state change alarm: Unit: 1 Fan ID: 3 Event: 3 - Operational <189> Dec 18 11:56:22 M4250-UP-1 TRAPMGR[boxs_Req]: traputil.c(814) 377 %% NOTE Fan state change alarm: Unit: 1 Fan ID: 2 Event: 3 - Operational <189> Dec 18 11:56:22 M4250-UP-1 TRAPMGR[boxs_Req]: traputil.c(814) 375 %% NOTE Fan state change alarm: Unit: 1 Fan ID: 1 Event: 3 - Operational <189> Dec 18 11:56:19 M4250-UP-1 TRAPMGR[boxs_Req]: traputil.c(814) 370 %% NOTE Temperature state change alarm: Unit Number: 1 Current: Normal, Previous: None <189> Jan 1 00:00:27 M4250-UP-1 TRAPMGR[trapTask]: traputil.c(768) 364 %% NOTE Entity Database: Configuration Changed <189> Jan 1 00:00:23 M4250-UP-1 SIM[DHCPv4_Client_T]: sim_svc_port.c(372) 353 %% NOTE Service port IPv4 address has been set to 192.168.1.11. <189> Jan 1 00:00:22 M4250-UP-1 General[procLOG]: procmgr.c(2723) 344 %% NOTE Administrative Command:app-restart netsnmp <189> Jan 1 00:00:22 M4250-UP-1 IP[ipMapProcessing]: vrf_util.c(1644) 342 %% NOTE Registered IPMAP-0 as a best route callback with RTO <189> Jan 1 00:00:22 M4250-UP-1 General[procLOG]: procmgr.c(2689) 303 %% NOTE Administrative Command:app-start discAgent <189> Jan 1 00:00:22 M4250-UP-1 General[procLOG]: procmgr.c(2689) 301 %% NOTE Administrative Command:app-start RestAgent <189> Jan 1 00:00:22 M4250-UP-1 General[procLOG]: procmgr.c(2689) 299 %% NOTE Administrative Command:app-start AVUI <189> Jan 1 00:00:21 M4250-UP-1 USB_FD[emWeb]: usbFlashDrive_core.c(907) 254 %% NOTE There is startup-config on flash. <189> Jan 1 00:00:21 M4250-UP-1 SIM[emWeb]: sim_util.c(4138) 247 %% NOTE Switch firmware operational: M4250-26G4F-PoE++ 26x1G PoE++ 1440W and 4xSFP Managed Switch, 13.0.4.17, 1.0.0.11 <189> Jan 1 00:00:21 M4250-UP-1 CLI_WEB[ssltTask]: sslt_control.c(1692) 246 %% NOTE Secure HTTP server port changed from 443 to 49152. <189> Jan 1 00:00:21 0.0.0.0-1 TRAPMGR[trapTask]: traputil.c(768) 209 %% NOTE Link Down: vlan 1 <189> Jan 1 00:00:21 0.0.0.0-1 General[procLOG]: procmgr.c(2689) 140 %% NOTE Administrative Command:app-start ping-0 <189> Jan 1 00:00:21 0.0.0.0-1 SSLT[ssltTask]: sslt_cnfgr.c(642) 139 %% NOTE Request to set the sslt admin mode to disable is successfully generated. <189> Jan 1 00:00:20 0.0.0.0-1 General[Cnfgr_Thread_]: l7utils_inet_addr.c(514) 138 %% NOTE INET_ADDR:Invalid FamilyType - 0 <189> Jan 1 00:00:20 0.0.0.0-1 General[procLOG]: procmgr.c(2689) 94 %% NOTE Administrative Command:app-start traceroute-0 <189> Jan 1 00:00:19 0.0.0.0-1 General[procLOG]: procmgr.c(2689) 14 %% NOTE Administrative Command:app-start vr-agent-0 <185> Jan 1 00:00:19 0.0.0.0-1 SIM[Cnfgr_Thread_]: sim_util.c(4196) 8 %% ALRT Switch was reset due to power disruption or unexpected restart.(error[0x0]).
Just thought of something. The switch defaults to SNTP for time. You've been working with us offline about issues with our Management VLAN not being connected (only OOB). If the Management VLAN isn't connected, I'm assuming SNTP wouldn't have worked over OOB. Might that explain the issue? I see many logging statements from Jan 1 (assuming these are logs before SNTP was connected)?
Management VLAN has been up for a couple of days and the SNTP time currently is accurate.
I rebooted again, I see a bunch of log messages from Jan 1, then a cold start message on Oct 31 and then finally two SSL cert logging statements with the correct date/time (I'm assuming this is when the unit was able to sync w/SNTP).
It appears like the local time is logged incorrectly until the unit reboots. Do I need to manually set the system time and then switch back to SNTP to prevent this?
To close on this (any other questions, please email ProAVDesign@netgear.com) and one of the SEs will schedule a call with you to address any other concern! We're here to support you.
If there is internet on the OOB side, then the time is synchronized with NTP too from there (all my switches in my lab are managed through OOB, and they all sync to the right time with OOB right)
When there is a reboot, during the boot there is no time sync yet, the switch lost his time. That's why you see Jan 1st until all services are up, eventually the correct time comes back again when NTP was reached
If you set up a time manually, I don't think it would change anything as during the first 60 seconds of the boot, there is no time yet anyway, either
On the other hand, ignoring the Jan 1st you know that logs are coming "incremental", so any log entry with Jan 1st would also indicate a reboot somehow in the history of logs
The show logging (logs entries in Engage or in AV UI\Maintenance or IT GUI Monitoring) is the same as Memory log (just the presentation is different) - Traps are reflecting the logs too - the severity is the same too
I don't believe a follow up email is needed, I have an explanation of why the Oct 31 and Jan 1 dates show up in the log after reboot.
Just one question, shouldn't the hardware time clock retain the date after reboot and then sync up with the NTP server after it reboots? Or do you consider this working as designed?
For time storing, it is normal if we don’t write synced time to a persistent storage. For such system, usually it will boot up with date 1970 (Jan 1st) and sync to the current time after software is brought up fully.
