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
