@Brill I'm actually surprised that the MA-ANT-21 and MA-ANT-23 are listed on the MR84 datasheet. The MR84 antenna connectors are dual band ports, which means they should use a dual band antenna, otherwise you're leaving radios disconnected from an antenna (which is going to play well). If the data sheet is correct then maybe there is some 'smarts' that takes care of the radios when only single band antennas are connected to the ports (someone with more knowledge than me will need to clarify that one - I've only ever seen them with dual band antennas connected).   Definitely, if you attach dual band antennas to the ports (such as the MA-ANT-25) then they should cover the same areas as some of the features of Wifi 5 and Wifi 6 (e.g. MIMO, MRC) require that.   There is actually no configuration for Meraki Mesh. If the AP can't get and IP address on its LAN port then it will 'flip' to Mesh operations and start looking for an adjacent access point to connect to. https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Wireless_Mesh_Networking ... View more

Sounds like the SSID configuration is probably not the problem. You mention the AP has Static IP with no VLAN. If the AP has a static IP address then it shouldn't be using DHCP. If it is using DHCP then it means that its failed to contact the Meraki cloud using the statically configured IP address. Does the AP have DNS services and an IP gateway configured correctly too? (Or if you're using reservations on the DHCP server, just move it to DHCP). ... View more

What 'Client IP Assignment' are you using on the SSID - I'm assuming NAT mode. So the traffic is intended to go directly from the AP to the ASA and then out to the internet. Any you're seeing the "This device is using a DHCP IP address...." in the Meraki Event Log for the AP? ... View more

If you're seeing a number of STP changes then something is occurring in the network that is causing STP to reconverge. If this is happening again and again, then this will cause the switches to be unable to contact their DNS servers (either due to high-CPU, or pure network traffic), so the DNS misconfiguration is likely a secondary symptom.   I'd be checking your network for Layer 2 loops and ensuring that STP is appropriately blocking them (ideally you'd remove all the Layer 2 loops and use LACP for redundancy), and finding out where the changes in the network are occurring that are causing a STP reconvergence. You mention Blade Servers, and that would be one of my starting points, especially if they have an switch in the chassis which will be non-Meraki (I've seen plenty of issues here in the past - generally devices that don't running STP and thus create loops in the network if you're not careful).   I'd take the time to review the network against the Meraki MS best practice guide, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices. And I'd pay special attention to the Spanning Tree elements of it: Keep the STP diameter under 7 hops, such that packets should not ever have to travel across more than 7 switches to travel from one point of the network to the other BPDU Guard should be enabled on all end-user/server access ports to avoid rogue switch introduction in network Loop Guard should be enabled on trunk ports that are connecting switches Root Guard should be enabled on ports connecting to switches outside of administrative control Tell us how you go. ... View more

What are the configurations of your SSIDs? Where are clients getting their IP addresses from? Even if you configure the switch port as an Access Port you need to remember that the MR is still effectively a Trunk Port. If you use an IP addressing mode on the SSID that potentially tags traffic on the port (e.g. Bridge Mode, Layer 3 Roaming) then you might be seeing unexpected behaviour that has nothing to do with the Management IP address and VLAN of the MR.  ... View more

Exactly what @cmr said, but I'll add a little to that. A lot (like really a lot) of web traffic is encrypted or dynamically generated and so unable to be cached anyway. It may be that you get some benefit to it, but I'd say its unlikely, and very dependant on what's being downloaded. Also worth noting that the MX84 and MX100 had 1TB drives for caching, the MX250 and MX450 only have 128GB drives (although they are SSDs) - does that say anything? ... View more

@ManolisFr if its an unmanaged device then you'll likely be having the same issue I described for the MX64. If the Synology is using both its NIC MAC addresses, but only a single IP address then you will be seeing the same IP with two different MAC addresses, which triggers the alert on the MX. Have a look at the MAC addresses that the MX is reporting in the Event Log alerts and see if they match the MAC addresses on the two NICs of the Synology.   Unfortunately, there may not be a solution to this one. If you're using Synology's Adaptive Load Balancing this may just be the way it works. Your solution may be to either live with the error, unplug one of the cables from the Synology (i.e. break the network bonding), or to purchase a switch that supports LACP and use LACP for the link aggregation. ... View more

