Meraki

NolanHerring · ‎Mar 14 2024

Ugh, double correction here. My actual testing was at my office which is still 28.7 MR44. The new site is 30.6 with MR44, but I haven't been able to test that yet in person, but I would suspect the same results.

NolanHerring · ‎Mar 14 2024

I forgot to mention I'm on MR44 with 30.6 code. Yeah I'm honestly really hoping it was just the stupid PMK Caching being set to NO on the Intune profile. Otherwise I suppose I could at least use 802.11r Adaptive (instead of Enabled) since that is suppose to only use 802.11r for Apple devices, but if its anything like their OS detection then maybe not lol. That is hit or miss.

NolanHerring · ‎Mar 14 2024

So I'm just now starting out testing with our Intune Windows 11 (23.30.0 ax211) and iPad is able to do roaming with 802.11r just fine. I also have 802.11w enabled, since iPad and these Dell laptops both say they support 802.11r and 802.11w, so figured why not. The Windows laptop was having hard disconnect, so basically no roaming when I was testing. Logs showing EAPoL timeout and Invalid PMKID. Using EAP-TLS local auth option. I just discovered though that the wireless Intune profile doesn't have PMK Caching enabled, so getting that fixed and will test again. Hoping that was the issue. Disabled 802.11r and 802.11w and client roams fine (not fast roaming, but better than a no-roam scenario lol). Will need to test with 802.11w on/off as well to see if that is causing any issues, since I saw it mentioned above in this thread.

NolanHerring · ‎Mar 13 2024

Not sure if it helps but I found an article since this is all technically new with 18.208 https://documentation.meraki.com/MX/MultiWAN_Backup_Uplink

NolanHerring · ‎Mar 13 2024

When you say not stable, do you mean because it is a 'stable release candidate' and not under the 'stable' column, or do you mean the firmware is buggy and has lots of issues and its not 'reliable/stable' in that regard.

NolanHerring · ‎Feb 23 2024

28.7 vs 28.7.1 should have no impact or difference on the MR44 since the release notes (changelog) for 28.7.1 indicate the following: New This release adds support for MR28, CW9164 and CW9166. Bug fixes There are no bug fixes included in this release.

NolanHerring · ‎Feb 23 2024

Bless your heart! The new wireless access points page is simply terrible, it literally makes me want to find another vendor its so frustrating.

NolanHerring · ‎Feb 22 2024

Definitely get a case opened to track this first and foremost. I was going to say go to 30.6 as I know that version has tons of bug fixes, but looks like you already did. My personal 2 cents here, is stability > features. I'm pretty much running 28.7 for all MR44's because its been rock steady and stable. I honestly could care less about fancy features, if the code isn't stable, I'm not interested. Nothing quite like unstable firmware code to make you look incompetent to the business, been there done that and it's stress I never want again. I would downgrade to 28.7 for production environments (or whichever stable version you were on before), and then have that case opened and an engineer to work with you directly via a lab environment with 30.6 and get PCAPs and figure out what's what, and until you have a fix, hold off on upgrading.

NolanHerring · ‎Feb 22 2024

I see 18.208 is out but I've not been able to test to see if the issue is resolved or not.

NolanHerring · ‎Feb 16 2024

Ok and now I'm officially upset. I just noticed that the wireless page (switch still seems to have old version available to revert to) is forcing the new view. IT IS HORRIBLE...who approved this? ALL of the complains that @Alexander3 I am also seeing. Sorting is broken Can't scroll right without having to scroll all the way down and back up again Why do I have to scroll right at all when the old version didn't have to? @Ryan_Miles @CarolineS - Can you guys PLEASE slap some sense into whoever is in charge of the dashboard because they clearly are not actual users of it.

NolanHerring · ‎Feb 8 2024

Sounds good, appreciate the assist. I never would have noticed it had I not happen to be PCAPing for another issue, so it was luck that I stumbled across it.

NolanHerring · ‎Feb 8 2024

Oh and the Case I had opened, the engineer confirmed this is a known issue and its already being tracked.

NolanHerring · ‎Feb 8 2024

