Thanks to the Meraki team for adding that, it shows once again that the community is integral to the solution 👍   For completeness below are the notes including half a dozen MS390 fixes: Switch firmware versions MS 15.18 changelog Alerts HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect. MS390 upgrades to this version will result in a full system reload MS390 series switches can only downgrade to MS 12 with an incremental step to MS 14 New features STP anomaly detection support for MS390 series switches IPv6 static routing support for MS390 series switches Additional client analytics added for MS390 series switches Meraki authentication support for MS390 series switches Alternate Management Interface (AMI) support for MS390 series switches UDLD support for MS390 series switches Group policy ACL support for MS390 series switches IPv6 management interface support URL redirect support for MS390 series switches UPoE (802.3bt) support for MS390 series switches Critical/failed authentication support for MS390 series switches Multi-auth with voice VLAN bypass support MAC flap detection support for MS390 series switches Stack power is supported by default for MS390 series switches Netflow and Encrypted Traffic Analytics (ETA) support for MS390s Bug fixes MS390s with DHCP configurations for over 100 SVIs will fail to apply (present since MS 15.17) Collecting out-of-band logs on the local status page for MS390s may result in the management plane restarting (present since MS 15.8) MS390s may reboot with incomplete configurations for URL redirection, requiring reconfiguration (present since MS 15.15) MS390 SNMP walks for "IfAlias" return empty values (present since MS 14) MS390 ports can enter an error-disabled state and not recover without a port bounce (always present) MS390s authenticating over 350 dot1x clients at the same time may see its management connection flap (present since MS 15.4) General known issues AMI IP addresses do not send gratuitous ARP packets which can lead to packet loss if the AMI address has aged out in the network Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12) Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10) Deleting an SVI on a stack results in the stack's highest numbered VLAN which is sharing the same RFC 1918 address to have an incorrect next-hop VLAN (present since MS 14.33) Enabling NAT detection may cause issues with TCP streams resulting in pages failing to load entirely or taking longer than usual to load (present since MS 14) Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present) Sporadically, SNMP walks will fail by not increasing the OID (present since MS 14.13) Switch stacks will learn MAC addresses from ports in the STP blocking state which can trigger a constant flood of MAC flaps in the event log The next-hop port may be incorrect on L3 stacks and believed to be the result of client flapping between ports (present since MS 14.32) mGig switches will have an amber light for all physical ports that do not negotiate to the highest supported speed. Dashboard will continue showing a light green status for all ports above 100Mbps. For example, MS355 switch ports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G. Non-MS390 switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 unless the bundles are configured on the MS390 first. All Non-MS390 ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present) Ms120 known issues In rare instances, switches may return empty packet captures until they are rebooted Switches in extremely rare instances will experience reboots every few minutes (present since MS 11) Ms120/125 known issues Ports with an odd-numbered MTU value fail to initialize (predates MS 11) Ms120/220 known issues Switches will never move a RADIUS server's connectivity status to available if it was ever lost resulting in all authentications being placed into the critical auth VLAN (present since MS 14.32) Ms125 known issues The local status page cannot be accessed from the management port of MS125s (always present) Ms210/225/350/355/425/450 known issues In large L2 networks experiencing frequent STP TCs can become fully unresponsive (present since MS 15) Ms350/355 known issues Enabling Combined Power results in events being logged once per minute (present since MS 11) Ms350x/355 known issues Switches do not negotiate UPoE over LLDP correctly (always present) Ms390 known issues "Port Up/Down" events will generate an event log for each stack member Adding additional ports to a port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present) Fixed IP assignments are not deconfigured until the system is fully reloaded (present since MS 14.33) IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present) In very rare instances, the management plane will reboot every few minutes and requires a full reboot to self-correct (present since MS 15) Loop detection is not supported Management plane may lose connectivity after changes are made to the storm control percentage Multiple CoA policies sharing the same IP but using different ports fails to be configured (always present) Passing line rate traffic on non-uplink ports can have an impact on the management plane connectivity Ports fail to be configured if the allowed VLANs character length is greater than 223 (always present) Rebooting an MS390 switch in a stack via the UI will result in the entire stack rebooting Receiving incorrectly flooded CDP packets may incorrectly report VLAN mismatches and SFP port information (present since MS 12) Warm spare/VRRP is not supported Ms400 known issues When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12) Ms425 known issues MS425 stacks in rare instances will start dropping DHCP traffic on trusted ports while DAI is enabled until rebooted (present since MS 12) Other Good idea cmr ... View more