So far as I'm aware the cellular interface on the MX67C/MX68WC are still only for failover in the event that your WAN interfaces both go down. Therefore, L2 is still only 1 in your scenario (assuming you're only using WAN1, and not WAN2) as the cellular link won't kick-in unless the link on WAN1 fails. ... View more

What model is the gigabit switch? Is it configured with link aggregation? ... View more

The MR84 is a 4x4 radio, so each antenna is both a 2.4GHz and a 5GHz radio. So with the MR84 there is really no way to use one radio for point to point and the other for client serving, since the antennas that you attach will do both. With the MR74 however you have 2x2 radios with the top two antennas serving the 5GHz radio, and the bottom two the 2.4GHz (or vice versa, I can’t remember). In this scenario you can say attach a directional antenna to the 5GHz radio for backhaul (point-to-point using Meraki mesh) and then use omni-directional antennas for client serving on the 2.4Ghz radio. There’s no way to specifically configure the radios specifically for backhaul (mesh) or client serving, it’s just how you design the network based on Meraki mesh and the antennas you choose.. ... View more

@ManolisFr what are you connecting your Synology NAS to? If its directly to the MX64, then the MX64 doesn't support any form of NIC/network bonding. It is possible that the Synology is using both network links with the same IP address. This will likely result in the Meraki seeing an IP address being associated with two MACs, and hence the error. I would try 'un-configuring' the network bonding on the MX if the Synology is connected to it.   The server is probably behaving slightly smarter - i.e. keeping each IP address on the same NIC - which is why you're not seeing alerts from the server. ... View more

@GFrazier the lack of STP support on the MX is good to remember, but if you only have a single link to it from each switch then it doesn’t make too much difference - if you have multiple links you need to consider the spanning-tree topology.   With your plans, it generally sounds good, but a couple of things to consider:   Why not stack all three switches in the MDF (assuming they’re located together, and the same model). You could use 3x MS225 if you only need basic Layer 3 capabilities - they’ll support up to 16 VLAN interfaces and 16 static routes. You can then use the stack as your Layer 3 gateways. Having all switches in a stack in the MDF would allow you to dual connect the MX and the IDF switch stacks to provide improved redundancy - in physical stack you can do cross switch LACP aggregation (this is only to the MS, the MX doesn’t support LACP so you need to rely on STP for redundancy). Relaying DHCP to the MX should be fine; the MS225 only supports DHCP relay (and Azure doesn’t allow DHCP servers).   ... View more

If you do go with the Meraki switch on the outside of the MX, then it might be best to put it in its own Dashboard network so that the Dashboard reporting for the actual network is better. ... View more

As always (annoyingly), it depends.  If your network is generally a flat Layer 2 network where the communications is generally between clients on a single VLAN, then having the two switches connected to the one makes sense, as a lot of the traffic won’t need to hit the MX (and so reduces the load on the MX).   If however you have a well structured network with separation between server and clients so that the majority of traffic goes through the MX (as it’s a acting as a Layer 3 gateway) then it probably makes little difference as the traffic is traversing the MX to reach the other VLANs anyway.  Generally I’d take the approach you currently have, MX to MS, then that MS to the other MSs, but if you using the MX for Layer 3 (since the MS220s are Layer 2) I don’t think there’s much difference either way. ... View more

You can try the factory reset procedure here to get the MX back to defaults, https://documentation.meraki.com/zGeneral_Administration/Support/Resetting_Cisco_Meraki_Devices_to_Factory_Defaults. But before you do that I'd call support and see what they can do to assist, they can likely see things happening on the backend that you can't. ... View more

