Meraki

rhbirkelund · ‎Jun 17 2021

Peasants 😉

rhbirkelund · ‎Jun 11 2021

Maybe due to lack of certification? Firm-/software not in place or too buggy to announce? It is not uncommon for vendors to ensure hardware is in place before software support. Give Cisco as an example. Their latest Cat 9100 APs have support for BLE/IoT with the hardware already in place. If memory serves me right, it contains a ZigBee radio. However, even though the hardware is already in place, there is no software support as of yet (last I heard, at least)

rhbirkelund · ‎Jun 11 2021

Honestly, I do have a suspicion that the MG41 has the hardware capability for 5G. But that it is just software limited.

rhbirkelund · ‎Jun 9 2021

So far they will be available to order by July 6th, with shipping starting July 13th.

rhbirkelund · ‎Jun 9 2021

Especially since Cisco already has a Wireless WAN router out, and been so for at least six months, that supports 5G.

rhbirkelund · ‎Jun 9 2021

Seems that the same goes for MG aswell: MG41 https://meraki.cisco.com/product-collateral/mg41-series-datasheet/?file

rhbirkelund · ‎Jun 9 2021

Meraki finally dropped the new MX's in complete silence. Check the MX data sheet here: https://meraki.cisco.com/product-collateral/mx-family-datasheet/?file It's about time!

rhbirkelund · ‎Jun 1 2021

Security & SD-WAN -> DHCP

rhbirkelund · ‎May 28 2021

@mmistretta wrote: [...] it wasn't until after configuring the local and remote IDs, the tunnel came up. Which is also a change in behaviour for MX15.42.1 firmware. From release notes;

rhbirkelund · ‎May 20 2021

What model MX is it? Models MX6n have a shared WAN2 and LAN port, so in order to use WAN2, you'll need to convert a LAN port to WAN I had .misunderstood the question, so just disregard. 🙂

rhbirkelund · ‎May 1 2021

Have a look at https://meraki.cisco.com/public/mv-site-survey/index.html Perhaps, it could help you estimate the amount of MVs needed.

rhbirkelund · ‎Apr 28 2021

I'm not sure if this is available for public, but for reference; https://community.meraki.com/t5/Developer-Early-Access/api-mp-meraki-com-is-now-deprecated-please-use-api-meraki-com/ba-p/116260

rhbirkelund · ‎Apr 28 2021

The mega proxy is being deprecated, so you should use api.meraki.com instead.

rhbirkelund · ‎Apr 27 2021

If the APs are connected to access ports and in vlan 1, configure the new SSID to Bridge Mode and disable VLAN tagging on the Music SSID.

rhbirkelund · ‎Apr 26 2021

Hah! I’d expect the antennas be better packaged. It is Cisco afterwards. 😆

rhbirkelund · ‎Apr 26 2021

Have ensured the AP is configured in survey mode? See here for instructions; https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Conducting_Site_Surveys_with_MR_Access_Points

rhbirkelund · ‎Apr 26 2021

What’s in the “doggy bags”?

rhbirkelund · ‎Apr 26 2021

If you click on the Order no in Active Trial, that should bring you to the trial. From there you should be able to end the trial.

rhbirkelund · ‎Mar 30 2021

Regarding the SKU types, the vMX-M does not choose the IP SKU for you. You have to choose it yourself. There’s four different types, and the exact difference in performance I have no idea. But you need to choose the right one, because depending on what you choose you’ll not able to utilise ClientVPN due to some firewall rules that are being applied the IP SKU.

rhbirkelund · ‎Jan 24 2021

I can't comment for MRs because, well, I haven't tried that scenario yet. But imagine Z1 teleworkers. The Z1 is not supported on MX15.x but you can schedule an upgrade to MX15.x. What will happen is that the Z1 will "upgrade" to MX15, but since there is not support for it, the Z1 will stay on the latest MX14.x software that supports it, but still report as upgraded to MX15.x. I imagine that the same applies to MRs.

rhbirkelund · ‎Jan 14 2021

Perhaps its a hidden Jimi Hendrix mode? Jokes aside, I haven't seen this on any of the cameras I have access to. But it sounds like a hardware malfunction. I'd just reach out to Support and request a quick t-shoot and then RMA the units.

rhbirkelund · ‎Dec 12 2020

So, I dug a bit deeper into this, and had the opportunity to have a conference call both with Meraki Support, as well as Microsoft Azure Support. It seems that the main reason why I couldn't get ClientVPN to work was because ports 500 and 4500 were being blocked. I was not able to open those ports by applying an NSG, due to a vendor policy from Meraki on the vMX RG. Also, it seems that the Public IP SKU being deployed from the managed app, was randomly being chosen as a "Standard" IP SKU, which apparently has some default port blocked. If the deployed IP SKU is "Basic" ClientVPN will work. The only way around this, is a redeployment of the vMX.. I'll probably add some more on this, after I've done some more testing, and sharing these results with Meraki Support.

rhbirkelund · ‎Dec 5 2020

Microsoft keeps claiming that Meraki needs to remove the Vendor policy, on the Meraki App, inorder to create the NSG, so VPN traffic from my client, can reach the vMX. Meraki keeps claiming that Mircrosoft needs to do this, and it is noting to do with the vMX policy.

rhbirkelund · ‎Dec 5 2020

I am right now in the middle of a ping pong between Meraki Support and Microsoft Support, regarding who needs to do something, inorder to open ports udp/500 and udp/4500 and forward it to my vMX, so that I can get ClientVPN to work..

rhbirkelund · ‎Dec 3 2020

No worries. The vMX i Azure has really been a steep learning curve for me. Working on my first deployments, and I have already run in to different odd behaviours.

About rhbirkelund

rhbirkelund

Community Record

Badges