I don't see any issue with the snippet of the config you provided for the 
"Firewall Port". Is there a chance that the port ge-0/0/67 is referenced 
somewhere else in the Juniper config that when applying your trunk setup is 
causing issues?

Just throw that out off the top of my head and not really thinking it through.

Robert

-----Original Message-----
From: NANOG <nanog-boun...@nanog.org> On Behalf Of Joseph Jenkins
Sent: Thursday, April 5, 2018 4:58 PM
To: nanog@nanog.org
Subject: Juniper Config Commit causes Cisco Etherchannels to go into 
err-disable state

I have cases open with both Cisco and Juniper on this, but wanted to see if 
anyone else had seen an issue like this because support has no idea.

I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4 switches. 
I have 4 separate stacks of Cisco 3750 switches with 2x1GB uplinks bound into 4 
different LACP trunks. I have had it happen twice now where I apply a trunk 
port config(not an LACP trunk) to a port that isn't a part of any of the LACP 
trunks and it causes all 4 of the Etherchannels on the Cisco stacked switches 
to go into an err-disable state with these
messages:

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Gi1/0/48, putting Gi1/0/48 in err-disable state

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Po17, putting Gi1/0/48 in err-disable state

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Po17, putting Po17 in err-disable state

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet1/0/48, changed state to down

Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on 
Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2)

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
GigabitEthernet2/0/48, changed state to down

Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
Port-channel17, changed state to down

Here is the config I am applying to the port that has caused this issue to 
happen twice now:

set interfaces ge-0/0/67 description "Firewall Port"
set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode trunk 
set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 9-10 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 29 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 31-32 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 43 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 50-51 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 56 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 58 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 66 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 68 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 90 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 143 set 
interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 170

The issue happens within a couple of minutes of committing the config on the 
Juniper side, there are no cables plugged into port 0/0/67 so technically there 
shouldn't be any BPDU's sent out since there isn't a port change.

Juniper Support wants me to turn on trace option and then run though a bunch of 
scenarios, the issue is that testing this takes down my network.

Just wanted to put it out there to see if anyone else had run into a situation 
similar to this.

TIA

Joe

Reply via email to