Half a dozen MS390 fixes and reorganised issue section: Switch firmware versions MS 15.18 changelog Alerts HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect. MS390 upgrades to this version will result in a full system reload MS390 series switches can only downgrade to MS 12 with an incremental step to MS 14 New features STP anomaly detection support for MS390 series switches IPv6 static routing support for MS390 series switches Additional client analytics added for MS390 series switches Meraki authentication support for MS390 series switches Alternate Management Interface (AMI) support for MS390 series switches UDLD support for MS390 series switches Group policy ACL support for MS390 series switches IPv6 management interface support URL redirect support for MS390 series switches UPoE (802.3bt) support for MS390 series switches Critical/failed authentication support for MS390 series switches Multi-auth with voice VLAN bypass support MAC flap detection support for MS390 series switches Stack power is supported by default for MS390 series switches Netflow and Encrypted Traffic Analytics (ETA) support for MS390s Bug fixes MS390s with DHCP configurations for over 100 SVIs will fail to apply (present since MS 15.17) Collecting out-of-band logs on the local status page for MS390s may result in the management plane restarting (present since MS 15.8) MS390s may reboot with incomplete configurations for URL redirection, requiring reconfiguration (present since MS 15.15) MS390 SNMP walks for "IfAlias" return empty values (present since MS 14) MS390 ports can enter an error-disabled state and not recover without a port bounce (always present) MS390s authenticating over 350 dot1x clients at the same time may see its management connection flap (present since MS 15.4) General known issues AMI IP addresses do not send gratuitous ARP packets which can lead to packet loss if the AMI address has aged out in the network Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12) Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10) Deleting an SVI on a stack results in the stack's highest numbered VLAN which is sharing the same RFC 1918 address to have an incorrect next-hop VLAN (present since MS 14.33) Enabling NAT detection may cause issues with TCP streams resulting in pages failing to load entirely or taking longer than usual to load (present since MS 14) Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present) Sporadically, SNMP walks will fail by not increasing the OID (present since MS 14.13) Switch stacks will learn MAC addresses from ports in the STP blocking state which can trigger a constant flood of MAC flaps in the event log The next-hop port may be incorrect on L3 stacks and believed to be the result of client flapping between ports (present since MS 14.32) mGig switches will have an amber light for all physical ports that do not negotiate to the highest supported speed. Dashboard will continue showing a light green status for all ports above 100Mbps. For example, MS355 switch ports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G. Non-MS390 switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 unless the bundles are configured on the MS390 first. All Non-MS390 ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present) Ms120 known issues In rare instances, switches may return empty packet captures until they are rebooted Switches in extremely rare instances will experience reboots every few minutes (present since MS 11) Ms120/125 known issues Ports with an odd-numbered MTU value fail to initialize (predates MS 11) Ms120/220 known issues Switches will never move a RADIUS server's connectivity status to available if it was ever lost resulting in all authentications being placed into the critical auth VLAN (present since MS 14.32) Ms125 known issues The local status page cannot be accessed from the management port of MS125s (always present) Ms210/225/350/355/425/450 known issues In large L2 networks experiencing frequent STP TCs can become fully unresponsive (present since MS 15) Ms350/355 known issues Enabling Combined Power results in events being logged once per minute (present since MS 11) Ms350x/355 known issues Switches do not negotiate UPoE over LLDP correctly (always present) Ms390 known issues "Port Up/Down" events will generate an event log for each stack member Adding additional ports to a port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present) Fixed IP assignments are not deconfigured until the system is fully reloaded (present since MS 14.33) IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present) In very rare instances, the management plane will reboot every few minutes and requires a full reboot to self-correct (present since MS 15) Loop detection is not supported Management plane may lose connectivity after changes are made to the storm control percentage Multiple CoA policies sharing the same IP but using different ports fails to be configured (always present) Passing line rate traffic on non-uplink ports can have an impact on the management plane connectivity Ports fail to be configured if the allowed VLANs character length is greater than 223 (always present) Rebooting an MS390 switch in a stack via the UI will result in the entire stack rebooting Receiving incorrectly flooded CDP packets may incorrectly report VLAN mismatches and SFP port information (present since MS 12) Warm spare/VRRP is not supported Ms400 known issues When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12) Ms425 known issues MS425 stacks in rare instances will start dropping DHCP traffic on trusted ports while DAI is enabled until rebooted (present since MS 12) Other Good idea cmr ... View more

