The next model up, the MS425's let you use configure the 40Gbe ports for either stacking or "standard" ports ... In fact, the 425's let you do that for any of their ports. So you can use some of the 10Gbe ports for stacking instead, or have no stacking ports at all.
"I would think that if a lacp issue with the software was causing this it would be a problem with the unstacked switch also"
From the release notes I posted for that 3750 software version; and you are channeling across the 3750's. That version incorrectly uses different ID's across the stack members.
– The EtherChannel is a cross-stack EtherChannel with a switch stack at one or both ends.
– The switch stack partitions because a member reloads. The EtherChannel is divided between the two partitioned stacks, each with a stack master.
The EtherChannel ports are put in the suspended state because each partitioned stack sends LACP packets with different LACP Link Aggregation IDs (the system IDs are different). The ports that receive the packets detect the incompatibility and shut down some of the ports. Use one of these workarounds for ports in this error-disabled state:
It does! I guess what used to work for a decade is irrelevant - it will annoy me to no end that this only happens with meraki - the 3850 stack software doesn't indicate there should be any lacp issues but yet it has major problems, only when connected to meraki - could be a different issue with the same symptoms I suppose. Keep in mind it works fine to a 3750 port channel spanned across member switches to a single meraki switch - it's not until I stack the meraki this happens. At least now I have a stack I can test with - unfortunately one of our 350's is a brick now so I can't test meraki to meraki aggregates - still have the root > designated designated >root events going on all the time, only when meraki aggregates are in use...good times
I configured the meraki switch stacks to never be root for the network and published vlan 1 across all trunked uplinks - the meraki stacks all acknowledge the cisco switches as root for the network now and there has not been a designated > root root > designated event since I made the changes at 5am this morning - the event logs from the previous few days indicate a STP event several times per day so that looks promising. I'll reconnect the port channel from my other bldg in the near future to verify that problem has gone away also.