These are the things we did that finally brought stability to our MS390's. We are running 14.32   1. Completely isolate spanning tree on Meraki network from any Catalyst PVST spanning tree using BPDU filters on the catalyst side and turning off RSTP on interfaces connecting to catalyst from the meraki side. Catalyst and Meraki STP do not play nice together on the MS-390.  2. After any L3 SVI changes (Adding removing, or moving VLAN subnets), reboot the entire stack. Other MS390 stacks on the network may need to be rebooted too. We just wait till the evening and reboot ALL of them. This is a known issue. 3. After updating to 14.32, make sure to reboot the MS-390 stack TWICE from the Meraki console. (Not just pulling the plug. FROM THE CONSOLE) The switch will take a long time and some strange lights will flash during one of the reboots. We suspect some type of firmware/rommon update is being applied quietly. But t6he switch will not apply this if you just pull the plugs or cycle power. it has to be a graceful from the console reboot to trigger it.   After all of this, they quit dropping off the console and have been relatively stable.   We also found in some cases with clients application layer firewall filtering on Palo Alto, Checkpoint,  or FortiGate was causing issue with blocking management plane traffic to the cloud. Make sure the switch IP;s are exempt from any IPS/IDS or L7 firewall filtering or expect problems.    If you are using these as Data Center switches in a hosting environment where constant layer three changes are being made, you may want to consider Ronnies advice and get them swapped for native Meraki switches as the constant rebooting may be unpalletable. ... View more

so one thing we did to fix this issue is we noticed some things going on under the hood regarding the latest firmware. If you are running 14.32, make sure to reboot the stack TWICE from the meraki console. It HAS to be done from the Meraki console. You can't just yank the power plugs.on the second boot after the firmware update is applied, the reboot takes MUCH longer and it appears as if some kind of microcode update is applied. We noticed if you do this, then the switches quit dropping off the cloud console. ... View more

