You can review the source IOS XE RNs here: https://www.cisco.com/c/en/us/support/ios-nx-os-software/ios-xe-17/products-release-notes-list.html While IOS-XE features do not directly map to Meraki any new features added in 17.10, 17,11, and 17.12 would  now exist in the base code and be able to be Merakified if desire existed.   Important notes This version's IOS image is based on 17.12.3 CCO. Upgrades to this version will result in a full system reload. New feature highlights Client Analytics Device Uptime for MS390s EEE (Energy Efficient Ethernet) Support (API Only) Multi-auth with support for guest/failed/critical RADIUS Caching VLAN to SGT mapping General fixed issues Fixed an issue that in some circumstances prevented switches from restoring a safe configuration after incorrect configuration had been applied (i.e. disabling uplink) Fixed an issue where an event with system information could be generated when a support data bundle was created Ms390 fixed issues Resolved an issue that could prevent link aggregation configuration from being applied when the active member rebooted in an MS390 stack configured for cross-stack link aggregation General known issues MS390 stack configuration may experience high memory consumption and as a result could lead to authentication failures. Reloading the active switch clears the issue temporarily. MS390 stacks may fail to apply new configurations fetched from the network. This results from an issue with the NETCONF application, leading the system to revert to the previously stored configuration. Meraki native switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 or other Catalyst switch unless the bundles are configured on the Catalyst side first. All Meraki native ports are configured in passive LACP mode so that loops do not occur between Meraki native switches (always present) Switch Port Packet Counter live tool shows 0 packets on uplinks for all fields except for Live Data Ms390 known issues MS390 stacks may experience an unexpected reboot when both active and standby EHSA are down ... View more

We are getting random 403s when running GetOrganizations in some of our API apps. The 403s are coming from an org that we recently got access to that has IP restrictions on it. We can not change that orgs settings. I've found a few posts in the past about similar issues when one org had license issues.   I'm presuming I'm going to have to open a support case, but curious if anyone else has seen this. ... View more

