Awesome. Glad it resolved your issue.   Good luck with the rest of your project ... View more

@M4TT we have our DC MXs set up as @GIdenJoe said.  They have been completely trouble free for a year or so with 8 remote sites over dual connected SD-WAN and an increasing number of homeworkers with either small MXs or Z3s using the supernet method described.   We use Sophos XGs as the main internet facing firewalls and their NAT plays nicely, I believe Palo Alto does not, not sure about other vendors. ... View more

We'll be happy to help, but don't forget - your Meraki license buys you 365-day, 24 x 7 access to Meraki Support.   If your query is urgent, picking up a phone gets maximum priority over email / cases raised through Dashboard.  (check out Help > Get help, top right of Dashboard) Remember to check out the Meraki documentation pages before asking - the aim is that the KB articles are 'Meraki-simple' to access and understand - plus you're likely to get pointed there, if that's where the answer is available, whomever you ask   😁   https://documentation.meraki.com/   So, just by way of example:   https://documentation.meraki.com/zGeneral_Administration/Support/Contacting_Support Enjoy your Meraki journey! ... View more

Our intention is to pool / load balance the bandwidth. ... View more

I would look at the use case for your existing MR16s and the current and likely future usage profile for the replacement APs.   Like others, I'd question the use of MR20, particularly for its lack of 3rd (scanning) WiFi radio.  It may be the closest in terms of capability to the MR16, but if you're using those APs for serving a modern carpeted office, with the usual for example, I'd actually use MR46 as my 'vanilla' starting point.   If this can't be justified, cost-wise, then MR36. ... View more

This is obviously quite some time after the original post, but adding, for anyone also finding their way to this thread:   https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing#Notes_regarding_switch_management_address_when_using_L3_routing ... View more

