MS-390, when is it ready for action?

[MarcelTempelman]

Hi,

we were considering the MS-390 in a design for a customer but after looking at the release notes (even the beta software) we're not really convinced that this switchis ready for action yet.

This is a list from the relase notes and I say it's quite long:

•   MS390 stack members may not report client-level detail
•   MS390 series switches Max MTU is limited to 9198 bytes
•   MS390 series switches will not display packet details in the DHCP Servers page
•   MS390 series switches do not support the 'next-server' or 'bootfile' parameters in DHCP messages
•   Rebooting a single switch in an MS390 stack will reboot the entire stack
•   LLDP frames from MS390 series switches will use a single system name instead of the Dashboard given name
•   MS390 series switches will not display the advertising router ID for OSPF
•   MS390 series switches with OSPF enabled will default to an IP MTU of 1500 bytes on every OSPF enabled interface
•   MS390 series switches do not support the multicast routing livetool
•   Stacked MS390 series switches do not report traffic/client analytics correctly in all cases
•   MS390 series switches do not support tagged traffic bypass for voice on ports with a Multi-Auth access policy
•   Dynamic VLAN assignment from a RADIUS server on MS390 series switches must already be an allowed VLAN on the port for it to function
•   MS390 series switches may not display link state on links at mGig speeds (2.5G, 5G)
•   MS390 series switches do not currently support the following features: VRRP, SM Sentry, Syslog server, SNMP, Traceroute, IPv6 connectivity to dashboard, Meraki Auth, URL Redirection, MAC Whitelisting, RADIUS Accounting, RADIUS CoA, QoS, Power Supply State, PoE power status/usage, Loop Detection, UDLD, MAC Flap Detection

Is there an ETA when this list is implemented / fixed ?

It's also a bit confusing ; we designed a redundant core solution with a warm spare. The datasheet says the MS-390 supports warm spare but the realse notes say VRRP is not supported yet. Are we talking about VRRP with other brands (Warm spare is based on VRRP with Meraki switches) or is this VRRP in general ? 

with kind regards,

Marcel Tempelman

[DarrenOC]

Hi, I would say if you don’t feel comfortable with the number of known bugs/issues then hold off or propose another device.

Ive read the 390 data sheets and they specify VRRP is supported whilst the Warm Spare release notes don’t mention the MS-390’s.  I would go with what’s in the ms-390 datasheets.  The warm spare release notes clearly haven’t been updated.

[MarcelTempelman]

It depends. If the customer is targeting Q3/4 for implementation and everything is fixed by then there's no problem.

[Nash]

Given the current state of the world and active disruptions that we're all experiencing

I wouldn't place bets on firmware being fixed by Q3/Q4. I am not criticizing Meraki's speed here. I am recognizing that we are not in a usual time or place.

[PhilipDAth]

I don't think I would deploy it yet.

But - I'm struggling even for a use case (apart from someone wanting SGT support - which it currently doesn't support ...).  Why do you prefer this switch over (for example) an MS355?

[MarcelTempelman]

The customer needs around 20 SFP/SFP+ ports en 20-40 copper ports in each MER. A stack of 3 MS-390s would be enough otherwise we'd have to make a design with several stacks of MS3XX and MS4XX switches.

[PhilipDAth]

With that port density in mind the MS390 with the 8 port 10Gbe module is a nice fit.

I think I would go with a pair of MS425-16's (to get 32 SFP+ ports) and a pair of MS225-24's (to give you 48 copper ports), which gives you two of everything so you have complete redundancy.  You can use 10Gbe TwinAx to link the MS225's to the 10Gbe MS425 core.  Cheap interconnects.

Plan B, involving just 1 extra switch, would be to go with 5 x MS355-24X.  That will give you 20 x SFP+ ports and 120 copper ports.  Some customers might prefer to have the single stack.  Easy to manage.  One "core" switch.

But if it was my money, I'd want the MS425 10Gbe core.  I just feels "right".

I've used this exact design (MS425 core and MS225 switch blocks) before with customers and it has worked great.  I have had an MS225 server switch block (for those server things still with Gigabit ports) and then MS225 access layer blocks for general connectivity.

