Reboot events in logs?

[psda]

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?

[LaurentMa · Accepted solution]

I verified and it's 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.

[LaurentMa]

Hi @psda ,

I am sorry for the late response here, looks like we missed your post. I can tell you that all reboots are logged, all the time.

[psda]

Hi @LaurentMa 

Which log(s) track the reboots?

[LaurentMa]

Hi @psda ,

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]).

[psda]

What switch logging level do I need to be at?  I see the cold start logging statement in October of 23, but no reboots are tracked since then.

[LaurentMa]

Default should be OK, the severity is:

• Behavior: Wrap
• Severity filter: Notice

If you don't anything since October, it would mean "no reboot since then"

[psda]

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.

[psda]

Also, should I be looking at the memory log?  Does this equate to the log in the AV UI?

[psda]

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?

I see in your log  lots of Jan 1 times also.

[LaurentMa]

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.

1. 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)
2. 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
3. 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
4. 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
5. 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

[psda]

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?

[LaurentMa]

Please stand by until I verify it's WAD or not

[LaurentMa · Accepted solution]

I verified and it's 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.