Did a support ticket ever get opened on this? ... View more

We use MR44s or now CW9162s in low density mobile areas (such as corridors and fire escapes) so the 4:4 would not make any difference.  At the moment neither will the 6GHz for 99% of devices, but I'm sure it will get used in the future... ... View more

Did you find a solution ? Did you ever get it to work ? ... View more

Did anyone ever get a Cisco AP in WGB mode to connect (and forward traffic) to the equipment behind it ?   ... View more

I think the documentation makes fine sense for adding licenses, but the renew part could use a little "work" with a specific example not just involving the same device type (in the example on that page its just APs).   And I agree, you could actually use the license calculator for this, its just .... ehh ... not that friendly to use, especially if you have many licenses and times to take into account . A really nice feature request here would be to be able to use the license calculator on an already existing org (with the current licenses already put into it). - That would be awesome 🙂     ... View more

My interpreted response from our Meraki sales rep.: "HA HA HA HA HA HA HA HAAAAA .... 90 to 100 % .... HA HA HA HA HA HA HA HA!!!!"   RIP my home lab. ... View more

In ETSI area channels 36 - 64 only allow up to 23 dBm whilst channels 100 and above allow up to 30 dBm that is why you have the difference. ... View more

I think this is broken again in 30.2 My MR46E with the default antenna can now again only go to 12dbm transmit power. ON the other hand ... my MR36H can now go to 25dbm .... yes .. you read that correctly transmitpower on 5Ghz ....  #broken ... View more

With that, it seems "safe" to start with CW-APs and migrate them later to DNA mode. I'll go with that! ... View more

No but it makes it easier for them to get into the local status page with a local laptop. so you set the APN   MG - (varies) The local status page is accessible at the MG's LAN IP address. By default, MG devices run DHCP. Once the client is connected to a LAN interface of the MG, find the client's IP address and default gateway, then open the default gateway address in a web browser.   https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page   https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page#MG_Series     ... View more

Hmmm .... interesting. I actually think we have had it connected for more then two hours. But I will - Re-try "the procedure" today and let you know.   Alternatively I can now see that survey mode has been enabled from IOS-XE 17.9 (or something) in "DNA-persona" - I tested that out on another 9164 yesterday and that seems to work just fine. (For those who want to try that : SSH or console into your "DNA-persona" AP, and give it the command : ap-type site-survey) The "webui" of the AP (who nows looks an awfully lot like the OEAP UI 🙂 ) will have the settings you need for channel and power. (The login is admin / admin when setting this "type", regardless of what you had before on the AP). ... View more

I was able to fix the problem by upgrading to v18 and change Client tracking to "IP Address." The problem was the new Content filtering changed in v17 was not working well with my internal L3 routing.  ... View more

I guess nothing has changed in 4 months? since @JohnT's message? ... View more

Exactly what @thomasthomsen said: if you've got 150 users sitting behind a MX64 doing nothing, everything is perfectly fine. If each and everybody is downloading dozens of Linux ISO images (e.g.) at the same time, things will start to get interesting... ... View more

Even I am betting on @RaphaelL . ... View more

Thanks (Im working remote and cannot "double check" with an actual client). But I accept this as fact 🙂 ... View more

I am glad to hear that 🙂 ... View more

Hello @thomasthomsen , thanks for bringing this to be community.   Yes, this should work. The two Orgs are different, and do not share information(such as route) on the Meraki infra. This should work A-okay as long as the route configuration is configured appropriately in Azure. ... View more

