What it's telling you is totally unclear, though. I've asked TAC to explain to me the packet behaviour that generates this errdisable, and haven't been able to get a clear answer from them. It seems to come out of 'nowhere' on multi-vendor networks, where all other vendors are perfectly happy and no operational or configuration issue is evident, other than Cisco shutting the port. As far as I can tell from the documentation's description of this case, it should not even be possible for it to trigger when LACP is in use (as the 'port channel' is negotiated by LACP, not configured by the user...), yet it certainly can. FWIW, I've also seen this between Juniper and Cisco, and have been forced to disable the misconfig detection. If you know exactly what Cisco's STP is telling me happened with this error, I'd really love to know, it might at least help to understand how it could be triggering, because it is definitely not 'port-channel misconfiguration'. Keenan On 2018-04-05 02:26 PM, Naslund, Steve wrote:
It really does not resolve anything it just allows a bad configuration to work. The guard is there so that if one side is configured as a channel and the other side is not, the channel gets shut down. Allowing it to remain up can cause a BPDU loop. Your spanning tree is trying to tell you something, you should listen or you could get really hard to isolate issues.
Steven Naslund Chicago IL
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Joseph Jenkins Sent: Thursday, April 05, 2018 4:16 PM To: Robert Webb Cc: nanog@nanog.org Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state
No there isn't, but from what I am getting responses both onlist and off list is to just run this on the Cisco switches:
no spanning-tree etherchannel guard misconfig
and that should resolve the issue.
Thanks Everyone.