× NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Orbi WiFi 7 RBE973

Re: M4300-24x: spontaneous reboots dispite latest firmware

jmozdzen
Tutor

M4300-24x: spontaneous reboots dispite latest firmware

Hi *,

we're running a (until today) single M4300-24x 10G switch, with latest firmware (M4300-24X ProSAFE 20-port 10GBASE-T and 4-port 10G combo, 12.0.2.20, 1.0.0.9). Both with earlierer and current firmware, we have experienced unexpected reboots every few weeks (typically there are about 4 weeks uptime, but I've seen this after two weeks, too).

 

The remote syslog does not report anything special, i.e. the recent reboot (approx Mar 22 15:34):

 

--- cut here ---

Mar 22 12:57:26 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 56609 %% Link Up: lag 10
Jan 1 00:01:11 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 416 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:12 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 417 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:14 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 418 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:15 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 419 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:16 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 420 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:18 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 421 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:46 s-22455-02-05 TRAPMGR[SNMPCfgTask]: traputil.c(763) 422 %% Cold Start: Unit: 0
Mar 23 06:38:36 s-22455-02-05 CLI_WEB[emWeb]: emweb_common_custom.c(162) 467 %% HTTP Session 11 started for user admin connected from 192.168.103.12

---- cut here ---

 

So no pointer either before or after the reboot.

 

There has been no special (network / system) activity around the reboots, nor a pattern we could detect. Nobody was logged on to the switch at the time of reboot.

 

The release notes from 12.0.2.20 suggested that somebody reported similar behaviour: "M4300-12X12F (XSM4324S) - device rebooted itself without any reason, customer wants to know the root cause."

 

Any ideas on how to proceed?

 

Regards,

Jens

Message 1 of 9

Accepted Solutions
DaneA
NETGEAR Employee Retired

Re: M4300-24x: spontaneous reboots dispite latest firmware

@jmozdzen,

 

I suggest you to open a chat or online support ticket with NETGEAR Support then describe your concern and include the logs you have posted for it to be analyzed.  If ever the switch has been declared faulty, be ready to submit a .doc or .pdf copy of the Proof of Purchase or Sales Invoice of it for warranty verification.  Then, if the hardware warranty is still valid, an online replacement will follow. 

 

 

Regards,

 

DaneA

NETGEAR Community Team

View solution in original post

Message 9 of 9

All Replies
DaneA
NETGEAR Employee Retired

Re: M4300-24x: spontaneous reboots dispite latest firmware

Hi @jmozdzen,

 

we're running a (until today) single M4300-24x 10G switch, with latest firmware (M4300-24X ProSAFE 20-port 10GBASE-T and 4-port 10G combo, 12.0.2.20, 1.0.0.9). Both with earlierer and current firmware, we have experienced unexpected reboots every few weeks (typically there are about 4 weeks uptime, but I've seen this after two weeks, too).

 

The remote syslog does not report anything special, i.e. the recent reboot (approx Mar 22 15:34):

 

--- cut here ---

Mar 22 12:57:26 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 56609 %% Link Up: lag 10
Jan 1 00:01:11 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 416 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:12 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 417 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:14 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 418 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:15 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 419 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:16 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 420 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:18 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 421 %% Spanning Tree Topology Change Received: MSTID: 0 lag 1
Jan 1 00:01:46 s-22455-02-05 TRAPMGR[SNMPCfgTask]: traputil.c(763) 422 %% Cold Start: Unit: 0
Mar 23 06:38:36 s-22455-02-05 CLI_WEB[emWeb]: emweb_common_custom.c(162) 467 %% HTTP Session 11 started for user admin connected from 192.168.103.12

---- cut here ---

 

So no pointer either before or after the reboot.

 

There has been no special (network / system) activity around the reboots, nor a pattern we could detect. Nobody was logged on to the switch at the time of reboot.

From the logs you have posted, there might be a loop within the existing network where the M4300-24x switch is connected since there are changes in the Spanning Tree Topology that occured.  

 

Let us isolate the problem.  Kindly answer the questions below:

 

a. How is everything connected?  It would be best that you post an image or screenshot of your detailed network diagram. 