I sus[pect a lot of folks are having resume moments for buying into these. ... View more

we had similar issues except it was with Catalyst 4506E chasis running IOS XE.   If you want the 390's to work reliably, do this.   1. Allow no spanning tree interactions between the 390 stack and any catalyst switches. We also tried MSTP and it just did not work. This means RSTP off on any ports that connect to catalyst on the meraki side and BPDU filters on that connection on the cat side. 2. If the MS390 stack is doing the routing, then any time you make a L3 change on that stack, like adding an SVI, reboot the whole stack. We found doing this makes the switches work correctly. Usually an L# change would take ours down and have them acting in a very bizarre fashion. 3. Use the latest firmware. They just pushed 14 to stable and already have v 15 in beta with regular updates. We have found the stability and functionality get a lot better with each update. But we also discovered sometimes you will need to reboot the switch more than once after a firmware upgrade. We found sometimes after an update the switch would reboot mutiple time son its own as it were doing microcode and ios XE updates under the hood. but deferring to later reboots to do other things. 4.Hard code spanning tree topology using priorities in switch settings. Set roots, then next layer down 2nd tier , 3rd tier etc. Don't leave this up to chance. 5. Don't use VLAN 1 as a data bearing VLAN. ALso prune vlan 1 of any trunks. ... View more

I agree 100%. I would love to have all these features in a 390, but don't risk my career by making me have to explain to my customer why this turd doesn't work. especially for the ridiculous price of these switches compared to Aruba or others. Only sell it when it actually works! ... View more

These clients are very large deployments. Think hundreds of MS390 switches. With thousands-tens of thousands of host connections. And these are large public institutions in the public eye. I can't say anymore than that. ... View more

Unfortunately my management is going to continue with this believing the code will get straightened out and it will future proof the customers for "new features" that the existing Meraki hardware won't support. meanwhile over the weekend one client had an entire stack go offline Saturday and they had to reboot them to get them back online this AM. ... View more

Has anybody considered a class action lawsuit on these switches? They were essentially sold on false pretenses before they were fully functional. Meanwhile my license time is ticking away while the switch is not working. Has anybody at Meraki considered extending license periods WHEN they become more functional? Or some kind  of replacement trade in program? These switches have been a disaster for my customers and left a very bad taste in their mouths regarding future Cisco purchases.  ... View more

I second this. I need this info for some more than 10k remote sites to know if I need attenuators with ER SM optics..... ... View more

Oh god. What have ours NOT done?! LOL random stack member reordering out of nowhere, random issues with stacking if you have a catalyst network with RPVST+ enabled (We had to shut off BPDU's between the merki network and the catalyst network and put them in separate STP domains isolated from each other.) Random links in the stack would get blocked and not connect if the STP was left on with the catalysts networks. No QoS support, L3 changes requiring reboots of entire stacks. Even with the updated beta firmware reboot times are insane.Having to make consideration for order of changes because of the necessity to only being able to configure layer 3 while being cloud connected. I could  ramble on for HOURS about the nightmare thess switches have been. And the worst part is being meraki, it's a BLACK BOX. You have almost ZERO ability to debug these things like you could with IOS. If I had a CLI and  debug, I could figure out what is wrong in 10 minutes. And if I had access to the IOS fix it in 5 minutes. But these switches are sold as the idiot boxes with idiot lights and an idiot GUI to CEO types. Just plug them in and they just work! Get rid of highly trained highly paid network staff and hire a high school kid to run your network! And it would work that way if they actually worked. Unlike the MS390. I'm probably being hyperbolic and letting my frustration with these things show. The meraki system was designed for medium to branch office stuff. not enterprise level switching. Unfortunately a lot of us engineers get stuck with technical decisions CFO types make these days. And any time you dangle cutting expensive IT head count out the CFO will bite. So we get to try to work around half baked MAeraki products. ... View more

MS390 - hahahahahahahahahahahahahahahahah   OK sorry. I have been living the nightmare of trying to get these switches to work reliably for over a year now.   I'm so frustrated with these things I could throw them in the trash too.   As I sit here now one of mine is flashing yellow claiming a vlan mismatch. If you check the port it has two cdp entries on it. Used  a packet sniffer and the port is only getting CDP from one device. And the VLANs match.   All the support engineers who have dealt with my tickets are ready to throw these switches in the trash too.    If I could load IOS on them I would do that in a  heartbeat. ... View more

It would depend on the criticality of what is going on the switches. Currently they are not stable enough for use in situations with servers or large traffic loads for us. They are relegated to being access layer switches for the time being. Frajnly we have been trying to figur eout what th eplan is here with regards to Cisco and these switches. It is pretty clear to me that the switch is running Catalyst IOS XE natively and the Meraki software is running in an IOS XE VM to provide the "Meraki" interface. Basically with the Meraki software VM acting as a "thunking" layer. I have verified this with Meraki support folks who had access to the catalyst stuff going on underneath for debugging purposes for some of our open tickets. Issues we had included problems with Stacking, stack members randomly reordering themselves, stacks requiring reboots for layer 3 SVI changes to take effect, issues with QoS, the 1000 vlan limitation issue, and issues with STP compatibility between catalyst IOS switches and the meraki switches. When doing forklift network upgrades for campuses, we have been having to build entire parallel networks back to the firewall to isolate the STP from the old catalyst STP or you get all kinds of weird stacking problems.   I come from a CCNP background and I have scoffed at our management's attitude that somehow this stuff is the future of networking. We deal with a lot of clients who have high turnover low skill set engineers due to low wages and living in rural areas. (Think government workers.) So they bought the Kool-Aid on this we can avoid fixing our HR problems and paying real salaries by getting this "Anybody off the street can build a GUI network" kit. The actual old Meraki hardware has been relatively trouble free. But having to debug a buggy beta product foisted on the masses with no actual debugging tools becasue they are hidden has been a HUGE time suck. Our early projects were regularly over budget and late due to trying to debug these things. Once you know the tricks like:   1. Isolate the STP instances from any Catalyst STP 2. Upon brining up an MS390, set all ports to access and VLAN 1 to avoid the 1000 vlan problem when connecting to switches that pass all vlans rather than a subset on trunks.  3. After making MS390 L3 changes reboot the stack to make sure things take effect. 4. Bring a magazine and some coffee to pass time while the switches are booting up. Bring a book if you are doing things that require multiple reboots like firmware updates.   My speculation having worked for government and large outfits is a very large company was working with cisco on a very large business deal. This deal probably stipulated port requirements, power requirements, feature requirements, or redundancy requirements that existing Merki hardware could not provide. So to not lose the contract, Cisco got a couple of engineers to hack together this kludge so they could be a merki solution but meet the hardware requirements. And once it was done they started selling this to the general public. But yeah the view here is this thing is still Beta. ... View more

No. None at all. right now I brought 4 of them home. As I thought the old catalyst network of the client may be causing STP issues or something. Even here at my house stacking is spotty and there is no consistency in what isn't working vs swapping cables or switches. It seems to be random. ... View more

HA! I'd be happy just to get a #$%^& MS390 to form a stack correctly without missing stack ports in the dashboard. I'm not even worried about advanced features on the 390. I just want the basic ones to work! ... View more

Ok. So I did some experimenting yesterday. This is what I found which I thought was odd.   I set the management IP in the IP settings for the switch. I configured it to DHCP and set management vlan to 2009. Saved config and waited.   I got the error alert that the switch was DHCPing an address instead off VLAN1.   I then went into the Switch/configure:settings and set the management VLAN to 2009. I thought it was odd the setting was not changed here in the UI as I had changed it under IP. Save, and wait and like magic everything works correctly.   It appears to me that you have to set the management VLAN the same in 2 different places in the UI in order for it to work. To me this is confusing as heck and it does not say this anywhere in the documentation. I would consider this a aflaw or bug.   Is there some reason for this? Anybody from Merkai care to comment on why this is? Or should I file a bug report? ... View more

I am doing some more investigation based on messages now. Will post soon once I have better information. I did get this from Meraki support....   Thank you for contacting Cisco Meraki Technical Support. My name is xxxxx and I am happy to help. Looking at your Switch > Configure > Settings page, I am seeing that the management VLAN is configured to be VLAN 1, not VLAN 2009. If the MS is configured to retrieve IP information from DHCP, it would pull DHCP from the Native VLAN, in this case VLAN 1, not VLAN 2009. If you change the management VLAN and the switch can no longer obtain a DHCP lease or reach Meraki Dashboard, the switch will revert to its previous management VLAN configuration. So the management VLAN HAS to be an untagged vlan on the uplink?   There are two places to set this it would seem in the dashboard. In the Lan IP section of the switch, and under "configure: Switch settings."   Are these both the same setting? ... View more

ok now my eyebrows are up! Fill me in on this! What kind of Bugs. We are specing a LOT of these right now as catalyst replacements. What kind of problems and bugs? ... View more

Thanks. Not perfect but it might work. ... View more