Embracing the Cloud - Cisco Meraki and VMWare's stingy Essentials license

I hate the term 'Cloud' as it refers broadly to an approach that has been around for a long time, so it really is a buzzword and nothing more, but I'll concede that it is simpler to just use the term in the interest of brevity...

In considering replacement network hardware for our cheapish-and-cheerfulish Netgear kit we're faced with a few core options.  HP, Dell, Cisco Meraki are in the mix, as are some other less well known players, but for a single IT staff resourced company Meraki is so tempting as to be worth taking the risks associated with a cloud managed system.  I have a Meraki AP and an 8 port Meraki switch that I got for free by attending some webinars (cunning strategy, IMO) and they really are so very easy to provision and manage and look good too (not that it matters when they will be mostly hidden away).

There are lots of nay-sayers around using Cloud for one thing or another, and the privacy and security oriented part of me (with it's roots in my early days as a *nix sysadmin) agrees with them all.  However, we have taken the plunge for many management and commercial reasons, not least of which being the trend in our industry and our lean approach to IT staffing.  So the fact that Meraki is cloud managed is OK with me, in this context.  Horror stories about delayed renewals taking networks down merely re-enforce the need to manage one's contracts properly (and are increasingly older stories, so I suspect it is more well managed in general now).

Having said that, we are not a huge operation IT-wise, and our environment on-premise is mostly virtual.  This puts us in the VMWare Essentials Plus license band, which suits us almost perfectly, being affordable (though not cheap) and allowing us a HA cluster at our larger site and a single server at the smaller site (so resilience between sites at the application level and at one site at the infrastructure level).

I have always used LAGs to mitigate against bandwidth problems for the VMWare physical connections, though of course the ability for a LAG to mitigate the problem is a lot more limited than people often think.  The added resilience is handy too.  On our NetGear switches we just set up a LAG and ignore LACP and it just works.  On the Meraki switch we are told (by Meraki) that this will not work - their documented method is to enable LACP and use a VMWare distributed switch, which we can't do as the Essentials Plus license doesn't include that feature.  Upgrading to a full vSphere license is pretty costly (looks like somewhere around the £5-6K mark, with an associated annual maintenance increase - a lot for one tiny feature IMO).

Meraki theorise that doing the same as we do now, but turning RSTP off on the LAG will work.  They warn about the chance of loops, but from my understanding of vSwitches spanning tree is not necessary as the vSwitch prevents loops itself.

Of course, I can't commit to the new hardware without being sure that this will work, so it's time to vmotion all the guests onto one of the two cluster nodes and move the freed up host to my 8 port meraki switch for some testing (I could dredge up enough hardware to build a test system, just about, but I would feel better using my live host and it would be a lot quicker - 1 man IT dept, remember...)

Mind you, I do have an apprentice starting soon, so if I don't get to this before then they could learn a lot by building out a VMWare host....  Hmm.

Whichever I decide I'll post the results of the test here as I cannot find any posts on the Internet saying whether this works (which makes me wonder if many people use Essentials Plus)

UPDATE: I did the testing with the production ESXi host and couldn't persuade the Meraki and the server to work reliably with an aggregated link - ports would shutdown (presumably because the Meraki was trying to use LACP and VMware wasn't) and some VLANs worked but others didn't.  What did work was to use "Route based on the originating virtual port" - sadly the Essentials license doesn't include the variant of this that takes load into account, so there's no clever load balancing, but there is some arbitrary spread and at least the links are redundant.  The nice thing about this is it requires no configuration on the switch other than making the ports into trunks.