So if I run a PCAP from the MG51 LAN, all traffic is coming from the static IP on either FW1 or FW2. Not the VIP. If I look at the ARP table, the VIP doesn't exist. If I downgrade firmware to 18.107.X - Then I do see the VIP on PCAPs and ARP table. That's basically all I have to verify if its working or not. It's currently remote so I'm not able to do any actual fail-over testing but I would expect results to not be as quick as if the VIP is functional. Also not sure if this is specific to MX85 hardware or not.

NolanHerring · ‎Feb 8 2024

Single in the sense that the MG unit only has a single power source. If that switch goes down, the MG goes down with it. Similar to if it is connected to dual MX. If the MX providing power goes down, so does the MG.

NolanHerring · ‎Feb 8 2024

Yeah I mean in that specific example its basically just transferring the single point of failure from whichever MX happens to be providing PoE, to the switch that is providing PoE. If the switch has dual-PSU then it might make more sense vs having it connected directly to the MX that doesn't. Unless I'm missing something?

NolanHerring · ‎Feb 8 2024

Confirmed on another thread by another Meraki employee (and a case I opened) that MG unit only support a single PoE source at a time. Data can be dual, but not PoE.

NolanHerring · ‎Feb 8 2024

Just an FYI to others, but I have dual MX setup (primary/warm-spare) and I use a VIP on both my WAN1 (DIA) and WAN2 (MG51 cellular) connections. VIP function works on 18.107.2, but upgraded to 18.207 and VIP function stopped working. Only noticed because I happen to be running PCAPs to test something else, but also confirmed via ARP table on MG51 not showing the VIP anymore. Downgraded, and PCAPs and ARP both showing correctly.

NolanHerring · ‎Feb 8 2024

Got a reply on another thread from Meraki employee (and confirmation via case I opened) that the MG unit can only have a single PoE source for power at a time. LAN can be dual, but not PoE.

NolanHerring · ‎Feb 8 2024

I figured as much. Thank you for the information. Do you know if there's any plans for adding that in the future? I assume its simple not possible but figured I would ask lol

NolanHerring · ‎Feb 8 2024

@Ryan_Miles Is there any documentation regarding Warm-Spare designs with using the MX85 WAN ports for PoE? I have a single MG51 setup, both LAN ports on it are going to the WAN2 ports on the MX85 (primary and secondary). Only one port ever gets PoE, and so when that FW goes down, the MG51 goes down with it until the other connection from the other FW kicks in and starts to provide PoE. Not ideal, because it causes a 3-5 min outage while waiting for the MG51 to boot back up (or however long it takes). Opening a support case now to figure this out. Would be great if both WAN2 ports were able to provide PoE at the same time so there is no outage created.

NolanHerring · ‎Feb 8 2024

Have you had any luck with these during fail-over @KarstenI ? I have an MG51 plugged into WAN2 on FW1 and FW2 (warm-spare) and only one of the WAN2 ports ever provides PoE. When the FW that is providing PoE goes down (reboot or whatever), the MG51 loses power, and then PoE on the other FW kicks in. So there is an outage that really should not exist given the physical redundancy, which is upsetting.

NolanHerring · ‎Feb 8 2024

So I'm discovering now that the LAN ports on MG51, when connected to two MX85 WAN ports, only one port gets PoE. So if FW1 dies, and its the one providing PoE to the MG51, the second connection (which is up) to FW2 doesn't have PoE, so the MG51 goes down. Any way to get dual-PoE from the WAN ports to both LAN ports on the MG51? So there is no outage created.

NolanHerring · ‎Feb 2 2024

I see it now via DHCP Servers & ARP settings, however I'm not sure its working. I have it set to block ALL IPV6 DHCP servers, but my switch is still getting an IPV6 via the ISP device. I have it routing through the switch first via transit VLAN so that I could split it off from there to go into WAN1 on both primary and spare MX units since I only have one physical hand-off from the ISP.

NolanHerring · ‎Jan 30 2024

So I can't imagine there actually being any real 6GHz usage around you, so I would suspect cosmetic bug. The spectrum and channel utilization is nice but it has a history of being unreliable. https://nolanwifi.com/2017/02/02/meraki-rf-falsehoods/ As for the MAC, I don't see 6GHz mentioned on this document, but I suspect its MESH https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Calculating_Cisco_Meraki_BSSID_MAC_Addresses

NolanHerring · ‎Jan 23 2024

Thanks for bringing this issue to our attention.

About NolanHerring

NolanHerring

Nolan Herring

Community Record

Badges