MS switches in stack can't recover from power outage

[Netstatman]

I manage a fairly large network of several hundred meraki switches. All ms225. 

Every time there is a power outage a few stacks in IDFS going back to the core fail to recover.

On the cisco core it show the port-channel interfaces as suspended. The only thing that fixes them is when the Meraki switch is rebooted. This almost always happens to a stack of switches, and the first switch has the uplink ports. 

Of course needing to get sites back online, they are rebooted before any tech can make it out there to pull logs. I have also seen the local web page access doesn't work while its in this state. 
No routing is being done on these switches.

Has anyone else had this issues? Thanks

[PhilipDAth]

>On the cisco core it show the port-channel interfaces as suspended

If you do a down/up on the core switch ports - does the port-channel recover?

I've only done it a channel across multiple stack members, and I haven't had any issues yet.

Are the MS225s running current stable or better firmware?

[Netstatman]

We have had this issues across multiple code versions. We are on 16.8 today.

Yes, down/up the ports, but the cisco core says the meraki switch isn't sending LACP and suspends them again. Once the meraki switch is rebooted it comes right up.

[GIdenJoe]

On the cisco core on a port-channel interface add the configuration.  no port-channel standalone disable.

This will allow the ports to come up as individual ports and then you should check via the Cisco CLI if the Meraki switch are or are not sending LACPDU's.

[Netstatman]

During the last event I pulled one of the interfaces out of the port-channel and it stayed up, however it did not restore connectivity. 

[GIdenJoe]

Pulling cables won't have any effect on the Cisco side with the default behavior of port channels.  The moment you configure a port to be in a port-channel with LACP it will by default not allow the link to pass traffic if it does not negotiate LACP.  So it will be in suspended mode as you mentioned.

However if you disable that feature by using the command on the port channel like I said and the behavior returns you should see interfaces being up with a capital i (individual).  But it should pass traffic.

If you want to have any foot in the door with the Meraki devs you'll need to provide some evidence that the Meraki's are not sending LACPDU's after reboot causing the link to come up individually.  Then you can use show commands on the Cisco side to verify if LACPDU's are being received from the Meraki switches.

[Netstatman]

I didn't physically pull the cable out. What I did was shut down both ports, removed one port from the port-channel via "No channel-group" and then no shut that interface. The port then came up and I did learn some mac addresses from the other side, but Mgmt to the Meraki switch never restored. 
The core logs clearly indicated they were not receiving LACP.

*Aug 27 19:32:19.093: %ETC-5-L3DONTBNDL2: Twe2/0/34 suspended: LACP currently not enabled on the remote port.
*Aug 27 19:32:19.974: %ETC-5-L3DONTBNDL2: Twe1/0/34 suspended: LACP currently not enabled on the remote port.

Meraki support has come back with there is a bug in version 16.7+ with meraki switches having issues sending LACP when a port comes back up. They recommended we upgrade to 17.1.1. 
--Fixed an issue that caused unexpected LACP discarding states after aggregate links were restarted or reconnected