Both of these switches have been out for a while and have mature firmware.

[MarcelTempelman]

Good to hear about the stability. For access switches we went for the 250 because it support redundant power supplies.

We're going back to the drawing board and I'll consider what you're using, thank you.

[whistleblower]

hi @All

do you still think the same way today? how is the experience with the MS390 series as of today? I’m also considering a MS425 flex stack in a new deployment and use the MS390‘s as physical stacks as access switches! One reason for me is that I was told that the 390 would be the best for future use - e.g. of the hardware specifications, Adaptive Policy feature etc.

Maybe someone knows if SGT would also be supported on the other switch models like MS425, 350 and 250?

[cmr]

@whistleblower I'd use 355Xs as an access stack, in fact I have replaced a stack on 3850s with 355Xs and the Cu 2.5/5/10GbE is a great benefit for access.  As they have QSFP+ ports we are going to use those to link to our core at that site.

[Bruce]

I’m still in two minds about the MS390. From a futures perspective, yes it will be the best switch. Should you deploy it now? Hmmmmm... if you just want switches doing nothing too special in small stacks (three or less), and you’re happy for the odd hiccup and to run the MS14 ‘beta’ code then I reckon they’re probably deployable.

As for SGTs, I doubt very much that the traditional Meraki switches will ever support them. The Cisco Catalysts and the MS390 that support SGTs have the UADP ASIC in them so that they can process the additional payload in the Layer 2 header - its unlikely the traditional switches will ever get this capability as their ASICs most likely can’t do it, and doing it on the CPU is impractical.

I expect, but this is pure speculation, that potentially once the MS390 has reached a certain level of maturity and stability then Meraki may bring a small number of other Catalyst hardware over to the MS range, like the Catalyst 9500 to expand/extend the MS400 series. Under the hood the Catalyst 9000 switches are all similar from my understanding, so once one is done the others should be significantly easier (and probably not such a mess as the MS390 was).

[GIdenJoe]

I strongly agree with @Bruce here.

The catalyst switches themselves are very stable but the integration with Meraki software is going a bit bumpy.

