NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
WojtekC
Jun 16, 2019Guide
M4300 VLAN routing interface gets down with stack master
My simplified lab setup is two M4300-12X12F, stacked up. All ports, except stack ones, are set as follow: interface x/x/x
switchport mode trunk
vlan acceptframe vlanonly
vlan ingressfilter
exit
T...
- Jun 16, 2019
I've have some issues on a mixed stack of 1x M4300-12X12F (same as yours) and a M4300-52G-PoE+ with this firmware version where initiating a failover between master and standby master (configure; stack; initiate failover) would render a stack management inaccessible. Although not exactly the same thing, a manual failover or a power off event on the master leads to the same situation where the standby master will take over the stack master role.
Could you check that when you initiate a failover like me that the new master has some ports in DETACH state when you issue the 'show port status all' command? If you lose access over SSH, try the serial console, it remained working in my situation.
I'm currently working with Netgear on an issue with this specific version and testing a beta release after they have done some preliminary testing internally. I don't do any inter-VLAN routing on the M4300's so my use case is not entirely compareable to yours, additionnaly this only happened on that mixed stack but not on another stack with 2 M4300-52G-PoE+'s.
If you see the same behaviour load 12.0.7.10 into the other firmware bank and start it. In my case failover was still rather slow and causing some packet loss, but overall working. If things are similar I could send you my case number in private so you could point the Netgear support to potentially give you access to that release. (I am not permitted to do so by the beta agreement which I had to accept for this support case)
msi
Jun 16, 2019Luminary
I've have some issues on a mixed stack of 1x M4300-12X12F (same as yours) and a M4300-52G-PoE+ with this firmware version where initiating a failover between master and standby master (configure; stack; initiate failover) would render a stack management inaccessible. Although not exactly the same thing, a manual failover or a power off event on the master leads to the same situation where the standby master will take over the stack master role.
Could you check that when you initiate a failover like me that the new master has some ports in DETACH state when you issue the 'show port status all' command? If you lose access over SSH, try the serial console, it remained working in my situation.
I'm currently working with Netgear on an issue with this specific version and testing a beta release after they have done some preliminary testing internally. I don't do any inter-VLAN routing on the M4300's so my use case is not entirely compareable to yours, additionnaly this only happened on that mixed stack but not on another stack with 2 M4300-52G-PoE+'s.
If you see the same behaviour load 12.0.7.10 into the other firmware bank and start it. In my case failover was still rather slow and causing some packet loss, but overall working. If things are similar I could send you my case number in private so you could point the Netgear support to potentially give you access to that release. (I am not permitted to do so by the beta agreement which I had to accept for this support case)
WojtekC
Jun 17, 2019Guide
After powering off stack master (unit 1), all ports was fall into Detach link status, no matter connected or not.
After powering unit 1 back (is no longer stack mater of course), all ports on it was back to Up or Down status.
But on unit 2, now stack master, all ports are still in Detach link status, and still properly worked in layer2.
- msiJun 17, 2019Luminary
Interesting. In my case losing the L2 connectivity to the switch was not always happening, like more after the second or third failover in my case. Could do a 'initiate failover' instead of powering down a switch? (to be closer to what happened to me, this could help Netgear support*) and then try the same on 12.0.7.10 to see if it doesn't happen on that release?
At that point I can't tell 100% if 12.0.7.12 is affected as well, but Netgear and I were both able to confirm that failover, albeit rather slow, would definitely work on 12.0.7.10 but does have issues in certain combinations on 12.0.7.15. The beta release I'm testing looks like it improves both failover stability and failover time overall, but I have only enabled it since a couple of days.
- WojtekCJun 17, 2019Guide
I downgraded firmware to 12.0.7.10 as You suggested, and everything works fine.
No mater if i do "initiate failover" or powering off the switch, VLAN ip interface still works as expected, after couple failovers.
Thank You for help.
After going back to 12.0.7.15 and "initiate failover", everything is the same: port are still detached on management unit, and vlan ip is down.
- msiJun 17, 2019Luminary
Good to hear WojtekC - I couldn't have helped if I hadn't run into the very same issue 2 weeks ago.
For other readers: It seems to be a bug applying only in certain specific combinations of M4300 models stacked together and running 12.0.7.15, but not all are affected by this bug. If you are affected by this, downgrading to 12.0.7.10 seems to be a viable workaround as of writing.
I can say that I have been positively surprised by Netgear's L2 and L3 support while working with them on this issue and can tell that they have done a good job at analyzing and pinpointing and reproducing this particular issue. Based on that it looks like a matter of time when a next firmware release should be published, that includes a proper fix.
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!