Reply
sconnary
Follower

M4300 - Firmware Upgrade = Code Mismatch = Packet Loss

Model: Netgear M4300

Firmware: Image 1 - 12.0.11.16 (running)

                 Image 2 - 12.0.11.18

 

Is there any way to upgrade firmware without incurring packet loss?  Every scenario I try ends up with 40+ seconds of packet loss.

 

If you upgrade the standby it results in code mismatch which prevents you from being able to intitiate a failover.  You then have to reboot the master to upgrade it and the result is 40+ seconds of packet loss.

 

Am I missing something?

 

I can provide more detail if required.

 

Thanks in advance,

 

Scott

 

 

Model: XSM4348CS|M4300-48X - Stackable Managed Switch with 48x10GBASE-T
Message 1 of 2
msi
Luminary
Luminary

Re: M4300 - Firmware Upgrade = Code Mismatch = Packet Loss

Hi

 

I guess you are looking for the staged upgrade procedure as outlined by @LaurentMa in the following thread:

https://community.netgear.com/t5/Managed-Switches/M4300-for-iscsi-storage/m-p/1570701

 

This involves a reboot of first all slave members, wait for them to come back with code mismatch then the backup master (same, wait until it is up but with code mismatch), and finally the current stack master. Until old stack master is rebooted, the other stack member ports will remain down, but will come back up once the former stack master goes rebooting while the backup master gets (within seconds later) promoted as the new stack master.

 

From my experience: Do practise this method, so you know how it behaves when you need to do do this. There is a reason why it is not the default upgrade method outlined by Netgear. I've done it now a couple of times on our server stack and core with M4300's but continue with standard full reboot in stacks that are user-facing. It's not perfect, but I can confirm that it works as described. However I always deploy new releases first to less-important stacks first, before updating i.e. the core stack with this staged reboot method.

 

You'll need to check the currently-configured behavior using "show auto-copy-sw". I honestly don' remember exactly, but you need to make sure the stack doesn't allow automatic downgrades. Otherwise the stack master will try to force-sync the running (old) code.

 

From my experience the overall failover time has improved and become quite more stable compared to early firmware releases, definitely way less than 40+ seconds as you currently experience. However: The lower the number of ports from my experience, the faster the failover from the old to the new stack master.

 

For a side node: Even somewhat competing products with stacking, such as HPE/Aruba 2920/30 or Cisco 3850 couldn't do sstaged upgrades for what I've researched. If you cannot afford any ever-so-small downtime within a LAG during an upgrade - unfortunately - the only product I'd see it within Netgear's offering, is the M4500: These don't do stacking, but multi chassis link aggregation groups (MLAG).

 

MLAG or even higher-end functionalities things like in-service system upgrade is unfortunately often still only found in a pricing realm way above the M4300's and often reserved to datacenter switches. Even the M4500's which are definitely competitively priced compared to other products in their respective space, is quite a bit more expensive compared to even the big M4300-96X.

Message 2 of 2
Top Contributors
Discussion stats
  • 1 reply
  • 41 views
  • 1 kudo
  • 2 in conversation
Announcements