This are also no new vlans being used at all. They are all already existing on the switches involved and nothing is being added. In fact what makes this even weirder is that I already have that exact same port configuration running on port 1/0/67 of the Juniper and it doesn't cause me any issues nor did it cause any issues when the config was applied. This existing port 1/0/67 has gone down/up as the firewall has been rebooted and doesn't cause any issues or hiccups on the network. For reference the attached firewall is an ASA which doesn't do spanning tree anyways. set interfaces ge-1/0/67 description "Firewall Port-2" set interfaces ge-1/0/67 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 9-10 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 29 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 31-32 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 43 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 50-51 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 56 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 58 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 66 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 68 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 90 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 143 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 170 On Thu, Apr 5, 2018 at 2:34 PM, Joseph Jenkins <joe@breathe-underwater.com> wrote:
Steve let me clarify the config I am applying has nothing to do with an LACP trunk or any of my existing LACP trunks. It is a completely different configuration on a completely different interface, the only similarity is that I am trying to configure a trunk interface on the Juniper side for multiple vlans. There is no LACP configuration involved.
On Thu, Apr 5, 2018 at 2:26 PM, Naslund, Steve <SNaslund@medline.com> 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.