As long as it is 5/6 then I'm okay with that.  If Cisco release a new AP that is 2.4/5 only then they deserve to fail, so I really hope nobody is that stupid! 🙏 ... View more

Security appliance firmware versions MX 19.2.4 changelog Important notice As of MX 19.1, Cisco Meraki will no longer support USB-based Cellular Failover on the MX and Z platforms. Starting with MX 19.1 firmware on vMX platforms, Meraki has begun to deprecate the use of 3DES encryption for Phase 2 (IPsec) of Client and IPsec VPN connections due to its insecure nature. Subsequent firmware releases will continue to deprecate it on all platforms. Executive summary This is a routine maintenance release and the latest generally available release for MX 19.2. It contains a variety of fixes including AnyConnect reliability improvements, setting the NAS-IP address parameter in RADIUS Access-Request messages, and more. Please read through the full details below. Bug fixes - general fixes Corrected an issue that could result in MX appliances reaching out to Cisco Umbrella endpoints even when the Cisco Umbrella integration was not enabled. (MX-11668) Corrected an issue that could result in an incorrect DHCP lease count in the Meraki Dashboard when a client roamed between multiple VLANs. (MX-16553) Resolved an issue that could result in duplicate Client VPN authentication event log messages being posted. (MX-35150) Corrected a rare issue that could cause a temporary disruption of traffic over AnyConnect VPN for 1-2 minutes. (MX-37126) Resolved a rare issue that could result in AnyConnect VPN connections failing to form. (MX-40793) Bug fixes - limited platform fixes Fixed an issue that resulted in Z4(C) appliances forwarding traffic destined for the appliance out all LAN ports. (MX-43696) Fixed an issue that resulted in Z3(C), Z4(C), MX67(C,W), 68(W,CW), and MX75 appliances incorrectly using 127.0.0.1 as the NAS-IP address in RADIUS Access-Request messages from 802.1X port authentication. (MX-26058) Resolved an issue that resulted in Z3(C), Z4(C), MX67W, and MX68(W,CW) appliances incorrectly using 0.0.0.0 for the NAS-IP address in RADIUS Access-Request messages from WPA2 Enterprise SSIDs. (MX-39732) Legacy products notice When configured for this version, MX64(W), MX65(W), MX84, MX100, and vMX100 devices will run MX 18.107.13. Known issues status This list is being reviewed and updated. Other The product complies with EN 18031-1:2024 and EN 18031-2: 2024 ... View more

CW9171 - that might finally deliver on the promise of many small 6GHz cells to fully realise the benefits of the band. ... View more

I'm guessing it came with the new page as I can see here it no longer complains.  However I also see domain name is listed along with option 3 (router).   ... View more

Thank you, I will try it on 17.18.1, but it was on the CS versions that I never got it to work!  ... View more

@JustinBennett which firmware was this on? ... View more

It did help me with how to do something, I cannot remember now what it was, but I posted here when it happened. ... View more

I was more thinking of comparing against other manufacturers, Cisco does seem to have this side of things down to a tee. ... View more

Perhaps you had video like a drunk uncle at a wedding? ... View more

On another note, looks like dark mode has returned for me 😎 ... View more

What do you have on this screen? Also what firmware are you running and what speed and duplex is the connection to the switch, or is it wireless ... View more

Camera firmware versions MV 7.1.2 changelog New New MQTT Topics for Advanced People Counting General Resolved stability issues affecting video recording and motion detection Notice When configured for this version, MV21 & MV71 cameras will run MV4.15 ... View more

I've always used either the SFP(+/28) ports or port 1 for uplinks, no idea why, but it looks like a good plan now 😂  ... View more

@DarrenOC explained the other issue.  The way CS firmware works is that there is a traditional IOS-XE firmware underneath, with the Meraki management code running in a container on the 'master' switch.  When one goes down it has to fail this over to another switch and I believe this effectively means starting a new container on the other switch, or at least a sleeping container waiting for a timeout before waking up. ... View more

The MS150 reminds me of the early MS390 at the moment.  Lots of basic stuff not being reliable.  The last one above just looks plain odd! ... View more