Once they got the hang of it, porting other members of the catalyst portfolio to the newer MS line will be less troublesome.  All catalyst switches use the same kind of UADP chip in one generation (except the 9200's) and the software behaves the same over the entire family.

The traditional MS line is more stable but has way fewer supported features than a catalyst switch,

Smaller customer that exclusively route traffic over the upstream appliance albeit an MX or a 3rd party device will be just fine with the current MS family.

However if those customers grow and go to a routed distribution layer/core then segmentation becomes more important and that is where the trustsec/adaptive policy value lies.

[MichelRueger]

I am in the same Status. As the Firmware with solves a lot of Problems is still Beta I do not recoment to buy it now. Or only if you need Multigigabit Ports. One of the biggest problem still is that if you have a stack with ms390 and you are updating software the full stack goes down!! and not just for 3 Minutes. Last update of a stack with 4 MS390 took more that 35 Minutes to get fully operational again.

I also See that Meraki is using more Cisco Nativ switches in future. But if you see how it is implemented at the moment. this will never work stable. if you open the MS390 Switch you find the Serial Console Port. Connect a Console Cable to it and power on the switch. You are able to see that the Switch is powering up a Cisco nativ IOS and then starting a virtual stack for the Meraki implementation.

[whistleblower]

thanks  @Bruce @GIdenJoe 

---

@Bruce wrote:

I’m still in two minds about the MS390. From a futures perspective, yes it will be the best switch. Should you deploy it now? Hmmmmm... if you just want switches doing nothing too special in small stacks (three or less), and you’re happy for the odd hiccup and to run the MS14 ‘beta’ code then I reckon they’re probably deployable.

---

...and that`s the point, for now the switches will be used for wired-access /w 802.1x and to connect APs maybe via mGig... for this to achive the 355 Series would be fine! But when it comes for future use and one point out of that would be in my opinion Adpative Policy/SGT than I`d have to go with the MS390...

The thing is... when I use the MS425 in the core and they won`t support the Adaptive Policy feature neither in the future as well - the design is`nt as good for future proof! So I`d to use the MS390 (/w all differences e.g. like flexible-stacking compared to the MS425...) or mix Meraki MS-Switches with Cisco Enterprise C9K devices - which I honestly would like to avoid! 😕

[PhilipDAth]

>when I use the MS425 in the core and they won`t support the Adaptive Policy feature neithe

If you buy the MS390 are you going to buy the "Advanced" licence as well to enabled Adaptive Policy?

[whistleblower]

hi @PhilipDAth 

yes, the plan was to buy the license to use the Adaptive Policy!

BTW - I‘ve attended the meraki PVT in the last week and the SE‘s advised that currently the way to go in using Adaptive Policy will be to work with C9K in the core! the questions - if the classic MS Series will also be adopted to use the same future proofed features like the MS390 offer today... where’nt answered very clearly to me 😕

In my case now, if the customer will decide to use micro-segmentation, I‘ll change all over to Cisco C9K switches for core/distribution and access layer! If not, than I probably choose the MS355 as the access switches because of the better stability...

[Bruce]

@whistleblower, it’s highly unlikely that the classic MS switches will ever be able to do Adaptive Policy. AP uses a Scalable Group Tag (SGT) which is inserted into the Ethernet header, and since virtually every switch uses ASICs to process the Ethernet header, the ASIC needs to ‘know’ about it. Unfortunately the ASICs in the classic MS switches aren’t reprogramable.

The MS390 has Cisco’s UADP ASIC in it, which is the same as in the Catalyst 9000 series, hence why they all support SGT and why they can all play nicely together. The UADP ASIC also supports a level of reprogamability too, which is why Cisco rave about it so much - means they can add new capabilities to the ASIC without throwing the switch out.

[misterguitar]

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!

[MichelRueger]

Hi all, I am just installing 10 * MS390 Switch. I am quit frustrated about them.

First they take for ever to boot up! 10 Minutes minimum!!!

second I am using MS425 Meraki Switch an Core. First big Problem Meraki Swtich do have all ports as Trunk with nativ VLAN 1 and allowed VLANs: all --> MS390 can not Handel allowed VLANs: all they have allowed VLANs: 1-1000 so you will get a VLAN Error on all Ports between true Meraki Switch an MS390.

I started this morning at 08:00 and connected always 2 * MS390 together as a Stack. this evening at 20:00  i got it done to have them all green in the Dashboard 🙂

[PhilipDAth]

Out of curiosity, did you get the standard or advanced licence for them? 

[MichelRueger]

Enterprise Version

[cmr]

@MichelRueger the reason they take so long to boot is that I believe they run the standard ios-xe os natively and then load the Meraki management in a container on top.

We use 3850 stacks as our core at 24/7 sites and a stack usually takes 15-20 minutes to reboot when in install mode, otherwise they take up to an hour!

The 390 is effectively a 9300 which is, itself, effectively a 3850+...

[MarcelTempelman]

Hi,

Cat 9300/9200 and Cat3800/3600 boot very slow and when stacking is enabled it's even slower. 2960X are slow beasts also when it comes to booting. It seems boottime is no priority at Cisco.... (when things are down you get the urge to beat the switch to boot faster...😁).

[DanZ]

I am doing a trial of the MS390.  They do take a long time to boot compared to the 355s.  Code upgrade also took about an hour!  I ran into the 1000 VLAN limit too.  That seems like a bizarre limitation and surprising that it's not fixed yet.  I am stacking 3 together and that behavior is also different.  They all seem to share the same management IP instead of 3 separate management IPs.  Although it lets you configure 3, only 1 will show on the Dashboard for each switch.  None of this is documented anywhere that I can find.  The MS390 initial startup guide makes it sound just like an MS355.  I also am trying to figure out why they keep losing their connection to dashboard every 20 minutes or so.

[cmr]

It is a 3850/9300, we have stacks of 3850s at each site and they all work the same way...🤔

[GIdenJoe]

So basically someone left the VTPv1/2 mode at client limiting you to normal range VLANs? 😛
Looks like a bug to me.

Catalyst switches to take some time to boot.

POST
Load rommon
Do a test of the ASIC's
Decompress and load the software.
Check if the software is authentic
Test the ASIC's again..
Then the prompt arrives.

I hope they never run into the issue that sometimes happens that the software fails to load on a stackmember after an update.

[BazzaP]

We had the dashboard dropping also, when you looked on the 9500 core it was complaining about low power on the links to the core. Just upgraded to 14.21 so far all good, been just under a week up now.

[watdee]

I like the size and the fact that it can have 8 10gb connections, plus I need the removable brackets to get it in my rack.  I'd like to use a pair of them for my server rack but worried about the boot time, bugs, and missing features.  Doesn't seem like this switch will ever be ready for prime time.  They have the MS390 on the switching home page, is this really the future of Meraki?

[BazzaP]

Hi You need to be on the latest firmware, currently 14.24. This has improved boot times significatly. There are still issues with these switches but they are getting better. They do have their own minds when it comes to stacking and aggrigating ports. Always best to get them online first before you do anything with them, this breaks from the usual pre-staging that you would normally do with a switch network.

[misterguitar]

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.

[DanZ]

I just rebooted a stack of 3 MS390 switches and timed it. It took 19 minutes. I thought they were broken and suddenly they came back up. That is nuts.

[cmr]

@DanZ as mentioned before, they are 9300s with the Meraki software running on top.  This is a good result, we've had a reboot take up to an hour if you don't have them in the right mode, it needs to be install on the underlying IOS-XE.

However the power and data stacking is exceptional 😎

[MichelRueger]

Now we go live with 12 * MS390, but it is just a nightmare. The Switch are not correctly show in the Network overview and the Power Supply Infos from the Switch are just not existing. 

This is now a long time the Switches are sold and still this Problems ?????????

[MichelRueger]

Just got News on this.

If you upgrade to MS12.22 Beta Software you have one think fixed. The Stack Modul is now Showing correctly.

Before MS12.22

After MS12.22 update 

Power information are still not there but Development is working hard to get it fixed 🙂

[Cal]

I recently sold these to a client and the implementation was a nightmare. 

I so regret choosing this model. 

Come on Meraki, this is not your standard. 

I don't like that the entire stack reboots if one member does it. I have a vSphere cluster aggregated to it. 

Sigh!

[PhilipDAth]

Split the stack in two and connect vSphere across the two stacks. 

[MarcelTempelman]

That beats the purpose of a stack. You would expect redundancy (to a certain level) when you connect servers with double connections to a stack. Splitting the stack will also disable any MLAG functionality.

Meraki should not have released this switch before a) the firmware was stable and b) it has at least the feature level of a MS355/MS425.

