You bet.  MX devices running MX 19+ firmware, MS devices running MS 17+ firmware and MS390/Catalyst devices running CS 17+ firmware will use the username admin and the password will be the serial number of the device (upper case letters and dashes).  https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page#Accessing_the_Local_Status_Page   ... View more

Hey @espenvp - have you already opened a support case to have us take a look at this? If the local status page is available, the switch isn't bricked, and likely that a level 3 reset at worst will restore the device to factory settings, but please call in and let our team have a look.    the local status page credentials were also recently changed, but support can help you with that as well. ... View more

Hey Philip, thanks (as always) for the feedback - sorry you’re having a poor experience. Generally this beta is working pretty well, but it sounds like this switch is likely stuck in ROMMON. I’d like to make sure we’re properly investigating - would you mind sending me the case number via DM and I’ll have the team take another look?   Will we see you next month at CL MEL? Would love to sit down and share a bit about what we’re doing and get your thoughts. ... View more

Sort of; MS switches don't actually reserve the requested power, and will allow oversubscription. So the switch will continue to provide power up to the actual available budget in use regardless. This is different than catalyst based and -M switches which will reserve the requested budget.  ... View more

Hi @TyShawn , I understand what you're saying; but know that we haven't limited the ports to 30W - that is all that the PoE chip is capable of providing. The intent was not to market the switch as BT to imply that more than 30W is available. Originally our datasheets only indicated the power budget in Watts. However, as this confusion arose, we've added some details to the datasheets to try to clarify that confusion. I agree that we may not have accomplished that clarity yet. For context, the PoE chip in the 130 models was chosen based on supply chain constraints when we were sourcing the components to ensure that we would have enough to build an adequate supply. Thanks for the feedback - we'll see what we can do to set better expectations.  ... View more

Hey @cmr, you may want to confirm this with an Catalyst wireless expert (which I am not), but I believe the 9166 is looking for the PSE to agree to the availability of over 30W, and the MS130 will not do that.  ... View more

Note that there are also MS130 models like MS130-8P, 24P, and 48P which have identical hardware specs to the MS120 for that exact use case - 1Gbps uplinks, and no mGig. The MS130 line up essentially combines the MS120 and 125 into one series, with the additional option of 2.5Gbps mGig.  ... View more

The MS130R launched a little bit later than the rest of the MS130 series. More info here. ... View more

Hey guys, we're working on adding support for more models all the time - the MS130 is just one step on that journey. Stay tuned for more. ... View more

Hey there! None of the MS switch lines ups are specifically targeted to SOHO, though they can be used there just fine. The100 series is the access-layer non-stackable option with multiple port-densities. Typical use cases for the lower port densities (compact 8-12 port) are really anywhere a smaller number of ports are needed - think retail for example. There's also no requirement to use an MX of any kind to get 10Gbps uplink bandwidth - an access layer switch will often be uplinked at 10Gbps (or more using LACP bundles) to a distribution or core layer switch where the stacking and L3 would often be. 10G connectivity maybe required within the LAN itself, and not just out to the Internet edge. Hope that helps. ... View more

Hey @jbright ! Brennan here from the Meraki Switching PM team 👋. I’m so glad you’re enjoying the new MS130! I wanted to point out that, while the PoE chipset is indeed capable of understanding 802.3bt negotiation, it is still only capable of providing 30W of power like 802.3at. What you’re seeing in Dashboard is a slightly confusing use of terminology - where it says “advertised” what it should say is that the “PD requested” 60W BT. We’re planning on changing the terminology in the near future to be more clear. Sorry if I’ve burst any bubbles! ... View more

Hey folks! I'm sorry that anyone has experienced issues with NAT detection - while it works well overall, we agree that it's not meeting our expectations so we're making arrangements to turn it off until we can tune it to be helpful without causing issues. Thank you for the feedback and patience! ... View more

Hey @Slobs2, I’m sorry to hear we’ve missed the mark for you on this. It was a tough decision but know that contrary to your experience, we’ve had a lot of customers that have had problems when they try to split stacks into separate upgrades. That being said, we also hear that being able to upgrade stacks without interruption would bring a lot of value for customers like yourself so we’ll investigate to see what is feasible.  ... View more

Gotcha! Sorry you ran into an upgrade issue, it’s frustrating when that happens. On the bright side, that’s not an issue with the staged upgrades feature 😁 ... View more

Hey @cmr, I want to make sure I understand correctly - were you able to split switches that are part of the same stack into separate upgrade groups, or were all of the switches of that stack in the same upgrade group and the issue occurred after attempting to upgrade that stack? ... View more

Hi @GIdenJoe  – the physical and flexible stacking logics are the same with regards to firmware upgrades. We’ve tested staggered upgrades on MS425s in the past and they are not hitless. For that reason, staged upgrades across members of stacks aren’t supported.   Convergence of hardware forwarding information should occur within 30 seconds of a failure or in this case a reboot for upgrade, however, this period could be longer depending on the nature of the failure, the definition of full convergence, and the protocols involved. For instance, if it’s the active switch in the stack that fails, protocols such as OSPF will have to re-establish adjacencies and synchronize the database. ... View more

Hey @cmr , I know right? Being able to keep a stack online during an upgrade (kinda like ISSU) is a super cool feature to have. Unfortunately, ISSU isn’t what’s actually happening there and we actually never supported splitting stacks into separate upgrade stages. In fact, doing that has caused problems where new and previous firmware images are mixed in a stack, resulting in forwarding and stability impacts that were not so awesome. Sorry to kill the mood there, we elected to play it safe on this one. That being said, something like ISSU is definitely something we’d like to look at properly implementing in the future so I’ll put a vote in the bucket on that item.    Thanks for the feedback. ... View more

Ok, cool. Thanks again for the feedback, and we’ll look into this! ... View more

Hey Blake! We’re definitely giving some thought to ways to search and quickly find switches to add to a group, so I’m glad to hear this came to mind for you too. We have a few ideas in mind to keep making staged upgrades even better, but wanted to get it out to you as quickly as possible because there’s nothing better than feedback from live networks.  I’m curious, how many switches are you dealing with in the network where you’d like to be able to search for switches to add to upgrade groups? ... View more