Has anyone else experienced this? Example MX is set to VLANs and has one or more VLANs defined. (May also happen with Single LANs I just don't ever set them up that way) Static Routes exist pointing other subnets across that VLAN to another layer 3 device. I make sure all dependencies for the statically routed subnets are gone/disabled (DHCP, firewall rules, etc) I try to change the VLAN on the MX and the static routes at the same time.  MX gives error saying the static route has an invalid next hop and lists the old next hop IP. This used to work, but I've seen the error multiple times over the past few months. It seems the order of operations or validation criteria on the backend have changed. I intend to open a case but was just wondering if anyone else has noticed. It's just a few extra steps but deleting also loses the DHCP info that I would usually just edit instead of having to recreate. And before anyone asks Templates are not an option for us.     ... View more

It's still replicating on Shards but I just got a bunch of push notices, I'm going to guess the SSL update mentioned is a result of a CVE or similar and part of the reason for the rapid push. Important note While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the "Help" > "Firewall Info" page is allowed through any firewalls or security devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs) WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs) Legacy product notice When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3 Bug fixes General stability and performance improvements AP not returning to original channel after a DFS channel change event (MR45/55) Clients failing to get IPv6 address with high bcast/mcast traffic (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Acct-Output-Gigawords in the accounting packets not increasing when they should (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Multiple DHCP servers detected when clients use DHCP relay (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Large mDNS packets can cause loss of wired connectivity (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) MA-INJ-6 provides 802.3at power, not 802.3bt when connected to switches that provide PoE, but are not MS390 (Wi-Fi 6E APs) User-Name and Calling-Station-Id in different format consuming additional license on ISE (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Air Marshal syslog messages sent without detailed information (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Fix channel width support for El Salvador (Wi-Fi 5 Wave 2 APs) Fix 6 GHz regulatory issue with Saint Martin (MF) (Wi-Fi 6E APs) UNII-3 channels not available in France (CW9166I-MR) Incorrect Country Code in 6 GHz Beacon/Probe Rsp in some EU countries (Wi-Fi 6E APs) Characters with diacritics truncated from SSID names in RADIUS accounting/access request packets (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) 'tcpdump' filters not working on wired interface when Adaptive Policy is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) UDN ID not properly assigned to clients for "iPSK w/ RADIUS" configuration (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Incorrect IPSK-EAPOL VSA data for Easy PSK (Wi-Fi 5 Wave 2 APs) Exclude Beidu/GLONASS constellations from GNSS receiver when used for AFC location (Wi-Fi 6E APs) 6 GHz radio not turned off when AFC expires (CW9163E-MR) APs utilizing WPA3 are shown as "Open" in RF Spectrum > Interfering APs UI (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Clients using 160 MHz channels reporting 20 MHz channel width use (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) Clients getting dropped before DHCP lease time expiry during L3 roam and disconnected for more than 30 sec (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) WiFi 6/6E failed to change channel High VoIP jitter during longevity tests Enhancement Add 6 GHz support for regulatory domains with new 6 GHz approvals (Wi-Fi 6E APs) Keep 6 GHz radio off for outdoor APs when no configuration provided (CW9163E-MR) Upgrade CiscoSSL from 7.3 to 7.3a Known issues Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) In high capacity wireless networks, APs may experience instability when the “Client Balancing” feature is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) ... View more

Edit: I can see the full notes now and and am pasting. Original post still below for history of this breaking news 🙂   What's new Significant performance improvements for MX85, MX95, and MX105 appliances. Bug fixes Resolved an issue that resulted in Event Log data not being generated for all clients of MX75, MX250, and MX450 appliances. Corrected a rare issue that could result in large numbers of routes causing network instability during AutoVPN connectivity changes. Fixed an issue that could result in some clients being unable to access WAN resources when MX75, MX250, or MX450 appliances were configured with a PPPoE uplink. Fixed an issue that resulted in MX appliances failing to initialize a service required for encrypted communication with Umbrella. Resolved a rare issue that could result in SFP+ ports on MX250 and MX450 appliances unexpectedly toggling between up and down states when forwarding incorrectly sized MDNS packets. Corrected an issue that could result in IPv6 dynamic prefixes from WAN1 not being installed into the MX routing table. Fixed a rare issue that could result in AutoVPN traffic being routed incorrectly after an uplink failover or failback when 1) the MX appliance was configured to operate in High Availability mode (HA), 2) a virtual IP address was used, and 3) a teleworker VPN was configured. Resolved an issue that resulted in MX68(W,CW) failing to negotiate PoE power at 802.3at Corrected an issue that resulted in Z4(C) appliances being unable to change to a DFS channel after having previously used a non-DFS channel. Fixed an issue that resulted in MXs appliances incorrectly modifying the source IP address of ICMP time-to-live exceeded messages when routing them between VLANs. Additional changes to increase the robustness of connectivity and self-recoverability for integrated cellular modems. Corrected an issue that could result in reduced performance on MX75, MX85, and MX95 appliances when IDS or IPS was enabled. Fixed an issue that could result in MX appliances failing to populate the ARP table live tool. Resolved an issue that resulted in MX appliances failing to receive an IP address on its WAN interface when DHCPv6 over a PPPoE uplink was used. Corrected an issue that could degrade the performance of traffic destined to and sourced by MX appliances when 1) IPv6 was enabled, 2) BGP was enabled, and 3) there were over 1024 AutoVPN peers. Resolved an MX 18.2 regression which caused MX appliances to summarize AutoVPN routes advertised through BGP without being configured to do so. 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.8. Known issues status This list is being reviewed and updated. Many existing issue reports have not been confirmed to affect MX 18.2XX firmware versions. Known issues There is an increased risk of encountering device stability and performance issues on all platforms and across all configurations. Other Control traffic for Meraki authentication will now only be routed out the WAN interface(s). Previously it could be unintentionally directed out other interfaces, based on the routing configuration. ORIGINAL POST: Just got a ton of emails on a mystery 18.208 upgrade being pushed. Dashboard says: Other Custom MX 18.208 version Please contact support for more details.   The email says Significant performance improvements for MX75, MX85, MX95, MX105, MX250, and MX450 appliances.  My emphasis in bold, as many of us know the bolded models have not been announced as getting performance updates with this release. The rest of the email info seems to match what we do know about 18.2XX.  A recent forum post says the other models are on the to-do list but no ETA. Anyway, I'm on hold with a confused support engineer and will update if he says anything useful, but wanted to let folks know.   ... View more

It would be really really really nice if you tied the display of these to whether the admin logged in had said not interested vs as a per org setting.    Seeing them over 100 times in different orgs and having to dismiss them is painful.   ... View more

One of my reps just pointed this out to me: https://documentation.meraki.com/MX/MX_Sizing_Information/MX_Sizing_Principles#Performance_Data   Full Gig with Security Services on an MX75!   The MX85 has become a very confusing SKU at the moment. MX75 exceeds it in all BW categories but is lesser than it for maximum clients/vpns and related specs.   I'm hoping this is a chipset difference thing that was coded for one set of SKUs and is still in progress otherwise. ... View more

Important note While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the "Help" > "Firewall Info" page is allowed through any firewalls or security devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs) WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs) Legacy product notice When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3 Bug fixes General stability and performance improvements Known issues Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs) In high capacity wireless networks, APs may experience instability when the “Client Balancing” feature is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs) ... View more