b. On the web-GUI of the M4300-24xz switch, go to Switching > STP > Basic > STP Configuration and check the Force Protocol Version selected.  On the STP Configuration, what is the Force Protocol Version selected?

 

The release notes from 12.0.2.20 suggested that somebody reported similar behaviour: "M4300-12X12F (XSM4324S) - device rebooted itself without any reason, customer wants to know the root cause."

This is one of the fix that should take effect after upgrading the firmware of the M4300-12X12F(XSM4324S) switch to v12.0.2.20.  

 

 

Regards,


DaneA

NETGEAR Community Team

Message 2 of 9
jmozdzen
Tutor

Re: M4300-24x: spontaneous reboots dispite latest firmware

Hi DaneA,

 

sorry for the late reply, I've been on the road.

 

> From the logs you have posted, there might be a loop within the existing network where the M4300-24x switch is

> connected since there are changes in the Spanning Tree Topology that occured.

 

I don't think those are indicators for loops, but rather for actual topology changes (many LAGs across our switching landscape, and servers rebooting from time to time). I guess the reports came from the upstream switch because of the 24X's reboot.

 

> Let us isolate the problem.  Kindly answer the questions below:

>

> a. How is everything connected?  It would be best that you post an image or screenshot of your detailed network diagram. 

 

That'd be too much details ("everything") - concerning the M4300, it's been that single 24X chassis with a two-port LACP uplink to a core switch (via 1 Gbps, it's the LAG 1 you see in the messages) and a number of servers connected to the 24X, again two ports per server, LACP, mostly 10 Gbps, some 1 Gbps links.

 

The -24X basically is a top-of-rack switch connecting dual-attached 10G servers (some still waiting to be upgraded from 1G) to the core switch.

 

> b. On the web-GUI of the M4300-24xz switch, go to Switching > STP > Basic > STP Configuration and check the Force

> Protocol Version selected.  On the STP Configuration, what is the Force Protocol Version selected?

 

Rapid spanning tree (IEEE 802.1w).

 

We now have switched to a dual-chassis configuration (2 pieces 24X side by side), let's see if we still get the reboots. But as these only occur with that multi-week delay, it'll likely be 6 weeks before I report back... if earlier, then because I got another unexpected reboot, which wouldn't be very appreciated 😉 But of course I'll answer any upcoming questions before that.

 

Regards,

Jens

Message 3 of 9
ttrue
Aspirant

Re: M4300-24x: spontaneous reboots dispite latest firmware

Can you download the crashlog from the switch to see what has possibly caused the crash?

The file is usually nvram:crash-log which you can copy via tftp/etc to your pc

 

I believe that bugfix "M4300-12X12F (XSM4324S) - device rebooted itself without any reason, customer wants to know the root cause" was actually a ticket i had opened as i had a couple switches either crash  and reload or crash so remote management was broken.  

 

I was able to see that the crash file contained some information about the LLDP process which is supposedly fixed in the 12.0.2.20 build.  

 

***************************************************
* Start FASTPATH Stack Information *
***************************************************
pid: 627
TID: 0x961df300
Task Name: lldpTask
si_signo: 11
si_errno: 0
si_code: 1
si_addr: 0x58f

 

I should also note that i had to open a new ticket as I ran into issues with openflow when upgrading from older build to the 12.0.2.20 firmware. The fix for this was to disable openflow for now as the case is still being worked on.

 

***************************************************
* Start FASTPATH Stack Information *
***************************************************
pid: 1771
TID: 0x97027300
Task Name: openflowProtoTask
si_signo: 11
si_errno: 0
si_code: 1
si_addr: (nil)
Date/Time: 1/1/1970 0:01:05
SW ver: 12.0.2.20

 

Im curious what your crash log may contain as in my case the issues i have run into all seemed to point to something in the crash log.  That may be helpful for you/support to take a look at that file

Message 4 of 9
jmozdzen
Tutor

Re: M4300-24x: spontaneous reboots dispite latest firmware

Hi ttrue,

 

thank you for taking the time to  respond.

 

> Can you download the crashlog from the switch to see what has possibly caused the crash?

> The file is usually nvram:crash-log which you can copy via tftp/etc to your pc

Instead of that file, I see a directory named "crashlogs"

 

--- cut here ---

(M4300-24X) #dir

1 drwx 3576 Mar 25 2018 15:43:14 .
1049 drwx 0 Nov 13 2017 05:59:32 ..
[...]
72 drwx 160 Jan 01 2016 00:00:01 crashlogs
[...]

--- cut here ---

 

Judging from the time stamp of that directory, it is likely empty - but I've not found a way to verify that.

 

Regards,

Jens

Message 5 of 9
ttrue
Aspirant

Re: M4300-24x: spontaneous reboots dispite latest firmware

I dont think the size of that folder is actually a indicator of the crash.

The switch that crahed for me looks the same way, but he command that downloads the logs grabs the file you need.

 

Here is what mine looks like that crashed.

 

70 drwx 488 Jan 01 1970 00:00:25 crashlogs
1022 drwx 0 Jan 01 1970 00:00:36 ramcp
1003 -rw- 3833 Mar 11 2018 13:15:23 fastpathRun.cfg
76 -rw- 596 Jan 01 1970 00:00:40 hpc_broad.cfg
796 -rw- 495 Jan 01 2016 00:11:14 coredump_log.old
986 -rw- 493 Mar 03 2018 15:18:06 coredump_log.txt

 

 

The file that matches up with the crash time is the coredump_log.txt

 

If you have a TFTP server use the copy nvram:crash-log command to grab that file as it may contain a bit more information on what caused your crash.  The switches I have been using have been good so far with the 12.0.2.20 firmware (I have noticed they have released 12.0.4.8 but it seems to be for the new model and not a lot of fixes that looked important)

 

 

Message 6 of 9
jmozdzen
Tutor

Re: M4300-24x: spontaneous reboots dispite latest firmware

Hi ttrue,

 

it may well be that the core dump is lost because I not only restarted the switch multiple times since the crash, but also turned it into a stack member.

 

>  use the copy nvram:crash-log command to grab

That command succeeds, but leave me with a zero-byte file on the tftp server (access to the file is ok, I double-checked by copying the running configuration to that file). Sounds reasonable, since I have no core dump in my "dir" output, and was the reason I was looking at the "crashlogs" directory in the first place. BTW, what caught my eye was the time stamp, not the size.

 

Seems like I'll have to wait for the next occurence of the problem, if it will happen again at all. Now that I have a redundant stack, rebooting a single chassis shouldn't hurt, so "Murphy" says no spontaneous reboots anymore 😉

 

Thanks again,

Jens

Message 7 of 9
jmozdzen
Tutor

Re: M4300-24x: spontaneous reboots dispite latest firmware

So we've had a number of spontaneous reboots again over the last weeks/months. As we now have a redundant stack, operations aren't affected that much anymore and we usally only find out by looking at the syslog messages.

 

Interestingly, it's always the same switch that is rebooting, stack switch #1, no matter if it is the "active unit" (after power on of the complete stack) or the backup unit (after the first spontaneous reboot of this switch #1, which makes stack switch #2 the "active unit").

 

As I had a confguration issue clobbering the log with it's messages, Iwanted to clean that up first, before reporting back - I now have a clean log, here's what I found for the recent reboot:

 

--- cut here ---

Sep 13 21:27:32 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045333 %% Stack-port link down: Index: 217 Unit: 2 Tag: 0/24
Sep 13 21:27:33 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045335 %% Stack-port link down: Index: 216 Unit: 2 Tag: 0/23
Sep 13 21:27:34 s-22455-02-05 CKPT[tCkptSvc]: ckpt_task.c(363) 1045336 %% Checkpoint message transmission to unit 1 failed for LLDP(85).
Sep 13 21:27:34 s-22455-02-05 CKPT[tCkptSvc]: ckpt_task.c(363) 1045337 %% Checkpoint message transmission to unit 1 failed for LLDP(85).
Sep 13 21:27:34 s-22455-02-05 CKPT[tCkptSvc]: ckpt_task.c(363) 1045338 %% Checkpoint message transmission to unit 1 failed for LLDP(85).
Sep 13 21:27:39 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 1045339 %% Spanning Tree Topology Change Received: MSTID: 0 lag 21
Sep 13 21:27:40 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 1045340 %% Spanning Tree Topology Change Received: MSTID: 0 lag 21
Sep 13 21:27:42 s-22455-02-05 TRAPMGR[dot1s_task]: traputil.c(763) 1045341 %% Spanning Tree Topology Change Received: MSTID: 0 lag 21
Sep 13 21:27:46 s-22455-02-05 CKPT[tCkptSvc]: ckpt_task.c(487) 1045343 %% Backup manager removed.
Sep 13 21:27:46 s-22455-02-05 VOIP[tCkptSvc]: voip_ckpt.c(174) 1045344 %% Backup unit gone
Sep 13 21:27:46 s-22455-02-05 UNITMGR[unitMgrTask]: unitmgr.c(8116) 1045345 %% No Potential unit to configure as Standby when unit 1 left
Sep 13 21:27:52 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045347 %% Entity Database: Configuration Changed
Sep 13 21:28:16 s-22455-02-05 DRIVER[hapiL3AsyncTask]: broad_hpc_rpc.c(1041) 1045348 %% hpcHardwareRpc: RPC Timeout for transaction 6018
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045349 %% Interface 1/0/1 detached from ndesan01.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045350 %% Interface 1/0/2 detached from ndesan02.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045351 %% Interface 1/0/3 detached from ndesan03.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045352 %% Interface 1/0/4 detached from ndesan04.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045353 %% Interface 1/0/5 detached from ndemds01.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045354 %% Interface 1/0/9 detached from compute1.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045355 %% Interface 1/0/10 detached from compute2.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045356 %% Interface 1/0/11 detached from compute3.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045357 %% Interface 1/0/12 detached from compute4.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045358 %% Interface 1/0/17 detached from nde32.
Sep 13 21:28:16 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045359 %% Interface 1/0/18 detached from control1.
Sep 13 21:28:17 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(1014) 1045360 %% Interface 1/0/21 detached from s-22455-02-01.
Sep 13 21:28:22 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045362 %% Entity Database: Configuration Changed
Sep 13 21:28:39 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045364 %% Stack-port link up: Index: 216 Unit: 2 Tag: 0/23
Sep 13 21:28:39 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045366 %% Stack-port link down: Index: 216 Unit: 2 Tag: 0/23
Sep 13 21:28:39 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045368 %% Stack-port link up: Index: 217 Unit: 2 Tag: 0/24
Sep 13 21:28:39 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045370 %% Stack-port link up: Index: 216 Unit: 2 Tag: 0/23
Sep 13 21:28:40 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045372 %% Stack-port link down: Index: 216 Unit: 2 Tag: 0/23
Sep 13 21:28:40 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045374 %% Stack-port link up: Index: 216 Unit: 2 Tag: 0/23
Sep 13 21:28:56 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045387 %% Stack-port link up: Index: 116 Unit: 1 Tag: 0/23
Sep 13 21:28:56 s-22455-02-05 TRAPMGR[spmTask]: traputil.c(763) 1045388 %% Stack-port link up: Index: 117 Unit: 1 Tag: 0/24
Sep 13 21:28:59 s-22455-02-05 CKPT[tCkptSvc]: ckpt_task.c(523) 1045418 %% New backup manager selected, unit 1.
Sep 13 21:28:59 s-22455-02-05 CKPT[tCkptSvc]: ckpt_task.c(423) 1045419 %% Checkpoint operation to backup unit 1 complete.
Sep 13 21:29:06 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045421 %% Link Up: 1/0/21
Sep 13 21:29:07 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045427 %% Link Up: 1/0/5
Sep 13 21:29:07 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045428 %% Link Up: 1/0/10
Sep 13 21:29:08 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045429 %% Link Up: 1/0/9
Sep 13 21:29:08 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045430 %% Link Up: 1/0/12
Sep 13 21:29:08 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045431 %% Link Up: 1/0/11
Sep 13 21:29:09 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045433 %% Link Up: 1/0/17
Sep 13 21:29:09 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045434 %% Entity Database: Configuration Changed
Sep 13 21:29:10 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045435 %% Interface 1/0/21 attached to s-22455-02-01.
Sep 13 21:29:10 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045437 %% Link Up: 1/0/2
Sep 13 21:29:10 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045438 %% Interface 1/0/11 attached to compute3.
Sep 13 21:29:10 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045439 %% Interface 1/0/10 attached to compute2.
Sep 13 21:29:10 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045440 %% Interface 1/0/12 attached to compute4.
Sep 13 21:29:10 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045442 %% Link Up: 1/0/1
Sep 13 21:29:10 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045444 %% Link Up: 1/0/3
Sep 13 21:29:10 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045445 %% Interface 1/0/9 attached to compute1.
Sep 13 21:29:10 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045446 %% Interface 1/0/5 attached to ndemds01.
Sep 13 21:29:11 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045448 %% Link Up: 1/0/18
Sep 13 21:29:11 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045449 %% Interface 1/0/17 attached to nde32.
Sep 13 21:29:12 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045450 %% Interface 1/0/2 attached to ndesan02.
Sep 13 21:29:12 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045451 %% Interface 1/0/1 attached to ndesan01.
Sep 13 21:29:12 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045452 %% Interface 1/0/3 attached to ndesan03.
Sep 13 21:29:14 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045453 %% Interface 1/0/18 attached to control1.
Sep 13 21:29:15 s-22455-02-05 TRAPMGR[trapTask]: traputil.c(721) 1045455 %% Link Up: 1/0/4
Sep 13 21:29:18 s-22455-02-05 DOT3AD[dot3ad_core_lac]: dot3ad_db.c(951) 1045457 %% Interface 1/0/4 attached to ndesan04.
Sep 13 21:29:35 s-22455-02-05 UNITMGR[umWorkerTask]: unitmgr.c(7040) 1045459 %% Copy of running configuration to backup unit complete
Sep 13 21:30:58 s-22455-02-05 STACKING[spmTask]: spm.c(1434) 1045464 %% Errors detected on stack-port 1/0/23 (oldRxErrors = 0 currentRxErrors = 1 oldTxErrors = 0 currentTxErrors = 0). Use the stacking diagnostics command to look at detailed statistics.
Sep 13 21:30:58 s-22455-02-05 STACKING[spmTask]: spm.c(1434) 1045465 %% Errors detected on stack-port 1/0/24 (oldRxErrors = 0 currentRxErrors = 1 oldTxErrors = 0 currentTxErrors = 0). Use the stacking diagnostics command to look at detailed statistics.

--- cut here ---

 

The next message in the log is from Sep 18.

 

The stack is make up of two M4300-24x, connected via direct stack link cables in 1/0/23 and 1/0/24 to 2/023 and 2/0/24. (The reports about errors on these two ports only every appear right after the module reboot, similar to the two last lines above.)

 

LAG 21, reporting the STP topo change, is the redundant uplink to a central switch via 1/0/21 and 2/0/21.

 

The other ports on module 1 that are going down and up are connected redundantly to a server each, with the servers' second link going to the same port on switch module #2, running LACP on the LAG.

 

I collected all switch reports I could get hold of, to our tftp server, via CLI's "copy nvram:..." commands. The crash log is again an empty file, although the CLI command reported a successful transfer. All other files are transfered successfully resulting in "content" on the TFTP server.

 

As it is the same physical switch rebooting, I tend to believe it is a hardware error of some sort.

 

Any idea on how to proceed? Is unit 1 cndidate for a replacement?

 

With regards,

Jens

Message 8 of 9
DaneA
NETGEAR Employee Retired

Re: M4300-24x: spontaneous reboots dispite latest firmware

@jmozdzen,

 

I suggest you to open a chat or online support ticket with NETGEAR Support then describe your concern and include the logs you have posted for it to be analyzed.  If ever the switch has been declared faulty, be ready to submit a .doc or .pdf copy of the Proof of Purchase or Sales Invoice of it for warranty verification.  Then, if the hardware warranty is still valid, an online replacement will follow. 

 

 

Regards,

 

DaneA

NETGEAR Community Team

Message 9 of 9
Top Contributors
Discussion stats
  • 8 replies
  • 3796 views
  • 0 kudos
  • 3 in conversation
Announcements