Yes, the wire-port-profile is trusted.
Here you go:
version 8.11.2.0-8.11.2
virtual-controller-country GB
virtual-controller-key 7f755cd90118a5e1da75216586fe7eeae81ab3f06105a5455e
name xxxx
terminal-access
telnet-server
ntp-server time.google.com
clock timezone London 00 00
clock summer-time BST recurring last sunday march 02:00 last sunday october 02:00
rf-band 5.0
allow-new-aps
allowed-ap dc:b7:ac:c5:af:d0
allowed-ap dc:b7:ac:c5:ac:40
allowed-ap 48:2f:6b:c1:02:10
allowed-ap 48:2f:6b:c1:00:74
allowed-ap 48:2f:6b:c1:08:cc
allowed-ap 48:2f:6b:c1:01:66
allowed-ap 48:2f:6b:c1:07:d4
allowed-ap fc:7f:f1:c7:6e:bc
allowed-ap fc:7f:f1:c7:6e:70
allowed-ap fc:7f:f1:c7:6f:3e
allowed-ap fc:7f:f1:c7:6f:22
allowed-ap 48:2f:6b:c0:cf:a2
allowed-ap 48:2f:6b:c0:cf:f0
allowed-ap 48:2f:6b:c0:d0:10
allowed-ap fc:7f:f1:c7:6e:ca
allowed-ap 48:2f:6b:c0:cf:4e
allowed-ap 48:2f:6b:c0:d0:94
allowed-ap d0:d3:e0:cd:52:b8
allowed-ap d0:d3:e0:cd:52:8c
allowed-ap dc:b7:ac:c5:ad:f4
allowed-ap dc:b7:ac:c5:ac:9c
arm
wide-bands 5ghz
a-channels 140
min-tx-power 127
max-tx-power 127
band-steering-mode prefer-5ghz
air-time-fairness-mode default-access
channel-quality-aware-arm-disable
client-aware
scanning
rf dot11g-radio-profile
interference-immunity 5
max-distance 0
disable-arm-wids-functions off
free-channel-index 40
rf dot11a-radio-profile
interference-immunity 5
max-distance 320
max-tx-power 33
min-tx-power 18
disable-arm-wids-functions off
rf dot11a-secondary-radio-profile
interference-immunity 5
max-tx-power 0
min-tx-power 0
syslog-level warn ap-debug
syslog-level warn network
syslog-level warn security
syslog-level warn system
syslog-level warn user
syslog-level warn user-debug
syslog-level warn wireless
hash-mgmt-password
hash-mgmt-user admin password hash 57642a4e02e436c3a5e29e1544736c37c21e79c0451f993fadca7ed9c7a88f853d4de1b8b7
wlan access-rule default_wired_port_profile
index 0
rule any any match any any any permit
wlan access-rule wired-SetMeUp
index 1
rule masterip 0.0.0.0 match tcp 80 80 permit
rule masterip 0.0.0.0 match tcp 4343 4343 permit
rule any any match udp 67 68 permit
rule any any match udp 53 53 permit
wlan access-rule Aruba-Mesh
index 2
rule any any match any any any permit
wlan ssid-profile Aruba-Mesh
enable
index 0
type employee
essid Aruba-Mesh
wpa-passphrase bd2d1ac14471aff5c317af4487ff89561c1d33292456bff7
opmode wpa2-psk-aes
max-authentication-failures 0
rf-band all
captive-portal disable
hide-ssid
dtim-period 1
broadcast-filter arp
deny-intra-vlan-traffic
dmo-channel-utilization-threshold 90
local-probe-req-thresh 0
max-clients-threshold 64
auth-survivability cache-time-out 24
wlan external-captive-portal
server localhost
port 80
url "/"
auth-text "Authenticated"
auto-whitelist-disable
https
blacklist-time 3600
auth-failure-blacklist-time 3600
ids
wireless-containment none
wired-port-profile wired-SetMeUp
switchport-mode access
allowed-vlan all
native-vlan guest
no shutdown
access-rule-name wired-SetMeUp
speed auto
duplex auto
no poe
type guest
captive-portal disable
no dot1x
wired-port-profile default_wired_port_profile
switchport-mode trunk
allowed-vlan all
native-vlan 1
trusted
no shutdown
deny-intra-vlan-traffic
access-rule-name default_wired_port_profile
speed auto
duplex full
poe
type employee
auth-server InternalServer
captive-portal disable
no dot1x
enet0-port-profile default_wired_port_profile
uplink
preemption
enforce none
failover-internet-pkt-lost-cnt 10
failover-internet-pkt-send-freq 30
failover-vpn-timeout 180
airgroup
disable
airgroupservice airplay
disable
description AirPlay
airgroupservice airprint
disable
description AirPrint
cluster-security
allow-low-assurance-devices
AP14#
Original Message:
Sent: Nov 22, 2023 01:46 PM
From: JS90
Subject: Spanning Tree & Wireless Mesh Links
Are the ports trusted? Can you attach your config again? It didn't come through previously.
------------------------------
Josh
Original Message:
Sent: Nov 22, 2023 01:09 PM
From: AR68
Subject: Spanning Tree & Wireless Mesh Links
That field is currently left empty (which seems correct to me). Screenshot attached.
The AP is currently tagging management traffic on VLAN 1631 and the switchport is configured as follows (same both ends):
vlan trunk native 1
vlan trunk allowed 1609,1611,1631
Connectivity between the switches is fine. The switches are in the same management VLAN and I can SSH & ping across the link without an issue. The problem is restricted to STP being blocked / dropped by the APs.
Original Message:
Sent: Nov 22, 2023 01:00 PM
From: JS90
Subject: Spanning Tree & Wireless Mesh Links
Also check "Uplink switch native VLAN" in Configuration > System > Advanced > General. Is it set to 1631?
------------------------------
Josh
Original Message:
Sent: Nov 22, 2023 12:48 PM
From: JS90
Subject: Spanning Tree & Wireless Mesh Links
Did you try matching the native VLANs on both sides. Looks like 1631 in this case.
------------------------------
Josh
Original Message:
Sent: Nov 22, 2023 12:29 PM
From: AR68
Subject: Spanning Tree & Wireless Mesh Links
RE the native VLAN...
The APs were configured with no management VLAN (untagged mgmt traffic). The switchports were configured as follows:
vlan trunk native 1631
vlan trunk allowed 1609,1611,1631
As a test I've configured the management VLAN on the APs as 1631 and I've amended the Switchport config as follows:
vlan trunk native 1
vlan trunk allowed 1609,1611,1631
Unfortunately I'm unable to remove VLAN 1 from the switch or interface, and unfortunately this test made no improvement. Still no BPDUs being received by either switch.
Original Message:
Sent: Nov 22, 2023 11:57 AM
From: JS90
Subject: Spanning Tree & Wireless Mesh Links
To reiterate, STP needs to be disabled in the AP configuration in order for the AP to pass BPDUs instead of participate in STP. I would double check the native vlan is set appropriately.
------------------------------
Josh
Original Message:
Sent: Nov 22, 2023 11:35 AM
From: JS90
Subject: Spanning Tree & Wireless Mesh Links
There is also a spanning tree knob in the AP system profile. What is it set to? Is this IAP based or Controller based?
------------------------------
Josh
Original Message:
Sent: Nov 22, 2023 11:18 AM
From: AR68
Subject: Spanning Tree & Wireless Mesh Links
I've spent several hours with TAC and unfortunately they're unable to determine the cause of the problem.
Initially we started with spanning-tree and loop-protect disabled on the wired-port-profiles of the APs (and BPDUs were not passed between the switches).
As a test I've enabled spanning-tree and loop-protect on the wired-port-profiles of the APs but BPDUs are still not being passed over the wireless link.
Original Message:
Sent: Nov 22, 2023 10:51 AM
From: JS90
Subject: Spanning Tree & Wireless Mesh Links
It's generally not advised to use STP to bring up two mesh links for redundancy.
Did you disable STP in the AP system profile? When STP is enabled in the AP system profile, the APs participate in wired STP and the STP frames stop at the AP and won't go over the mesh.
You may need to open a TAC case so they can look at your specific use case.
------------------------------
Josh
Original Message:
Sent: Nov 22, 2023 10:29 AM
From: AR68
Subject: Spanning Tree & Wireless Mesh Links
We have an issue whereby x2 6100 switches connected via a 570 series mesh link (x2 AP577 devices) will not pass BPDUs between the switches over the wireless link. The issue is that each switch becomes a STP root bridge and if an additional wireless link is connected between these switches a loop is formed and the network floods. When the switches are connected via a CAT6 patch cable STP negotiates and elects a single root bridge (as expected).
Can see that both switches are sending BPDUs to each local AP, but neither switch is receiving BPDUs. Ethernet bridging is enabled on one of the APs and a mesh link is established between Portal & Point. Connectivity over the mesh link is working as expected, but STP traffic is not being passed over the link.
Any help would be appreciated. Many thanks