I believe that the 390 is actually running IOS-XE and the Meraki code is in a container on top and I think this is why certain more 'hardware features seem to be more difficult for them to code.
I might be wrong but the 9300 and 390 look very similar and there is even 0 difference in the names...
No functional MAC table, spotty reporting of connected ports, basically no poe reporting. Making it nearly impossible to track down a connected user. All you get out of support is that they are hoping the new software is ready in Sept.
Wow, so much rigorous testing of their software then 😉
I'm curious how they glean the information from the switch itself.
Does the software use some CLI which it then parses to retrieve the information for dashboard or is it also using some new kind of API stuff to retrieve the info.
Hi @CV_Tech , is the eqpt within the 30 day returns period? If so you’re well within your rights to return the eqpt.
as others have stated we haven’t touched these devices yet nor would recommend them. Too many unsolved bugs and bad user experience installing them.
The new firmware may resolve your issues. Then again they may not. Is your network usable or degraded and can you live with the issues?
I just returned our purchase and replaced with MS355s.
the latest version of stable release code 12.31 notes the following
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, QoS, Power Supply State, PoE power status/usage, Loop Detection, UDLD, MAC Flap Detection
some of these are addressed in beta version 14 but not all. Be cautious if you’re considering these devices.
My Cisco rep indicated the 390 is the meraki equivalent of the cat 9300. Cisco should let meraki be meraki, and catalyst be catalyst. IMHO.
@bmarms the 390 IS a 9300, just with Meraki management software running in a container on it. Fundamentally an excellent piece of hardware but it does seem integrating it into the Meraki management stack is a bigger challenge than originally imagined.
We are starting to replace our Cisco 3850s and are going the Meraki route but are choosing the MS355s instead of the MS390s that would have been the natural successor.
I installed these as a core switch for just a few VLANs, customer specifically wanted these. I literally had issues since day 1. My support ticket has been open for 3 months.
Power stacking doesn't work. I pulled the power on 1 switch and that switch turned off (no power stacking at all) Then when I powered it back up, it didn't come back online for 25 minutes. Supposedly support fixed it with a backend change, but I sure as hell won't test it.
The dashboard can't pickup and netbios names, and match the name to the IP.
SNMP doesn't work, and of course as we all know LLDP no workie either. The Release notes are abysmal. This switch can't do things that a $300 netgear switch can do, or even a low end Cisco Small Business switch. This is really sad, and I hope to god my customer doesn't need any of these features.
I'm so very disappointed in this product and that Meraki/Cisco would release an extremely flawed product. Lastly the communication on these issues has been nil from what I've seen. I'm just so very disappointed.
@RobinsonRoca what firmware are you running? I know there are still issues, but there has been a big concentration on the MS390 problems...
I'm on 12.30, With the track record so far I saw no real improvements based on the release notes on ver 14.12. The known issues section is relatively the same.
Indeed, there has been a lot of updates but unless you need power state, PoE monitoring, QoS, client reporting accuracy or adaptive policy (which it sounds like aren't a priority) then there are a large list of fairly static outstanding issues 😒
It doesn't really support 802.1q either. I mean, you can use 1000 VLANs, and that's it. You should be able to accommodate 4094 VLANs in your design according to the IEEE but Cisco thought that it was overkill (and Meraki is just using IOS, so...)
Sadly, Meraki hasn't done much communication with us on this topic except through release notes on the beta releases. I think this is "Kind of a big deal"
Well there latest beta is vast improvement. Client identification in the dashboard is still broken.... and I had to create a new profile on here.
Cisco RMA’d mine even though I was outside the 30 day return window. I pleaded false advertising. Had my 355 stack of 3 up and fully operational in about an hour. No troubles at all. If meraki truly becomes catalyst, I’ll move to ubiquity or something else for my user facing access layer. Meraki doesn’t need to transform into something they aren’t or weren’t. They have good switching and wireless products.
Why on earth would you have 1000 VLANs in the same L3 domain?
The switch does support the VLAN numbers from 1 to 4094 but you can only define up to 1000 VLAN's in total which is a normal limitation of the CAM/TCAM space. And it uses 802.1q to make trunks to other switches so yes it does support it.
@GIdenJoe It seems that the Cisco people had the same position that you do (1000 is enough). So, if it's a "normal thing", you're saying that Meraki lies when it tells you that it will pass the 4094 VLANs? (effectively the "all" setting, in any other switch but the MS390)
The all setting is simply defines the allowed list.
The allowed list is not the same as the actual number of VLANs that exist in your network.
On Catalyst switches you can also allow ALL VLAN's but you can't define more than a couple hundred of VLANs simultaneously on lower end switches.
I'm not sure internally Meraki also has to create those VLANs if you explicitly allow them on trunks or make access ports inside your network with specified VLAN's, but all other switches do, even HP and other brands.
I'm pretty sure if you would have a large L2 network and you define each access port in another VLAN you could run into trouble.
I was reading through the Change Logs again, and something caught my eye:
Why would an upgrade NOT cause a full system reload? What are they doing from 12.28 to 12.29 that an upgrade would not fully reload a switch? This is very interesting, it sounds as if they are in deed running the Meraki control plane in some sort of KVM on the switch. I wish Meraki would be a bit more transparent here. They know they messed up, why not just be transparent about it, and help us who are stuck with these switches be more in the know.
@GIdenJoe that seems about right. The only thing is that for the MS390 the allowed list gets validated, which means that you can't do "all" but you have to define an actual list (including ranges). According to earlier posts this would be a rebranded Catalyst 9300 but somehow that "ALL VLAN" won't work. (is the 9300 a "low end" switch? Maybe is just a software limitation coded in the Meraki bridge).
Oh, that's a little different. That reminds me of the Catalyst instant access switches, they also had that limitation.
Well in that case perhaps MS switches do support actual high number of VLAN's and they haven't found a way to translate that onto the Catalyst. Funny how architectures can differ so much.
And no the 9300 is a highend access switch.
Seeing that the regular MS switches do have fewer hardware features/options than Catalyst switches I believe the CAM/TCAM space is formatted differently. If you don't need that many features you can focus on having a huge number of VLANs. There is also the reason you only have 1 ACL set on an MS switch and it can only carry 100 or so entries.
On Catalyst for example you can do ACL's per port, per VLAN, in dynamic sessions, for matching other features, MAC ACL's, so I do believe you lose alot of TCAM space to support those features.