Hi Paul,   Thanks for the reply. I watched your video as well but as we don't push out WiFi protocols for BYO devices (users have their own username and password authenticated via radius) that doesn't help our situation. (Although I have enabled that in the WiFi profile we push to company owned and managed devices before they update to iOS 14)   One small saving grace is that Systems Manager Sentry is not able to authorize a device with MAC randomisation enabled (since it can't correlate the WiFi and MDM MAC addresses) so a user can't get past the sentry until they manually disable MAC randomisation in their WiFi settings. Not very user friendly (they need to be informed out-of-band that they need to do this) but at least it prevents devices connecting and being able to use WiFi until this is done, and at that point all MAC based functionality will be working again.   I agree that there needs to be a device wide MDM setting for this for enterprises to disable this feature on their managed devices, although even then they would still initially connect with a randomised MAC address until they had enrolled and received the profile, at which point the device would presumably reconnect with the correct MAC address, leaving behind a "ghost" device in the WiFi device list.   A bit a of a mess really but this is typical of Apple introducing far reaching changes to how fundamental technology works without providing a way for enterprises to manage it properly. ... View more

Hello,    unfortunately, as mentioned below, there is no evidences due to cloud strategy... For now i will give all those answers from this topic to my company compliance.   Thank you all for your reply 🙂     Nickola ... View more

So, you were logging your own syslog message over the tunnel... generating an syslog message....   a loop spanningtree can't do anything about  🤣   But nice find 👌 ... View more

I have also noticed some possible discrepancies in the allowed EIRP on Meraki W6 AP's vs the actual regulatory allowed EIRP.   In Europe you have following rules. All 2.4 GHz channels - max 20 dBm EIRP. So the MR 33 should be max 16 dBm Tx Power and the MR36 should be max 14 dBm.   In case of 5 GHz it depends on the channel. 36 - 48 and 52 - 64 = max 23 dBm EIRP In this case you should have max 19 dBm Tx power on MR33 and max 17 dBm on MR36. 100 - 140 = max 30 dBm EIRP In this case you should have max 26 dBm on MR33 and max 24 dBm on MR36   However the MR33 also has a total max Tx power of 17 to 21 dBm depending on the channel used. And the MR36 is even a bit lower I've found the datasheet in the library section of the site (it's not linked on the product page itself 😕 )  the max power is 18 dBm in 2.4 GHz and 17 on 5 GHw   ... View more

Clearly you have never been to a factory / manufacturing environment where you have to deal with devices which don't speak 802.1 x at all (and thus you cannot make use of it for auth.). ... View more

Thanks Adam ... View more

Just one other thought - make sure your Meraki APs can reach the Internet  (i.e. the Meraki cloud platform). You may need to open some access for this through your network and perimeter firewall;   check out Help > Firewall info, from the Meraki Dashboard, for the holes you need. ... View more

Allright, how about a recap of what is essential. So your two original MX'es need to be in the main Meraki Dashboard org so they can do autoVPN where one is a Hub and the other can be a spoke pointing to the Hub.  If you want local internet traffic breakout (do not enable default route checkbox on the spoke).   The other MX has to be in a completely separate Dashboard org because you'll otherwise include that MX in AutoVPN and you cannot have the same subnets behind two different NAT mode MX'es unless they are an HA pair. Example: Imagine the following addressing: IPsec remote LAN subnet: 10.0.1.0/24 Hub site internet subnet: 198.51.0.0/24, upstream router .1, MX AutoVPN hub .101, MX IPsec VPN .201 Hub site client LAN: 10.1.1.0/24 Hub site transit between AutoVPN Hub MX and IPsec VPN MX 10.1.255.0/30 where AutoVPN Hub is .1 and IPsec VPN is .2 AutoVPN spoke site client LAN: 10.2.1.0/24 The AutoVPN spoke is the easiest to configure: just have the local VLAN with subnet: 10.2.1.0/24 included in autoVPN and make sure you connect to the Hub site MX as a spoke. The AutoVPN hub has the two VLANs defined 10.1.1.0/24 and 10.1.255.0/24 and you need to add a static route towards 10.0.1.0/24 via 10.1.255.2.  The local VLAN 10.1.1.0/24 and the static route to 10.0.1.0/24 must be included as the local AutoVPN subnets. The IPsec VPN has a single local VLAN with subnet 10.1.255.0/24 with itself as .2 and needs static routes towards 10.1.1.0/24 and 10.2.1.0/24 via 10.1.255.1.  You will need to put that MX as a Hub and include the static routes as local VPN subnets and then create that org wide's IPsec config towards the remote site where the remote subnet is 10.0.1.0/24. Then you should be golden.  You'll have to make sure not to mix IP's between the orgs.  You could of course use the supernets 10.1.0.0/16 and 10.2.0.0/16 instead of the /24's as long as there are no overlaps because that is where you could get weird behavior. ... View more

Sounds very misleading to me, @PhilipDAth - I'd log a case for it. ... View more

Thanks everyone , Seem got the solution now Thank you so much !!! ... View more

Philip's suggestion sounds sensible. If they have already deployed the MX68 then stick with it - but monitor utilization of the MX, by using Organization > Monitor > Summary report for the appliance Network in which it is deployed. Remember that if you don't follow guidance within the MX Sizing Guide + the customer suffers performance issues + MX utilisation is high, then Meraki Support would be within their rights, ultimately, to simply suggest you deploy an appropriate MX model. If the MX has net yet been purchased, I would suggest buying the right model, after consulting the guide. You could also try using the meraki Free Trial process, to see how MX68 performs in that environment. https://meraki.cisco.com/lib/pdf/meraki_whitepaper_mx_sizing_guide.pdf ... View more

Actually, thinking about it a bit more, I'm not sure the other proactive alerting mechanisms are any more secure (certainly not compared to properly implemented SNMPv3) ... View more

What firmware were you running, I have an MR55 on one network and it seems fine, was it roaming issues, speed issues or disconnects etc.? ... View more

Thank you thats what i was looking for as an answer. ... View more

Thank you very much @GreenMan & @AjitKumar . I will give it a go and revert. Cheers ... View more

@GreenMan is correct here.   This is a walk through guide. https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise  ... View more

Ok so I removed the physical link between the camera vlan and the stack.  But in order to get connectivity I had to go into the camera VLAN on the stack and add Port 1 (on the switch, that connects to MX port 3) as tagged.  This is what the vlan on the switch looks like now.   VLAN Interface with name cameras created by user Admin State: Enabled Tagging: 802.1Q Tag 30 Description: None Virtual router: VR-Default IPv4 Forwarding: Disabled IPv4 MC Forwarding: Disabled Primary IP: 0.0.0.0/0 IPv6 Forwarding: Disabled IPv6 MC Forwarding: Disabled IPv6: None STPD: None Protocol: Match all unfiltered protocols Loopback: Disabled NetLogin: Disabled OpenFlow: Disabled QosProfile: None configured Egress Rate Limit Designated Port: None configured Flood Rate Limit QosProfile: None configured Ports: 7. (Number of active ports=3) Untag: 1:11, 1:12, 1:13, 1:14, *1:15, *1:16 Tag: *1:1   All the cameras are plugged into ports 11-16.  Port 1:1 is connected to my MX (Trunked, Drop all Untagged, Allow All VLANS) ... View more

It's a dual-band antenna; i.e. each antenna element inside the antenna unit serves both the 2.4 GHz and 5 GHz radio simultaneously. There are two elements in the antenna, one per pigtail. This is why there are two antennas required, to support an AP with 4 antenna posts. For APs with dual-band antenna posts (i.e. MR84) it's important that both antennas cover the same area - as client devices supporting multiple streams will attempt to use them, to build a higher bandwidth connection. If used with APs which have dedicated antenna posts for each of the 2.4 and 5 GHz radios (MR74), you could, theoretically, have different antennas attached, covering different areas. ... View more