I don't think so as there is nothing in the dashboard to manage it. ... View more

Diolch @ConnorL, the CW9163Es survived!  We had some minor damage and the boiler randomly failed (perhaps due to the power coming on and off a few times)...  Interestingly the Welsh flag came up fine in the notification email!  We are in Ceredigion, about a mile from the coast and our house name is Brynawel, which as you'll know means it was pretty mad 🌬️ ... View more

so, i turned off the client balancing on the radio default indoor profile.  The error code 17 went away almost completely.  The association error code 30's are still all over the place.  not sure if the 17s went away or just changed to 30s.  no user feedback yet.   ... View more

Camera firmware versions MV 6.2 changelog New Dashboard packet capture support on MV13/23/33/63/73/93 series Improved accuracy for line crossing on MV33/93 series Notice When configured for this version, MV21 & MV71 devices will run MV4.15 ... View more

Meraki Licensing FAQs as of 8/7/24 (documentation doesn't reflect any changes).  Perhaps it's forthcoming? ... View more

Great job @MirzaDz!   Wow, @cmr, congrats to that top spot! 😎   Of course, thanks to everybody else involved here! ... View more

why is there no option to configure a virtual ip on the backup wan? ... View more

I want to bump this old post so I don't have to create a new one. I have been actively fighting this issue in the shadows for the past 18 months and got no where.    I know Meraki states that we can create a second org and apply the devices to that org but I have found the following issues.   MX's / Z require a new site per 2 devices (PIN4). Meraki support is giving mixed answers on this topic. Some state if you claim the device then your equipment is locked other support reps will quote the KB. I also have seen the sales team have mixed messaging on this topic as well. The disabled network email warning could cause a lot of unneeded questions within a company when using the inventory network. For companies that do not use APIs this process causes additional steps with inventory management by having to add or remove devices from one org to another. Installation documentation does not fully disclose the inventory process so there is an opportunity     For Meraki if a percentage of your customer base is unaware of this "requirement" they are left open to having their equipment taken from right under them, then having to go through support or sale to try to recover the equipment. This process hurts the customer from a time and frustration point of view, and Meraki from a customer perception and relation.    I will say other vendors that have similar systems will lock the equipment once the equipment is claimed, yet Meraki finds this solution to be better in some way.. I'm open to seeing that vision if there is a gain for me the customer.   Sorry for the small vent, but just wanted to float this out again.   ... View more

This is simply the firmware being promoted to stable. ... View more

Hey @cmr - I know this is somewhat old but I'm actually possibly running into this issue myself using OPTION 2 and what I believe are possibly older iPhone devices. It's a hit or miss situation, sometimes they struggle, most of the times clients don't. Again I suspect it's just old iOS devices. What list did you end up putting in? I did a pcap with an old and new iPad but both seem to be showing similar resolutions for DNS queries prior to clicking the accept button to get past the walled garden.   captive.apple.com captive-cidr.origin-apple.com.akadns.net captive-cdn.origin-apple.com.akadns.net captive.g.aaplimg.com ... View more

First of all: The new UI looks modern, thats nice. But there are some points which I think could be better and it's primary about the Information at the first view:   There is a lot of blank area and I have to scroll much more than the old design. If I enter the AP Summary page I want to see all important Information with one view. The Information on the left (SSIDs, Serial Number, Firmware, IP,...) are in the "wrong" order. I don't need to see the Firmware or Regulatory Info with the first view. The important Info for me and I think many others are: IP Information thats I want to see with the first view. And also here.. the blank gaps between the Infos. Move RADIUS and VLAN request status above Current Clients. The really first thing I want to see is, if all services are working on the Access-Point and if there are like 10 Current Clients I have again to scroll the RADIUS and VLAN request status.   Have a nice weekend 🙂    ... View more

Thank you to you and @cmr, the bonding mode was changed to Mode 1, this is Active/Backup mode so is a switch independent mode so doesn't require the aggregation of the ports.  I want to avoid port aggregation for the time being until all the faults with the switches are resolved. ... View more

Switch firmware versions MS 17.1.3 changelog General important notes MS17 introduces a change to the default login credentials for the device local status page, using "admin" as the username, and the device serial number (upper case with dashes) as the password Ms12x important notes If DAI is enabled prior to upgrading the network to MS 16, ensure that trusted ports and/or DAI-allow lists are configured prior to upgrading to avoid potential network outages. Ms420 important notes Devices configured for this version will run MS 15.22 New feature highlights DOM (Digital Optical Monitoring) Intelligent Capture RSPAN and VLAN Based SPAN SmartPorts New ms130x feature highlights Adaptive Policy on MS130X/R models General fixed issues Fixed a bug that caused some 802.3af devices to display as 802.3at in Switch Port Details Fixed a bug that caused switches to forward some RADIUS requests that included an invalid source MAC address Fixed a cross-stack port mirroring bug that incorrectly showed CDP/LLDP traffic from the source port as being connected to other members of the stack Fixed an issue that caused boot loops when attempting to upgrade to MS17 while using an externally calibrated third party SFP Fixed an issue that caused clients to get stuck in an auth_pending status until the switch port the client was connected to was bounced Fixed an issue that caused switch stacks to learn MAC addresses from ports in the STP blocking state, triggering MAC flap messages in the event log Resolved an issue that prevented an active stack member from managing STP state on other stack members after the active member rebooted Resolved an issue that sometimes prevented stack ports from being correctly reconfigured after stack link flaps Ms130 fixed issues Resolved a bug that caused some MS130s to stop reporting to Dashboard while upstream switches reported UDLD issues Ms210 fixed issues Fixed a bug that caused MS210 stack port LEDs to incorrectly indicate an orange light rather than the expected green Ms220 fixed issues Fixed an issue that caused the packet capture files generated by the Local Status Page to be empty Ms355 fixed issues Fixed a bug that occasionally caused some MS355 switches to reboot Ms425 fixed issues Fixed a bug that caused high device utilization on MS425 stacks when multicast routing was enabled Resolved an issue that caused pNIC errors when forwarding some LLC packets General known issues If voice and data are configured to use the same VLAN DHCP discovery messages may not be correctly forwarded from client devices after being authenticated via 802.1x on the voice VLAN LACP links may take an extended time to come back up when the Active Member of a stack reboots RADIUS communications may not recover after an initial failure when Critical Auth is enabled Some clients may be incorrectly added to a configured Guest VLAN when authenticated via RADIUS immediately after a switch reboot Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard Switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switches unless the bundles are configured on the MS390/Catalyst switches first. All non-catalyst ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present) Ms120 known issues Some client devices may fail to authenticate via MAB in an access policy with hybrid authentication enabled, resulting in 802.1X authentication failures Switches may fail to provide PoE power to legacy access points (always present) Ms12x known issues] ms120/125s may fail to forward link-local multicast [224.0.0.x traffic when 'Flood unknown multicast traffic' is disabled Ms130 known issues MS130-X switches may experience slow upstream throughput when connected directly to an MX device via an mGig port Ms250 known issues Switchport with Multi-Domain Hybrid auth access policy randomly goes into a port not forwarding state Ms350 known issues Cable tests may fail to execute on mGig ports Enabling Auto-stacking on MS350s may remove existing L3 SVIs Ms35x known issues In rare instances, stack ports fail to initialize after an upgrade (always present) Incorrect SFP port mappings may disrupt SFP functionality Switches may experience an unexpected reboot (present since MS 15) Ms425 known issues In rare circumstances MS425 switches may encounter a software crash that results in a reboot In some circumstances ARP requests may not be correctly forwarded after connectivity is restored following an inter-DC VPLS DCI outage MS425s in stack configurations may periodically trigger New DHCP Server alerts that include mismatched VLANs/subnets Ms4xx known issues When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12) ... View more

