You bet they are still trying!   Check out the latest v15.8 Beta code, still a crap ton of MS390 known issues not resolved.  "loop detection not supported"??  STILL?  For a Cisco made switch?!   @misterguitar I heard that before from Cisco and ran v14.x beta codes for a couple months.  Then I said I'm done with this.  I was driving to our call center every other day to literally pull the power cords and plugging them back in, just to reset them.   ... View more

The truth is, Cisco Meraki is using customers as test beds to improve the MS390, which I think is totally the wrong way to bring this product up to par.  It's like releasing a tire that might blow up (Yep, we remember Firestone).  After about 2000 sets of tires blow up then they true up the product??     I handled and repacked those 25 MS390 switches to ship back.  They remind me of the Catalyst 3850.  In my opinion, Cisco should not take Catalyst switches and try to phase Meraki firmware into them.  If they do, they better make sure it's tested to max.  Otherwise, this product should be pulled completely. ... View more

@misterguitar    My 2 cents: - I wasn't making frequent L3 changes and it's not a hosting environment.  The L3 changes were done after first 2 days of install and configuration - No other brands or types of switches or routers were connected to the MS390 switches, pure Meraki equipment.  No Cisco Catalyst equipment either, which I'm also familiar with.   No problem for 2 months, then all 3 MS390 stacks started blowing up every 1 to 2 weeks, during which time, no extra equipment was added.   By the way, I was on switch firmware v14.26 when I ripped out all those MS390 switches.  I was doing firmware upgrade every week on those, up until the "throw them out" week. ... View more

Told you so!  Every 10 days to 2 weeks exactly, they self-destroy, even on the newest beta firmware.  Well, 7 days for you this time.  Rid yourself of all stress before the holidays and get those 355's in. ... View more

@Bur20 , wait 2 weeks then come back and report.  The MS390 stacks I had would self destroy every 2 weeks.  They were like babies with fresh sunday sleeps every time after I rebooted but would just fall off the cliff approximately 10 days to 2 weeks, starting with 100% pegged CPU taking down the control plane module which causes it to lose contact with Meraki cloud.  I was literally doing firmware update every 2 weeks to the latest beta (yup, as recommended by Meraki support), after every crash.   It is only taking an entire year to fix this model, with experiments on live customers. ... View more

I suggest you just dump the MS390s for something else.   When v12.28 was the stable code back in May, I upgraded to the latest v14.2x just like what you are asking now for code v15.x.  Meraki support will keep asking you to upgrade to the latest code until you can't take it anymore.  They are using you as an experiment to stabilize the codes.  Has it stabilized?  Absolutely not. ... View more

You guys need to speak to your Cisco rep and deal with them directly.  I was able to make a deal and swap out all 25 MS390 switches with 25 MS350 switches.  I have not had to do single unexpected reboot since.  I don't think I need further proof that the MS390 switches are garbage, there are plenty of evidence here.  Although it took me several nights to swap out all 25 with over 1000 connections.   BTW, I am not doing any VLAN pruning on any trunk ports as I was doing on the MS390.  I believe VLAN pruning did nothing whatsoever on the MS390 and was a "flail" attempt from Meraki support asking me to do that.  For those who think I was "pushing the limit" by stacking 8 switches, I have no issue doing so with MS350 switches and why would I be pushing the limit if it's described in the data sheet as an approved setup?  I have stacked 8 Cisco 3850 switches and 8 Adtran switches in the past without issues.  Same scenario here, except that MS390 just can't do it properly. ... View more