From what I understand, the vMX token from the dashboard is typically used to associate the vMX instance in Azure with your organization on the dashboard. The "lifetime" usually indicates the time window during which the token can be used for this association, starting from the moment it's generated.   If the vMX is not online in the dashboard, even though you've confirmed that the instance is reachable from Azure hosts, it suggests there may be a problem that's preventing the vMX from communicating with the dashboard. This could be due to network routing or firewall issues, for example.   The token's "lifetime" usually does not affect the vMX's ability to stay online once it has been successfully associated with your dashboard organization. Therefore, if your vMX was never online in the first place, re-generating the token and trying again might be worth a shot. But, it's also important to investigate potential network or firewall issues that could be blocking the vMX's communication with the dashboard.   Here are a few things to check: Make sure the vMX has the correct network settings and security group permissions in Azure to allow it to communicate with the dashboard. Check if there's a firewall in your network that's blocking the necessary ports. The vMX needs to be able to make outbound connections to the Meraki cloud on certain ports. Review the vMX deployment guide and ensure that all steps have been followed correctly. This includes setting up the virtual network in Azure, configuring the vMX instance, and so on. If you suspect that the token might have expired before the vMX was able to connect to the dashboard, you could try generating a new token and entering it in the vMX settings in Azure. ... View more

Z3's here and a MX250 Hub.  18.107 caused major issues.  See this ping response!   Pinging 10.59.97.249 with 32 bytes of data: Reply from 10.59.97.249: bytes=32 time=1682ms TTL=60 Reply from 10.59.97.249: bytes=32 time=3423ms TTL=60 Reply from 10.59.97.249: bytes=32 time=3168ms TTL=60 Reply from 10.59.97.249: bytes=32 time=2440ms TTL=60 Request timed out. Reply from 10.59.97.249: bytes=32 time=1823ms TTL=60 Reply from 10.59.97.249: bytes=32 time=2578ms TTL=60 Request timed out. Ping statistics for 10.59.97.249: Packets: Sent = 8, Received = 6, Lost = 2 (25% loss), Approximate round trip times in milli-seconds: Minimum = 1682ms, Maximum = 3423ms, Average = 2519ms   Rolling back to 17.10.2 fixed issue for most, but didn't work on all.  Seems the rollback fails often. ... View more

After ~ 3 hours on the phone with Meraki and sharing the information provided by @IDV , @Raphael, @dgander , @dade80vr  & @dade80vr we have a "bandage" to resolve this until an update to fix it is released.  I was informed that Meraki is aware of the issue and is working on a solution.  No ETA as to when the actual fix will be known.  Meraki also stated that this is only affecting MX84's.  I suspect it may affect other models as well that the setting listed below is available on.   Solution:  Disable Web Cache and reboot router. Security & SD-WAN -> SD-WAN & Traffic Shaping   Unfortunately a reboot is required for the change to take effect.   I hope this helps anyone currently having the issue.     ... View more

Yeah, but in a Cisco standard switch you can tweak certain settings, if you need to go beyond 7 (as far as I remember, not saying its recommended, not AT ALL 🙂 ) - Just wondering if support can tweak some of the same settings.  ... View more

"When RADIUS servers have failed they appear in the event log, and the device usually changes to an alerting status, and when you go into it the device status says their was a recent RADIUS failure." - And this was the problem here. No alerts, and nothing in the event log. The dot1x SSID had changed to the secondary radius, but would "once in a while" try the primary one (with the ensuring timeout and everything as you mention), and I dont know why, it does this, to test if its back alive ? - and why does it try , also once in a while to ping the radius server, this seems "important", but no explanation. The iPSK network would not change to the secondary radius, and just continued trying the primary one.   - But from all this it seems that there are really , ehhh , how do I put this : "inconsistencies" in how AP radius functions, what people think, and what the documentation and support says - and that is what annoys me the most. ... View more

I'm in this boat too in Aus, patiently waiting for whatever regulation they need to go through so I can play! ... View more

Posting if this helps others, upgrading MX units to 18.105 which only have cellular/4G internet (ie, no ethernet internet connectivity) there appears to be a bug which the unit reports on the dashboard as upgraded to 18.105 however the device goes offline for 15 minutes every 2 hours. Meraki support engineer confirmed the device was stuck in a upgrade loop and was actually still running 17.10.2 firmware even though the dashboard says its updated. Telling the MX to reboot via the web dashboard 'fixes' the issue for a few hours before it comes back again. The actual fix is to pull the power out of the MX and reconnect, the hard power off/on appears to force it to update correctly. ... View more