CONGRATS to everyone participating. Meraki is winning. 💚 ... View more

Let's start off the with obvious this is a great add and I am thankful to see the additional information. That being said I feel like with the additional information we are able to see this could be combined with the current summary page and this would save admins the time of clicking back and forth.   New Tile   Device Summary Combine the following categories into one Block CPU Memory Power - Make smaller Power Mode - Make smaller AP Reboot  - Merge with Historical Connectivity Historical Connectivity - Tweak this bar to combine the alerts with AP Reboots, but use the same colors Radius and VLAN Status - Make smaller Uplink Traffic   Radio Summary  Utilization on current channel  Add Client count on each radio   Current Client Keep the same   Historical Device Data Keep the same   These are just my thoughts.   @RaphaelL - Thanks for posting about this release I missed it.   ... View more

How do we have a whole modern app for iOS with darkmode, but still don't have a simple palette switch for the dashboard in (nearly) 2025??? ... View more

Small update on this issue. FW 18.211.4 was stable and did not have the reboot issue. I've updated the MX to 19.1.6 and so far the issue hasn't returned.  ... View more

congrats everyone   ... View more

Ran into this last week and was a bit frustrated by the change. I have one org that's PDL and the subscription management process, with each device being on its own term, is preferable.    Have another customer that's basically "15 businesses in a trenchcoat" who would have benefited greatly from being PDL and had their renewal coming up, so I went to convert them, only to discover that the option no longer existed.    Some of their licenses are less than 6 months old (MR) and they balked at the price of renewing the entire org and the idea that they had to, given that some of the licenses were purchased quite recently. The argument was that they should only have to renew the devices with expiring licenses, which were for specific sub companies, and these could be billed as such (to each sub company), which I really couldn't argue with. I'd have converted them to PDR earlier if I had known it was going away, but apparently I missed this memo, which is my fault.  ... View more

