We've upgraded about 25 switches to this FW. Some of which reboot as soon as the FW is uploaded, others wait for us to hit reboot. This is horrible behaviour 😕
Wanted to like these switches, but the stacking is just terrible, can't trust it, moving to Cisco.
Model: XSM4324S|M4300-12X12F - Stackable Managed Switch with 24x10G including 12x10GBASE-T and 12xSFP+ Layer 3
Yes, we just removed 12.0.15.4 from M4300 download pages because despite our full regression testing (like all new firmware images) we noticed some issues in M4300 stacks in the field. We are working very hard on it as we speak, and we hope to release this new firmware (bringing Auto-Trunk, Auto-LAG, and many security enhancements) as soon as possible.
For the time being, please revert back to 12.0.13.8 for your M4300 stacks.
If you need any support or share your comments, or even discuss with me directly, please never hesitate to contact us/me sending an email to ProAVDesign@netgear.com
I will come back to this thread and comment on the new firmware as soon as it is available.
We are encountering several issues, mainly stability issues with units in the stack rebooting. We have removed this firmware from the publc website and we are working actively on a fix before reposting this maintenance release. It seems it pertains to the 1G models (GSM series in M4300, mainly). 10G models (XSM series) seem not impacted. Again, we should revert to previous firmware when possible, until we come up with a fix and new maintenance release for 12.0.15.x
the only 1G models I have (m4300-52g) , do not have this firmware v12.0.15.4 yet (they are way older than that), so i'm good i believe and will only go for now to v12.0.13.8 on these ones.
Was there a pattern in uptime for unit reboot or fully random ? i'm not sure root cause has been identified yet, helping preventing it
regarding the X ones (10G interfaces), is this compulsory to downgrade to v12.0.13.8 ?
or leave it as is and keep ass tight until next firmware is coming later in Dec/Jan.
Also, i believe that such an event (1 every 3y or 5y ?) would require a proactive client email communication sent to all registered units / email base .
I will update this thread when we have fresh and good/better news. The NETGEAR Tech Support organization is fully aware, handling all customer requests about it.
No pattern on the issues other than some units sometimes rebooting inside the stack (not the whole stack). We are fixing it, this is highest priority here. Only the GSM models seemed affected, I repeat, the XSM models aren't. If you stacks with only XSMs, this is OK to keep this version. If you have some GSMs in these stacks, better to revert back to a previous image until we publish a new updated version - this is highest priority and I'm sure we will deliver asap this month, in December.
Thank you @LaurentMa for your transparency and for pulling this firmware from the downloads. While annoying it was the correct decision to pull it until you understand the problem and have a proper fix. Good luck on the engineering team finding and fixing the root cause!
I can confirm the stability issues since I usually do some "canary testing" with new firmware releases on a non-core stack ahead of planned maintenance windows. We've been bit by a crash yesterday on a pair of 2 stacked GSM4352P's running 12.0.15.4 likely related to your findings. (The firmware has been running since end of october on a pair of stacked GSM4352P, usually a good sign.)
Some observations for comparison:
Both stack members had the stack master LED enabled
Remote management was gone (no ping), but serial console was responsive on both members
Devices connected to the stack master had a working connection, those connected to the standby master did not.
Standby master was not willing to converge with the stack even after a reload of (just that) member
Switching back to the backup firmware was not reacting form the working OS on unit 2 (serial console) I had to enable booting from the backup firmware from the boot loader. (No problems on the stack master)
Booting both members back to the backup image fixed the issue and the stack readily converged again.
Just as a idea for improvements: If you pull a firmware version from the downloads section it would be helpful to add a note to the download section that it was retracted or deferred. I was only made aware of these issues after the crash has happened and then I saw that the latest downloads was back to 12.0.13.8 to only then stumbled upon this thread. 🙂
Thank you for the insights. I can tell you the Engineering team is fully committed and we are making huge progress every day. This is our highest priority for M4300.
I agree with you with a KB note in download section of the firmware page, indicating if one FW version was retracted and why.
Again I will report here in this thread when we have good news. Thank you,
We have had it on a 10G XSM only stack. It's a 4 x XSM4348S stack with ver 12.0.15.4. Random reboots/warm restarts of individuals in the stack. Can be 2 or more weeks apart. Other units in the stack will then reboot within 24 hrs and the whole stack becomes unresponsive and requires a full power cycle.
Model: XSM4348S|M4300-24X24F - Stackable Managed Switch with 48x10G including 24x10GBASE-T and 24xSFP+ Layer 3
Thanks for posting a banner in the M4300 downloads section, that definitely helps avoid anyone else stumbling into this trop. Please keep us posted on the progress, it seems like a "not so easy" bug considering a 12.0.15.x could not be re-released that easily with "just"[1] the other fixes except for the change that eventually lead to said crashes.
[1] I am fully aware that sometimes "simply" identifying the source of the problem can be one of the hardest things.