Well it was full of builders at the time, so... ... View more

If you set a VLAN as native and don't include it in the trunk and do the same on a Cisco Catalyst switch at the other end, then the link will not pass the traffic in the native VLAN, I can confirm this from experience...  ... View more

The biggest issue is if you identify individuals (even by device names).  If you do, then you want to move the cloud host to the European region. for data protection purposes. ... View more

I had to go to the intel website as those locations didn't have recent enough drivers.  Here is a link: Windows® 10 and Windows 11* Wi-Fi Drivers for Intel® Wireless Adapters ... View more

@SebT what driver version is the laptop running, that was the main issue (along with needing to turn off power saving on the laptop driver which can be confirmed by connecting the laptop while the external power supply is connected. ... View more

Thanks @Ryan_Miles it makes sense now, I hadn't realised that the air quality level was added to the temperature alert... ... View more

Glad what we did worked for you, hopefully you can just enjoy the MX simplicity now 👍 ... View more

@SebT this is an Intel driver bug that has been resolved with newer drivers and Meraki firmware.  We had the same a while ago, but resolved it all.   What driver versions are you running and what Meraki APs / firmware?   ... View more

Any hot-cold power cable will do for an MS120.  As mentioned above the switches with removable power supplies and PoE required the notched connector (C15) at the switch end due to them being in the exhaust flow.  The cable is also a slightly rougher material as it can withstand higher temperatures that may be present in those areas.  Again, if you ever need those cables they are commonly available from most suppliers.     ... View more

This is 17.10.2 moving from stable release candidate to stable release.   We've been using it with enterprise features reliably, but there are several reports of advanced features leading to a less good experience. ... View more

If you look at the client page and add the port column, you will see for many MXs that the port shown is indeed N+1.  Therefore port 2 is the labelled port 3 as @alemabrahao stated.  Try on your network and this will confirm it for you, but it is definitely the case for an MX75. ... View more

@ronnieshih75 I would follow what @GIdenJoe said, we recently found that some 1Gb RJ45 transceivers would not properly plug into Meraki SFP+ ports as the ports were slightly sunk into the fascia.  This caused no issues with fibre transceivers as they are smaller.  We run MX250s with Cisco GLC-T in the WAN ports without issue, but I do remember that some Meraki GLC-T modules did need a firmware update to be recognised (as per @PhilipDAth's comment.   Do you have any non-Meraki GLC-T transceivers or fibre ones?  On another note, I'm sure you know that the DAC will only come up at 10Gb (usually) so you mustn't force the port to 1Gb. ... View more

Looks good and hope the holiday season goes well for you guys 👍 ... View more

Thanks @Ryan_Miles. I like the idea, but it's painting a bit of a rosy picture 😐 ... View more

The utilisation of 161 is 0% so that shouldn't be the problem, though I did check a 9166 and the graph is all over the place.  Newer models often take a while for this part to be right... ... View more

Here you can see an AP on channel 40 that is slightly suffering, but in realist is working fine, what does the table below show for your one?   In terms of diagnostics there is a lot of infrastructure between your client and Google's DNS servers, so I would ping the local gateway for a better test of the AP and local switch / router only.  If that shows loss and pinging it from a wired device does not then the wireless is where to investigate.   ... View more

@merman01 the Meraki APs automatically adjust power and channels for best performance (unless you override that feature).  For connection issues you have the wireless health page and for overall AP placement the location heatmap can help as it shows device locations, see an example below:     ... View more

I think it is where it is, because switches can also be DHCP servers and it is in the same relative place there.  I do agree however that it is hard to find and I think it should be under Network-wide / Monitor in a DHCP addresses section.  There could be a column there to indicate which device leased the address to cover networks with multiple L3 switches assigning addresses alongside an MX.   ... View more

We have had STP not block properly with MX + MS though it works fine with Catalyst switches.  I haven't re-tried this config with MS15.x stacks yet. ... View more