Finished removing all MS390 switches last Friday night, the MS350 are rock solid.  I sometimes think Cisco's Meraki division is simply performing code experiments using customers.  Literally right after this entire swap, I noticed Cisco had updated the most recent stable switch code with the following known issues remaining, which they literally experimented me on.  So how does one expect to manage the MS390 switches, a switch that needs to talk to the cloud for configuration changes when the control plane resets and cause loss of connectivity to the dashboard?  It is STILL NOT FIXED IN CODE V14.32 .  It doesn't matter that it doesn't affect data plane traffic, the switches CANNOT BE MANAGED once the control plane crashes.  Cisco -> you still don't understand.  I experienced all items highlighted in RED below, which are critical basic switch functions.  Once the control plane crashes and loses connection with the Meraki dashboard, the switches do not report back until you manually power cycle by pulling the power plugs.  People are left in the dark regarding the state of the switches.   My final announcement in this thread to the public out there:  DO NOT DEPLOY OR INSTALL THE MS390 SWITCHES.  They are not reliable and they are missing vital basic switch functions, and Cisco needs to pull this product off the shelf and stop experimenting with their customers' networks. Switch firmware versions MS 14.32 changelog Known issues MS390s may experience control plane resets which could impact dashboard connectivity. This does not affect data plane traffic. In rare instances, DAI inspection may fail to snoop DHCP transactions on stacks leading to those clients being in a blocked state If a combined network has Umbrella integration, changes cannot be made to the group policy page (present since MS 14.5) MS390 ports are limited to the lowest link speed since boot if QoS is enabled MS120 in rare instances will not be able to perform packet captures until rebooted (predates MS 12.28) In rare instances, a stack member may go offline until rebooted (present since MS 12) MS390s may experience a brief 1-2 minute control plane outage. The data plane will not experience issues during this time. In rare instances, non-390 stack members will reboot (present since 12.29+) Packet loss is observed when pinging the MS390 management IP MS120s on rare occasions will reboot (present since MS 11) Stackpower is not enabled on MS390s by default Links being established on a MS120 can result in neighboring ports to flap (present since MS 11) MS390 - Port Up/Down Events Shown Across All Members Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11) Networks containing a large number of switches may encounter issues saving changes on the Switch Settings page Stack members are not being marked to update their configuration when changes are made on other members 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. Example, MS355 switchports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G. The list of switches to clone from fails to load when cloning a switch in an organization with a large number of switches and networks Broadcast types of traffic can leak into the Guest VLAN if a port that fails authentication has a Voice VLAN configured, and dashboard has a Guest VLAN defined (present since MS 11) MS120s switchports with MAB authentication may randomly deauthenticate clients. In order to resume client authentication on that port, a switch reboot is required (present since MS 12) MS390 series switches do not support SM sentry MS390 series switches do not support Meraki authentication MS390 series switches do not support URL redirection MS390 series switches do not support MAC whitelists MS390 series switches do not support loop detection MS390 series switches do not support warm spare/VRRP MS390 series switches do not support UDLD MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10) Rebooting any MS390 stack member via the UI will result in the entire stack rebooting ... View more

I am at the tail end of swapping out all 26 switches or 3 switch stacks.  The entire infrastructure stabilized as soon as I swapped out the core stack with three MS350 switches.  The last MS390 stack continues to lose contact with the Meraki dashboard every 2 weeks like clockwork and I pretty much got numb doing firmware upgrade constantly on those.  NO firmware can fix MS390 quirkiness.  Everytime I call support when MS390s get stoned, they ask me if I can get into the local status page of a specific switch, NO I cannot.  The whole stack is unresponsive management access-wise, and requires manual pull of the power plugs to reboot to access them again.  Then Meraki support would say "well you rebooted them so the logs are lost".     Last stack to be swapped out this Friday night.  I won't miss the MS390 switches. ... View more

@misterguitar , that was EXACTLY what I was dealing with!  It's ridiculous also that old fashioned "power-plug-pull" is required to reboot those damn things.  Also when you speak to Meraki support, they go, "oh you rebooted the switches so the logs are lost".  I said "I have to reboot the switches for you to see them in your meraki cloud yeah?!  and local status page wasn't even responding with my laptop straight into a switch port, in person?"  It boggles my mind that logs aren't kept for a specific amount of time, they are GONE when switches are rebooted.    I don't know how big if your customer's deployment is but basically these switches took down our call center filled with over 200 people, 3 separate times, and I had to explain to the IT director what happened, 3 separate times.   ... View more

3 units of MS350 switches swapped in as the layer 3 core, the original eight unit MS390 core is now an access-layer stack.  Not only is it super stable, I even gained 200+ Mbps in internet bandwidth, 950Mbps total out of 1Gbps at any given time.   I am proceeding with swapping out the rest of the twenty-five MS390 switches in the coming days.  They are being returned to Cisco as beta junk.  That's about $180000 in unstable hardware/beta meraki switch code. ... View more

Have not considered that.  I have a bunch of angry people behind me for that large call center with these switches installed.  I had to describe to the director at the call center that "you are driving a Tesla using beta autopilot software to drive" then she understood what I was getting at.  The MS390 switches need to be pulled from the website and any market for sale until there is a solid stable version of the code PERIOD.  I don't know any managed switches without the loop detection feature, but these $7000 switches don't support it.    I was damn near ordering twenty-five Netgear 48-port gigabit switches last week via Amazon to toss out these expensive pieces of tarnished gold. ... View more