https://documentation.meraki.com/MR/MR_Installation_Guides/CW9163E-MR_Installation_Guide   The marketing pages haven't posted yet on cisco.com or meraki.cisco.com (it's dual identity) but it's available to order.   A number of caveats with regards to 6Ghz actually running because of regulatory stuff, Details in the doc.   Regardless, if you are working on outdoor coverage you can at least be a little bit more forward ready now and have the hardware. ... View more

Important notes 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. While Meraki switches have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MS 15.1+ we are beginning a transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the Help > Firewall Info page is allowed through any firewalls or security filtering devices that may be deployed upstream of your Meraki switches. These requirements have been updated on Nov 2022, so it’s important that you review them. MS 15.23 is the same as MS 15.22 for all models except the MS130 switch models New feature highlights IPv6 management interface support Ms130 fixed issues Cable length is reported as double the actual length during cable tests in some scenarios (always present) Cable tests may fail on non-mGig ports (always present) If a device is rebooted in quick succession, ports may fail to initialize correctly resulting in packet loss (always present) Devices may be provided incorrect firmware download URLs resulting in firmware images failing to be downloaded and devices remaining on the prior release General known issues Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12) 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) In rare instances, the port status will fail to update to dashboard until the system reboots (present since MS 14) Ms120 known issues Switches in extremely rare instances upon reboot will experience persistent reboots every few minutes, failed firmware upgrade, or fail to reconnect with dashboard (present since MS 11) Switches may fail to provide PoE power to legacy access points (always present) Ms125 known issues The local status page cannot be accessed from the management port (always present) Ms12x known issues Ports with an odd-numbered MTU value fail to initialize (predates MS 11) 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) Ms2xx/35x/4xx known issues Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage of up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10) IPv6 multicast packets tagged for a VLAN may not be filtered correctly resulting in packets egressing into other VLANs (present since MS 14) IPv6 solicited-node packets bypass port isolation (present since MS 14) Rebooting a stack member may result in internal stacking packets being sent out into the LAN (present since MS 15) SVI default route can be incorrectly removed from the routing table after L3 changes are made on dashboard. Removing and re-adding the route is required to resync the stack (present since MS 15) Stack routing tables can get out of sync when L3 changes are made. Making an additional change to L3 can resolve the sync issue (present since MS 15) 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 Ms355 known issues In rare instances, stack ports fail to initialize after an upgrade (always present) Ms35x known issues Enabling Combined Power results in events being logged once per minute (present since MS 11) UPoE does not negotiate over LLDP correctly (always present) 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. Ms425 known issues Large number of SNMP walks to switches in H.A. may destabilize the VRRP connection resulting in flapping (present since MS 15) Stacks in rare instances will start dropping DHCP traffic on trusted ports while DAI is enabled until rebooted (present since MS 12) 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