@d2 Exactly that. In normal circumstances you have your primary internet link and your MPLS link on MX1. You run AutoVPN across them both (assuming there is internet access from the MPLS network somewhere - either directly or via the head-end) and you can use the SD-WAN capability. You have a backup internet link on MX2 so that in the event that MX1 fails you get internet access (local breakout) via MX2 and an AutoVPN tunnel is brought up to connect back to your head-end.   The other failure scenarios are (assuming primary internet is in WAN 1 on MX1): primary internet fails, all traffic goes via the MPLS link. MPLS link fails, all traffic goes via the primary internet. Both primary internet and MPLS link fails, VRRP will make MX2 active and all traffic will go via backup internet link. ... View more

@buschtrommelXXL Glad to hear you got it working.   Here are the guide lines for setting up the STP guard features:   BPDU Guard should be enabled on all end-user/server access ports to avoid rogue switch introduction in network Loop Guard should be enabled on trunk ports that are connecting switches  Root Guard should be enabled on ports connecting to switches outside of administrative control These come from this document, https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices.  However, between the MX and MS devices I wouldn’t enable any of the STP guards since the MX doesn’t participate in STP, it just forwards any BPDUs it receives. ... View more

Hi @d2 , here's some confirmation of your points, and some considerations.   You are correct, only Active MX forwards traffic, but the Standby MX does need to have connectivity to the Meraki cloud so that it can report in, receive firmware upgrades, etc. Sometimes its a struggle (or expensive) to get the MPLS carrier to provide that second port and additional IP addresses on their CPE device. Consider your failure scenarios as you're only likely protecting against the failure of the MX in this case. Can you make do without the MPLS circuit temporarily if an MX fails? You'll still have connectivity to data centre via the AutoVPN over the internet. Consider your option for the internet links. Do you need a internet link with a /29, what's the price? You may be able to get two separate internet links from two separate carriers instead. The circuits on the WAN side don't need to be in the same subnet, they don't have to have a vIP and they can be completely independent, VRRP doesn't run between the WAN ports. On the LAN side of the MX, yes, they do use VRRP, but both MX appliances share a single IP address (VRRP runs at Layer 2 in this instance), so you can keep your /30 between the MX and the switches. Changing the carrier routing to static is a definite. BGP on the MX is for within the SD-WAN (iBGP) and integrating to the SD-WAN head-end data centre (eBGP). Its not intended for integrating with a carrier running BGP. With regards the visibility, that depends how you set it up. By default the MX allows all outbound internet and all the return traffic, like a normal stateful firewall. But with the AutoVPN/SD-WAN you can force all traffic to your central site still if you'd like. Or, if you purchase the SD-WAN Plus license, then you can do application specific breakout at the branch site, and still tunnel the other traffic to the data centre. Or you can used direct internet access for all traffic at the branch, and only internal traffic across the SD-WAN. I'm sure others will have more comments and suggestions too.  ... View more

@Dennb10  What IOS-XE version is running on the Catalyst? Are all the other APs that are working all MR45s and are the other Catalysts running the same IOS-XE version? Are there any messages related to PoE in the Catalyst event log? I think you're probably better off troubleshooting this from the Catalyst side. I know there have been bugs in IOS-XE where the LLDP power negotiation doesn't work correctly with some devices. ... View more

Normal your native VLAN is just one of your VLANs - quite often it’s the Meraki management VLAN so that your devices can connect to the internet with any pre-configuration. But if you prefer to use just an empty VLAN you can do that too. Just remember to configure the same native VLAN on the switch end of the trunk too. ... View more

What’s the native VLAN on the trunk at the moment? Can you leverage that at all? Pre-configuring 50 APs won’t be fun. If you can use the native VLAN for cloud management traffic only, maybe you could use the Alternative Management Interface for all other management traffic (e.g. RADIUS, Syslog) - and that one you can define for all the APs. ... View more

@thomasthomsen what’s the use case? I don’t believe there is an easy way to do what you’re asking through the Dashboard. Normally you’d want to keep all your APs on the native VLAN so that when you add another one it ‘automagically’ finds the internet and connects to the Dashboard. Otherwise you’ll need to preconfigure every AP before you deploy them anyway, since their first comms will be on the native (untagged) VLAN. ... View more