This thread is already too long and still the beta firmware (release notes) does not show much progress. since I opened this thread.

We're talking about a hardware platform which is already in production for about 2-3 years. It has a predecessor which is quite similar (Cat3600/3800). You'd say they had more than enough to play around with prototypes. I do not know what is keeping them from 'getting there'. 

In the meantime we've made several designs based on the 'normal' MS400/MS300 switches where a proper functioning MS390 certainly would have made a difference.

I really love the idea of having a Cat9K switch with Meraki software don't get me wrong.

[Cal]

Agree w/ you 100%.

[PhilipDAth]

>That beats the purpose of a stack. You would expect redundancy (to a certain level) when you connect servers with double connections to a stack. Splitting the stack will also disable any MLAG functionality.

No Meraki stack from any model MS family allows an individual switch to be rebooted.  The same restriction applies with most of the Cisco Enterprise stacks as well.  Nexus is one exception, but it's not a stack like the others.

I typically copy the Fibrechannel model, and create two "fabrics".  This is especially important if you are using IP storage.  Fabrics are independent of each other.  You can do this by:

• Having a primary 10Gbe stack and a backup 1Gbe switch.  In VMWare you configure the Gigabit NICs as standbys so they are not usually used.  The 10Gbe stack and 1Gbe switch need to go into separate Meraki networks.  As a bonus, the 1Gbe switch can be used for all the management ports.
• Have two 10Gbe switches not stacked (I like the MS425-16 as they have a pair of 40Gbe ports on them and they can be used as standard switch ports to provide high-speed connectivity between the switches).  Once again each switch goes into a separate Meraki network.
• Have a 10Gbe stack and a single standalone 10Gbe switch.  This lets you use LACP across the primary stack for those things that support it, and provides a second independent switch to keep VMWare happy when the primary stack needs to reboot eventually.  Once again, use a pair of networks.

