Meraki

cmr

It went as it needs to be completed...

cmr

Because it did seem to work well for me! I must admit the mobile app isn't the best, but I just use the website on desktop mode as I have good eyesight and a big phone!

cmr

Is it licensed, or in trial mode? How is it powered, if PoE is it a powerful enough injector/switch? How do you know it isn't broadcasting?

cmr

I'm loving the phrase Distribution Witches, it perfectly describes the issues we all sometimes see on the LAN 😉

cmr

I actually think there needs to be three levels. manage operate view I have several users who I want to be able to run cable tests, bounce ports, take packet captures etc. but not change things so with the current admin and read only, I'm happy for them to have the role. I wouldn't give someone access at all if I was worried about them bouncing ports for fun.

cmr

@chrisautomates also remember that the 9300Ls and possibly the 9200Ls don't come with the stacking ports, they have a motherboard header, but you need to buy the actual port separately for quite a lot. The benefit is that they do have the SFP+ ports on the end and you don't need to buy a module for them, as you would with a 9300. Lastly the annual licence for the 9300(L) is quite a lot more than the MS225,

cmr

No more dark mode 😢 Hopefully it won't be like the port page for MXs that lasted about a day and still hasn't come back several years later...

cmr

It seems okay for me in Edge, it even displays the disabled ports properly that the dark hack in Edge/Chrome had problems with. What browser are you using?

cmr

Just wait more years and the option will be there 😉

cmr

Just go to Profile -> Theme Oh wait, there is no Profile -> Theme... Hopefully we don't need to wait a few more years for the GUI setting to show up!

cmr

I've used the Rapid7 log solution, the data is stored in their cloud, but they have on premise collectors to ensure data integrity.

cmr

Where is the 🤣 emoji!

cmr

Hmm, so not even the latest 31.1 firmware...

cmr · Re: A new beta wireless firmware is now available on Wed, 01 Oct 2025

Wireless firmware versions MR 32.1.4 changelog Important note MR45/55 APs are not supported on MR 32.x.x and will instead upgrade to the backup version (MR 31.1.8) if they are in networks configured for MR 32.x.x versions, and thus, new features will not be available. Bug fixes General stability, performance, and experience improvements APs intermittently stop sending beacons & responding to clients on 5GHz (Wi-Fi 6e) APs not responding to probe/auth requests from clients on 2.4 & 5GHz (Wi-Fi 6, 6e) Multi/Broadcast packets (RA/DHCP) not forwarded by APs (Wi-Fi 7) Mesh not forming 6GHz 160MHz (Wi-Fi 6e)

cmr

That sounds like a great idea, I'd definitely support this for sites where auto RF just won't do.

cmr

If you want the MS250s to be the distribution then they need to be L2 only. The L3 routing would need to be done inside the 9300L VRFs. Combine this with NAT on the 9300L for egress to the MX and it could work as you have enough ports on the MX for one pair of ports per 9300L VRF with each port in a separate VLAN on the MX, but it would be one hell of a horrible setup to try to support.

cmr

Apologies there, I misread the notes and went down the wrong rabbit hole! Either way it isn't fixed yet, so best to restrict, or turn off SNMP!

cmr

And for clarity, this release is based on 17.15.4 and the fixed release is 17.15.4b

cmr

As the CVE state is currently this: Workarounds: No workarounds available I would suggest that if you have SNMP enabled on the switches, it is vulnerable. The beauty of Meraki is most networks I have dealt with don't need the additional monitoring of SNMP as the dashboard and APIs provide enough detail. In that case SNMP is disabled so the switches should not be vulnerable.

cmr

As devices connected to the MDF stack are experiencing the problem, I cannot see how the 10Gb downlinks to the IDF are having an impact. If you have the MXs connected to more than one switch each, then disconnect the second connection. The other things you want to try all sound sensible and I would try them afterwards if the above don't help.

cmr

CS firmware versions CS 17.2.3 changelog Important notes This version's IOS XE image is based on 17.12.4 CCO. Upgrades to this version will result in a full system reload. New feature highlights EEE (Energy Efficient Ethernet) Support RADIUS Caching Device Uptime for MS390s Multi-auth with support for guest/failed/critical VLAN to SGT mapping Client Analytics (parity) Support for Multicast in Live Tool Fixed issues Resolved a bug that occasionally caused the Meraki container to reboot and temporarily lose Dashboard connectivity Fixed a bug that sometimes caused longer than expected boot times, and in very rare circumstances could cause switches to fail to communicate with Dashboard General known issues Client traffic reporting may fail on high-speed (greater than 10Gbps) or trunk ports C9300 known issues In rare circumstances, high levels of MAC flapping can lead to memory exhaustion in C9300X switches in stack configurations. An iosxe restart is required to restore service to affected switches. Ms390 known issues MS390s may display an alert, "A power supply is offline" when a PSU isn't installed in the second slot Clients may fail to obtain a fixed IP address if their DHCP discover packet doesn't contain a client identifier field. These clients will instead be assigned an IP address from the DHCP pool.

cmr

CS firmware versions CS 17.2.3 changelog Important notes This version's IOS XE image is based on 17.12.4 CCO. Upgrades to this version will result in a full system reload. New feature highlights EEE (Energy Efficient Ethernet) Support RADIUS Caching Device Uptime for MS390s Multi-auth with support for guest/failed/critical VLAN to SGT mapping Client Analytics (parity) Support for Multicast in Live Tool Fixed issues Resolved a bug that occasionally caused the Meraki container to reboot and temporarily lose Dashboard connectivity Fixed a bug that sometimes caused longer than expected boot times, and in very rare circumstances could cause switches to fail to communicate with Dashboard General known issues Client traffic reporting may fail on high-speed (greater than 10Gbps) or trunk ports C9300 known issues In rare circumstances, high levels of MAC flapping can lead to memory exhaustion in C9300X switches in stack configurations. An iosxe restart is required to restore service to affected switches. Ms390 known issues MS390s may display an alert, "A power supply is offline" when a PSU isn't installed in the second slot Clients may fail to obtain a fixed IP address if their DHCP discover packet doesn't contain a client identifier field. These clients will instead be assigned an IP address from the DHCP pool.

cmr

Do you have them on their own WPA2-PSK SSID, 20MHz, 5GHz only, all roaming options off? That's what we did to get them good and reliable.

cmr

Here is a link to the documentation, MXs aren't on the not allowed list: Organization Split Overview and FAQ - Cisco Meraki Documentation

cmr

Is it a new Organisation, or does the organisation already have Meraki networks configured? If it is then split the current combined network into constituent parts, re-combine the non-MX networks if you want to and then ask support to move the MX network to a new org with the license. I'm pretty certain they will do that.

About cmr

cmr

Community Record

Badges