MR 32.1.2 Beta Release Out - Just a few fixes/changes

[Mloraditch]

New feature

• Local firmware fetch for MRs to reduce WAN consumption during firmware upgrades
• Support for DHCP Option 82

Important note

• MR45/55 APs are not supported on MR 32.x.x and will instead upgrade to the backup version (MR 31.1.7.1) if they are in networks configured for MR 32.x.x versions, and thus, new features will not be available.

Bug fixes

• General stability, performance, and experience improvements
• Dashboard channel utilization incorrectly reported above 100% (Wi-Fi 7 APs)

[cmr]

This is a good idea for larger networks:

• Local firmware fetch for MRs to reduce WAN consumption during firmware upgrades

[thomasthomsen]

But no mention, as far as I can see, how it works.

Is it like the 9800 efficient image upgrade where three subordinate APs (of the same "model) can download simultaneously from the primary ? And can you select the primary ? Can I turn it off if my sites have "enough" bandwith ? so many questions 🙂

[Mloraditch]

You think someone could learn to hit publish on the firmware and the documentation link at the same time...

[thomasthomsen]

😂

[cmr]

1. I'd guess so
2. I'd guess not
3. Meraki simple

😉

[PhilipDAth]

How does "Local firmware fetch for MRs to reduce WAN consumption during firmware upgrades" work?

Does one MR download it from other MRs?

[cmr]

I'm guessing that it is a bit like Windows 11 PCs downloading updates from each other locally, so yes!

[MinseK]

Indeed what most of community member's thinking is true. it allows local, p2p distributions of MR firmware. network will automatically elect AP Firmware server and AP Firmware client will make a request to server to download the firmware from local network. it will significantly improve the FW upgrades time on both large network as well as network with restricted WAN Bandwidth. full documentation is coming soon.

[Blue_Bird]

Exellent..! and Thanks for the updates..!

[NicolasRen]

Sounds great ! It's an important feature for massive networks. By the way, I don't know why I was thinking it was already the behaviour, maybe confusing with switches...

[JamesBalchin]

I saw the doc (https://documentation.meraki.com/MR/Deployment_Guides/Pre-download_with_Local_Firmware_Fetch) before I even saw the release.

Seems like a great idea to me.

[BaskaranGanesan]

I didn't see any bug fix for roaming between 6 and 5 / 5 and 6 on the same AP with different radios.   6E is causing more impact on the client roaming in the low-density area.  

[cmr]

@BaskaranGanesan are you saying that a client roaming between radios on the same AP is a bug?  I get this a lot, but as it is down to the client to decide if it wants to roam, unless you enable band preference, I'd expect that to happen.

[BaskaranGanesan]

I have tried all options, but clients are still roaming between the radio and the same AP. Its if single AP works fine.  When it comes to mesh networks, they are creating a huge impact. 

Are you seeing any 

[MinseK]

Do you have any meraki support case open?

typically, client likes to join 6GHz, if 6GHz broadcast higher connection speed. (e.g enable 80MHz or 160MHz Channel width) even when 6GHz RSSI is much lower. than 5GHz.
one idea is reduce the Channel width of 6GHz, matching with 5GHz.  and you can apply higher TPC range (min-Max), so you can make sure 6GHz has similar SNR as 5GHz