It's just a matter of being aware of the design rules around the platforms you want to use.

[MarcelTempelman]

>No Meraki stack from any model MS family allows an individual switch to be rebooted.  The same restriction applies with most of the Cisco Enterprise stacks as well.  Nexus is one exception, but it's not a stack like the others.

Catalyst 3K and 9K have an extra reload option to reload a slot (aka a stackmember). And you can always use the power to shut down a member (not elegant I know).

IMHO the purpose of a stack is redundancy in case of a failure. Having MLAG support is a benefit. 

VPC on NX-OS has one big benefit and that if one switch fails at the software level it won’t pull the other switch down the drain. VSS and StackWise Virtual still have that problem just like normal stacks. One drawback is that you have 2 separate switches with separate configs which you need to keep synced manually. 

Putting the redundancy at the host level is also an option. It’s a matter of preference I guess. 

[PeteMoy]

Meraki user here for close to 3 years now.

Just yesterday we started the staging process for a stack of new MS-390-48UX switches.  I thought I had seen most of the Meraki quirks given all the deployments I've done but nope.

First issue was the long (10 mins) reboot process.  Being remote, I had to ask the poor local office manager to divine interpret the colors on the cycling front panel LED.  More than once I thought the switch had died and did a power cycle boot, which only added to the wait.

Second, I like my switches to have a static IP for mgmt.  I boot the new switch with DHCP and then once the switch has stabilized, I would change it to a static.  After my change, this took over 20 mins for the change to be shown on the GUI.  I'm used to the lead/lag effect but this is insane.  As I'm waiting for the GUI to update, my mind of going over all the things that could be wrong.

The restrictions of VLAN 1-1000 on a trunk was another quirk I solved thanks to this thread.  I did NOT like seeing that warning message on my Core Meraki MS-416 but didn't realize the trunk port default for VLAN's is "all" on the core.

So now I have to go on to the next stage, which is to create a stack of these things.  Let's see how that goes...

If I understand correctly from reading this thread, the stack cables for the MS390 are different than the cables for the MS-425/MS-250 series?

[cmr]

@PeteMoy the stacking cables for the 390s are the same as those for the Cisco IOS-XE 9300s as they are the same hardware, just the MS390 has Meraki software running in a container on it.  When you have a stack the reboot process is longer as all members have to come up, but I thought in the latest code they had improved the reboot on upgrade time, so you may be okay.

[PeteMoy]

OK, a quick update as I try to remotely configure the stack of MS-390's.  Just as a point of reference, I've remotely configured at least two dozen stacks using MS-250 switches over the last two years so I get the quirks.

- All of the 4 switches had unique static IP's on the MGMT VLAN before I started.  Everything was stable and updated to version MS 11.31  I have my local contact hook up the stack cables.  The stack was recognized as a "potential" stack and was provisioned.

- A few minutes after doing this, I lost all contact with the stack.  I assume there was a reboot process happening.  About 30 mins later, the stack appeared in my GUI.  I noticed that all 4 switches had the same DHCP IP from another VLAN on my network.  Again, I had unique statics assigned to each switch before this process started.

- At this point, I disabled all the individual uplinks to the switches from the core switch.  These uplinks were only needed for the staging process.  I only need one fiber (or 2 to redundancy) uplink from the stack itself once it's been provisioned.  Switch to switch comms will happen over the stack cables.  Once I did this, the entire stack disappeared from the GUI again.  My local tech had already left the office at this point so there was nothing I could do.

- About 2.5 hours later, the stack magically reappeared in the GUI.  This time they all had the same local IP as one of the original switches.  But at least this was a static IP on the correct VLAN.

I did a reboot test of a switch that did not have a direct uplink to the core and confirmed that switch with the direct uplink also rebooted by watching the link of the port on the core go out.  So the reboot on one in the stack will reset the entire stack.