Fixed...   Thanks for highlighting  🙂 ... View more

Security appliance firmware versions MX 19.1.6 changelog Important notice As of MX 19.1, Cisco Meraki will no longer support USB-based Cellular Failover on the MX and Z platforms. Legacy products notice When configured for this version, Z1 devices will run MX 14.56. When configured for this version, MX400 and MX600 devices will run MX 16.16.9. When configured for this version, MX64(W), MX65(W), MX84, MX100, and vMX100 devices will run MX 18.107.11. Bug fixes - general fixes Corrected a rare device reboot that could occur when BGP was in use. Resolved an issue that could cause eBGP routes learned over non-Meraki VPN tunnels to become unreachable after other device configuration changes were made. Fixed an issue that resulted in failover between non-Meraki VPN tunnels not occurring in some cases. Resolved an issue that could result in MX appliances incorrectly dropping traffic destined for AutoVPN peers for traffic that was received through the WAN interface. This occurred when the MX appliance was configured in passthrough mode and a default route was learned through eBGP. Resolved an issue that could result in MX appliances failing to establish an eBGP session with a peer on the LAN. This happened in configurations that used a route overlapping the IP address of the eBGP peer for failover and failback of non-Meraki VPN peers. Corrected a regression that caused traffic sourced by the MX to incorrectly follow the client routing table when a default route was advertised and multiple AutoVPN hubs were configured. This affected the MX's ability to establish an iBGP connection over AutoVPN, as well as impacting its ability to correctly route traffic such as NetFlow and syslog. Corrected an MTU issue that could result in MX appliances erroneously performing fragmentation of AutoVPN traffic after encapsulation had been performed. This occurs when the MX appliance is using an MTU other than 1500, such as 1230 or 1486. Resolved an issue that resulted in traffic shaping priorities not being applied correctly when default traffic shaping rules were enabled. Corrected an issue that could result in an unexpected reboot when an IPv6 DHCPv6-PD packet advertised a prefix of larger than /64. Bug fixes - limited platform fixes Corrected an MX 19.1.4 regression that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances encountering an unexpected device reboot when processing a large volume of network flows. Fixed other circumstances that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continually operating at 100% device utilization. Corrected a regression that resulted in being unable to perform a factory rest on MX95, MX105, MX250, and MX450 appliances. Resolved an issue that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances dropping traffic destined to itself when the traffic was received over AutoVPN. This could cause a lack of response to things like an SNMP walk sent over AutoVPN. Fixed an issue that could result in GRE traffic being incorrectly dropped by MX75, MX85, MX95, MX105, MX250, and MX450 appliances when using a 1:1 NAT and the traffic path was a “hairpinned” NAT. Corrected an issue that resulted in ​​Z4(C) appliances failing to forward ARP messages that had a VLAN tag, even when the VLAN tagging correctly matched with the Z4(C)'s port configuration. Fixed a rare issue that could result in unexpected device reboots for MX67(W), and MX68(W,CW) appliances operating under heavy network load. Fixed an issue that could result in the ping live tool failing when trying to ping an IPv6 IP address over a cellular uplink. Fixed an issue that could result in port forwarding rules for integrated cellular modems not working after a device reboot was performed. Fixed an issue that resulted in vMX appliances running on Cisco UCS servers failing to upgrade to MX 19.1 versions when the vMX appliance was running a version older than MX 17. Further resolved cases where MX68(W,CW) and MX85 appliances could improperly attempt to provide PoE power to connected devices. Known issues During the upgrade process, MX appliances upgrading from versions prior to MX 19 may experience a failure to properly classify traffic. This issue will be resolved once the appliance has completed the upgrade to MX 19. Z4(C) appliances fail to properly forward STP frames received on its LAN interfaces. Other MX appliances will now use the IP address of their highest number VLAN as the NAS-IP in RADIUS Access-Request messages. The local status page will no longer display fields related to the cellular modem when no SIM card is present in the MX. Reduced the power consumption of MX67(W), MX68(W,CW), MX75, and MX85 appliances in some cases. ... View more

Hi Alexis    We are also having the same issues and according to Meraki Support you cant Transfer between Org's with the New Subscription Model .   Just checking in if you have found a way around this without doing a RMA or Splitting the Dashboard Keys ?   Regards   Barry  ... View more

Hi, As regards the following item: In rare cases, MX67C, MX68CW, and Z3C appliances may fail to enter into a "Ready" state despite being able to register to a cellular network and obtain an IP address for the modem. Seems it may also need to include Z4C's as well, as seems to have been allocated IPv4 and IPv6 addresses, but not showing as Ready: Seems to be up, but not really 100% sure. ... View more

Wow, not even WPA2! ☹️ ... View more

  It does take time to display the correct information. I've noticed more lag in the new version of clients connected dashboard.The online/offline status of wireless clients will depend on their connection to a Meraki wireless network.   ... View more