Switch firmware versions MS 18.1.3.1 changelog New feature highlights Group Policy ACL on MS130 & MS150 Maximum MAC support in MAC Allowlists 802.1x limited access mode with pre-auth GPACL Local Status Page connectivity diagnostics enhancements Layer 2 multicast live tool Traffic Mirroring: RSPAN & VLAN Based SPAN General fixed issues Fixed a bug that sometimes caused switches in stack configurations to fail to remove older entries from the MAC forwarding table Ms150 fixed issues Resolved an issue that caused some wireless clients to lose connectivity when roaming between access points connected to different members of the same switch stack Fixed a bug that sometimes caused MS150s to experience transmission errors and lose connectivity until they were rebooted Ms425 fixed issues Resolved an issue that caused clients authenticating via 802.1X with an access policy using hybrid authentication to not correctly log their RADIUS sessions Fixed an issue that caused some switches in stack configurations to experience high CPU utilization in multicast scenarios that sometimes resulted in network instability General known issues MS130 and MS150 switches may not properly display IPv6 RA packets in dashboard packet captures MS130 and MS150 switches may incorrectly remove or update SGT tags when no policy or VLAN mapping is defined. Until a firmware fix is available, correct SGT tags can be preserved by defining a policy for the SGT group in Adaptive Policies, and binding the SGT group to a VLAN using VLAN profiles. In rare circumstances switches may experience uplink instability when IPv6 link-local addresses are enabled. If this issue is encountered it can be resolved by enabling IPv6 RA Guard to block ICMPv6 neighbor discovery messages. Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard Ms120 known issues Switches may fail to provide PoE power to legacy access points (always present) Cable tests may report incorrect cable lengths Ms150 known issues Some SFP and QSFP modules may experience intermittent flapping on MS150 switches running MS18 firmware MS150 switches in stack configurations may lose connectivity while reporting redundant uplinks as blocked. As a workaround, connectivity can be reestablished by disconnecting the impacted redundant uplink. MS150 switches in stack configurations may incorrectly flood unknown multicast traffic despite the flood unknown multicast setting being disabled 48 port MS150 switches connected to an MX gateway may experience a reduction in uplink throughput if the uplink is on ports 45, 46, 47, or 48. As a workaround, connecting to the MX using ports outside of the 45-48 range will pass traffic at expected speeds. Ms225 known issues MS225 switches may infrequently stop forwarding client traffic until the switch is rebooted Ms35x known issues Switches may experience an unexpected reboot (present since MS 15) Ms355 known issues Switches in stack configuration may experience some ports failing to reconnect after a firmware upgrade Ms410 known issues Some MS410 switches may encounter alerts for fan failures that will eventually self-resolve Ms425 known issues In rare circumstances MS425 switches may encounter a software crash that results in a reboot ... View more

I think your issue is the second one here from the release notes, isnt it?   General known issues Client traffic reporting may fail on high-speed (greater than 10Gbps) or trunk ports Link aggregates may take some time to be reinitialized when a switch stack failover occurs. During this time traffic traversing the link aggregate will be interrupted. ... View more

@Ryan_Miles in subscription licensing, doesn't Essentials equal Advanced in co-term licensing, with Advantage equalling SD-WAN+?   If so then the adage of being unable to mix Enterprise and Advanced still holds true.   Or have I gone completely mad?! ... View more

!00% what @PhilipDAth says.  All IoT equipment, such as printers, smart lights, door access control, CCTV (non Meraki) etc. should be placed in separate VLANs and access from those VLANs to other VLANs should be minimised. Access from those VLANs to the internet should also be minimised.   It does take a little extra time to set up, but is well worth it in terms of reducing the attack surface of your site(s) and the possibility of data exfiltration by likely unmonitored devices. ... View more

You can order the hubs so that the main site is at the top of the list and the DR site is second on the list.  This was all connections should go to the main site unless it has a problem. ... View more

Adding to what Philip said, make sure the power levels are not too high, a client should not be seeing 8-10 APs at the same time! ... View more

Do you have the appropriate sites listed inside the walled garden for apple devices to connect to their cloud? ... View more