Individual switches take about 10 mins to reboot.  The 4-stack switch took about 20 mins to come back to the GUI.

I can just imagine how much stress it would be if this was a live network and a reset was needed on an individual switch.  How about reboots during IOS updates?

Anyway, it's a bit disappointing to see how the MS-390's so far seem to be a step backwards in terms of configuration and installation.

[MarcelTempelman]

Having one 1 IP address is standard with Catalyst Stackwise because the switches share the same control plane. I guess they did not change that.

The boottimes are really bad. It's a bit embarassing that they slap themselves on the shoulder with having one hell of an ASIC on the inside while the switch itself takes ages to boot (resulting in unnecessary long downtime). The Catalyst version is also slow as hell (but that is already mentioned in this thread). 

[PeteMoy]

Not sure why my last reply was wiped, but here goes again.

Some more things learned while configuring a new stack of for MS-390's

- I had static IP's defined for each switch in the stack during staging.  All the switches of the new stack will take on the IP on one the of switches in the stack once the stacking is complete.  Can you recycle the IP's that were originally assigned to each switch?  Who knows, but I wouldn't.

- My stack was offline for over 2 hrs after enabling the stack before it showed up again on the GUI

- Rebooting one switch in the stack will boot the entire stack.  Single switch reboot, 10 minutes.  Four switch stack reboot time?  20 minutes.  Keep this in mind for downtime windows during IOS code updates.

[CarolineS]

Hi @PeteMoy -

Sorry about that! Sometimes our automated spam filter is over aggressive. I have restored your first post (so now there is probably some duplication but oh well?)

Cheers! 

[Darren8]

So I am about to deploy 3 x MS390 switches (and MR46 APs) and am wondering, based on the feedback here, whether to leave stacking until it is more reliable but who knows when that will be.

I can uplink each switch individually to the core to avoid stacking.

I assume I can still use StackPower without data stacking?

So from those who have stacked MS390 switches, am I better off not using stacking at this time based on your experience?

Thanks, Darren

[cmr]

@Darren8 Stackpower is independent of data stacking on 3850s and 9300s so I'd be pretty confident that it is independent on the MS390s

[PeteMoy]

@Darren8 

I plan on moving forward with the stacking due to the lack of fiber uplinks between my stack and the core.  Plus our model uses an aggregate uplink connection (combining two trunks) and we can only due that across physical switches using a stack.

The stack behavior is annoying but as long as you understand what to expect, you can be ready for it.

I suggest you leave plenty of lead time to build and test the stack before putting it into production.

-Pete

[Darren8]

@PeteMoy, so what software version would you recommend based on your experience to date?

I'm thinking I should go to MS12.22 before stacking and cutover.

Thanks, Darren

[MichelRueger]

So I am Using the Last Beta Software and it is stable. The good Think with this Beta is you see the Module Interface Status.

[MichelRueger]

Just want to give a update to MS390. There are still a lot of Dashboard Problems with this Switch,

* No Power-supply Information

* Wrong Port Information in the Client View

* Network Wide Topology completely wrong information

* No Packet Capter posibility as Switch is delivering wrong Port Information

* Log File Show 1'000 of wrong Port Change

* ...

TAC is not solving the Problems they gibe it all back to Development. Cases are open since more than 2 Mounts and nothing happen 😞

We did escalated it true Meraki sales to management but nothing happen.

[cmr]

@MichelRueger has 14.6 not fixed any of those, I see it lists not supporting power state, but not specifically the others, or do you have stacks of four or more switches? 

Maybe they ran out of space on the release notes...

[MichelRueger]

14.6 ?  the newest Release i see for Switches is MS12.28

now biggest Stack is 3 Switches.

[cmr]

@MichelRueger it is in the beta section and unless you have stacks of 4 or more switches has multiple additional fixes compared to 12.28 as we have had 12.29, 12.30, 14.5 and 14.6 since then.  The later 12.x releases were replaced by 14.x about a month ago.

Don't worry about it being beta, in the context of a 390 beta is definitely betta 😉 

[cmr]