Problem confirmed by Meraki support as of this morning as yet another bug, causing MS390 to lose contact with the dashboard. ... View more

Old fashion power cycle by pulling the power plugs then plugging them back in brought them back into the meraki dashboard, then they dropped again for another 10 minutes, then they came back again.  Normal MS390 flakiness.  I was told yet another different thing to do and this time they had me dismantle the aggregation group between the MDF stack and the IDF stack.  So basically I cannot run any advanced functions on these switches it seems.   Configuring a pair of MS350 as the new core, going in on Friday night. ... View more

BUMP.  I'm going to keep this thread at the top until someone from Cisco backend engineering answers this. ... View more

An entire stack of eight MS390 access layer switches lost contact with Meraki at 4am Saturday night, while nobody was present onsite or working remotely on them.  I am now being called by management as I don't know what the hell I'm doing at this point.  These switches will literally get me fired if this keeps up.  Yep, rebooted them via smart UPS power outlets remotely and they still don't re-establish connection with Meraki cloud.  I literally need to go there and reboot them the old fashion way by pulling the plugs.  Nothing but a string of mysterious issues recently, including the non-responsive DHCP issue on nearly all MX84 and some MX100 routers.   My IT director will be talking to our Cisco rep and take this to the top.  Entire line of MS390 switches need get SCRAPPED IMMEDIATELY.  This reminds me of the first generation of 3COM hubs I worked on more than 20 years ago. ... View more

I will be building a windows 2016 server running DHCP and relay all DHCP requests back to headend data center instead.  But don't tell me that that even DHCP relay is busted... I hope that's not the case.     What bothers me here is the fact that everything was fine since I joined this company more than a year ago then this problem just started a few days ago while running on the same firmware for the last 2 months and 3 weeks. ... View more

We were told to upgrade the ones with this DHCP issue to v15.43.1, made no difference whatsoever.  Just over 12 hours later, pc's started dropping off the network with 169.254.x.x IP addresses again.  So what now?  Throw another firmware card?  Bring laptop to park picnic and reboot all routers while having a sandwich?  I had no issue whatsoever until 2 days ago, then it started out of the blue with ZERO change.  Maybe I should throw my old Cisco 2600 router back in or start building Window server on pc's to serve DHCP. ... View more

So what's the solution here?!  Everything was fine up until 2 days ago, with no change, no firmware upgrade, MX84 and MX100 routers just stop responding to DHCP requests?  If there is an infinite DHCP lease option, I would have done it already, but there is not!!  I've been rebooting routers throughout the entire day and it's just purely ridiculous.  No, I do not have VLAN tagging issue.  We run the same setup across all clinics and it's the same setup I've been doing since I joined this company. ... View more

@cmr  Access level switch stacks are "mostly" ok.  They have randomly dropped off the meraki dashboard for no reason also, several times in the 3 months that I have deployed these.  Switch dropout from dashboard most of the time occurred randomly in the middle of the night when no one is working on them.  Like I said, I have 8 MS350s coming to rip out the stack of 8 MS390 right now.  These switches need to go to the junk pile, it defies everything I know about Cisco switches.  I started my career using Cisco 2900 switches more than 20 years ago and I literally let those collect dust and they never even tried to die.  Rather disappointed in the Meraki MS390 switches. ... View more

@misterguitar  I'm wondering if yours sporadically crashed?  The set I have would sporadically lose connection with dashboard, most of the time in the middle of the night.   I don't know if Cisco tech support is watching here, but when will these switches act like switches? ... View more

Last night, I tore out the warm spare MX100, removed the 2 WAN breakout VLANs on 6 ports of the core stack, limited uplink ports to the single MX100 to only VLAN1, and limited uplink ports to all AP's for 3 specific VLANs.  Pruned VLANs, check.  Never did that on traditional Cisco switches.  Now will monitor for 2 weeks and get ready to rip out all 8 MS390 switches as core.   Unfortunately when this call center was built back in May, all MS350 (what we use as standard) were all on backorder so management ordered all MS390 switches.  What I am hearing is that I should just eat it and put up with it even though I installed them according to Cisco's spec.  Such as life. ... View more