@MichelRueger 12.30 has appeared as a stable release candidate today and that includes the MS390 fixes from 12.29

[PeteMoy]

Currently running 11.31 but that's because I have core and other switches that are stable on this version.  I only keep with the recommended Meraki versions and try not to jump ahead unless there is a specific bug. 

[Cal]

I hear you, but why should I have to compromise.

This is no good, I'm seeking a different model replacement from Meraki as recommended by support after we spent 4 hours on a call trying to troubleshoot them.

In the end the switches never completed their boot sequence as they were stuck in initializing phase.

Needless to say the project has to be aborted at 3:30am and reverted to the old switches.

[MichelRueger]

Hello MS390 Guys,

I have the next very Strange thing about that Switch. As you can see in the Pictures if you Stack two Meraki (True Meraki Switches 🙂 ) together they have there own IP See MS450 Core Stack but if you stack MS390 they Lose there preconfigured Statik IP Adress and get one of the Stack Member IP. I didn't figured out witch IP the Stack is selecting but all switches in the Stack have the Same IP. SO there is no consistency how Meraki is Managing Stack IP Addresses. Or better told if you don't use MS390 there is a consistency and if you use the MS390 you loos them 😞

There is also something absolutely strange If you are using Stack with MS390 the Network Topology is changing every 10 Minutes

🙂

So Stay tuned for Updates.

[cmr]

@MichelRueger thanks for the updates, it is good to find out how they behave in the real world!  As stated above, the MS390 is effectively a Cisco 9300 with the Meraki software running in a container on top.  This is why you get the single IP, 10 minute+ reboot etc. and also, to me, explains why there are so many issues with it, as the Meraki software has to go through the underlying IOS to get to the hardware below.

As for the topology issue, it doesn't surprise me as our Cisco 3850 (9300 predecessor) stacks show up in multiple places on the topology diagrams for each of our sites, with the topology logic seemingly unable to understand that they are one device...  I'm guessing this issue is causing what you see.

Keep up the good work 😀

Charles 

[redsector]

It´s an old fashioned Cisco switch hardware and Meraki has to put it in their easy dashboard interface.

It´s shurly not easy for them. But when sales or marketing want´s to have...

[Darren8]

So, I put 3 x MS390 switches into production recently and can report:

• Stacking didn't work - followed the specific MS390 instructions in the documentation multiple times
• Visibility information for MS390 is so wrong / inaccurate it is basically useless
• Sat waiting for support on the phone for an hour and gave up
• When I eventually got through to support the next day they said not to follow the documentation instructions and suggested I should have called them and was provided different instructions that require physical access again and an outage 🙄

Will see what happens when I can get back to site and have an outage.

Tried 12.30 and 12.28.

[PeteMoy]

Shocking to see how things are still so quirky after so many months...

[Bruce]

I'd try the MS 14.x firmware - yes, its beta, but then as someone else mentioned in another thread, the MS390's seem to be pretty much beta...

[Darren8]

I was very tempted but didn't want to risk it.

Support also said unless they tell you to for a specific reason you shouldn't have to (ie stacking should work with the stable release).

[cmr]

@Darren8 with the MS390, the versions after 12.28 bring you fixes about what client is reported where, PSU info, PoE info, routing fixes, crash fixes, the ability to change settings and not need to reboot the switch and more.

The only known downside of 14.8 that applies to the 390 is that the stack must be no more than 3, but you are okay with that.

[MichelRueger]

I just do Testing with MS14.8 Beta on my MS390 and yes there are some updates Like Power supply information but still a lot of things not working. Client Information is now OK. But you can not have more than 3 Switches in a Stack with Beta 14.8!!

Kabel Test is not Working.

Ping from the Switch goes up to more than 400ms and sometimes even up to 2 seconds!

hope to be able to post more updates soon.

[Darren8]

Got an outage window and back onsite and basically almost 5 hours later, 3 Meraki support engineers and still no data stack.

I followed the provided instructions which failed at step 1. Found a way around it and continued. Waited 3.5 hours after the final step for the stack to form and then called it.

Went with 12.32 this time.

Not a happy camper 🙄