Pg 27 does cover off the access switch for an Aruba CX access switch. I'm running 2930F.
While it doesn't talk about MST regions it's clear from the config they don't set MSTP config-name or version and the default values for Aruba CX means each switch will end up as its own MST region. Looking at the output of the commands shown on the access layer CX switch you can see the 'regional root address' is the local access switch while the bridge address and designated root address is the aggregation/core. So whoever wrote this guide didn't design it so that you had a common MST region for all access switches and that each access layer switch would be it's own MST region. Either that or it's an oversight.
I did test this out in my lab with various loops created and it does work correctly with each switch as its own MST region. Rebooting am access switch didn't result in stability issues either.
With a non blocking VSX core/aggregation I was thinking that the multiple MST regions may be desirable over a common region? Make a mistake on one switch/stack in a common MST region and better chance of impacting the other switches in the same region?
Mauricio, I am using loop protection too now as there are some scenarios where it will add benefit. Loops in the access layer are the most likely situation.
------------------------------
Campbell Simpson
------------------------------
Original Message:
Sent: May 11, 2022 05:05 AM
From: Vincent Giles
Subject: AOS-CX M-LAG & Spanning-tree flapping
By curiosity, doesn't p.27 of VSX Config best practices cover the access switch configuration for single MSTP instance ?
------------------------------
Vincent Giles
Original Message:
Sent: May 10, 2022 11:34 PM
From: Campbell Simpson
Subject: AOS-CX M-LAG & Spanning-tree flapping
I have a 2 layer design with a L3 core pair of VSX switches running an MST region and then L2 access AOS switches running their own individual regions with LAG uplinks to the VSX pair. It was a case of following the 'VSX Configuration Best Practices for Aruba CX 6400, 8320, 8325, 8360, 8400' version 1.3 which didn't really discuss the access layer but did include examples for AOS switches, but without setting the config-name or config-version. So I've fallen into doing this design without realising it likely isn't ideal. Spanning tree is really only there to mitigate against miss configuration of LAG uplinks and to protect against the access layer switch ports. It's working fine with no port blocking occurring under normal conditions and will correctly block ports on the access layer when a loop is introduced.
I'm trying to figure out if I need to go to the trouble of migrating all the switches at site into a common MST region or if the multiple MST regions and VSX core switch as CST root is ok
------------------------------
Campbell Simpson
Original Message:
Sent: May 10, 2022 08:01 AM
From: Richard Litchfield
Subject: AOS-CX M-LAG & Spanning-tree flapping
Do you need to have multiple instances? It would be a lot simpler to have just the instance 0 (CST) for everything. All the links are active with LACP, so the load balancing we used to do back before clustering options (like IRF, VSF, VSX, etc) were available are no longer necessary.
------------------------------
Richard Litchfield
Airheads MVP 2020, 2021, 2022
Original Message:
Sent: Mar 07, 2022 11:03 PM
From: Jax Dao
Subject: AOS-CX M-LAG & Spanning-tree flapping
Ok, I have made a change on each access switch by the following procedures:
1/ set bpdu-filter on trunk port
spanning-tree bpdu-filter
2/ re-config stp to match the aggregation switches.
spanning-tree config-name productionmstp
spanning-tree config-revision 1
spanning-tree instance 1 vlan 2-99 101-199 888 4000-4094
spanning-tree instance 2 vlan 200-299
spanning-tree instance 3 vlan 100 999-1099
spanning-tree trap topology-change instance cst
3/ config all edge ports
spanning-tree admin-edge-port
spanning-tree root-guard tcn-guard bpdu-protection
4/ remove bpdu-filter on trunk port.
------------------------------
Jax
Original Message:
Sent: Mar 02, 2022 10:15 PM
From: Jax Dao
Subject: AOS-CX M-LAG & Spanning-tree flapping
Thank you for your kind advice, Thomas and Stanislav!
I have applied the same stp config to the access switches (ASW). While doing this, the topology change message still broadcasts and then causing the unchanged ASW flapping. Is there a way to mitigate this, anyway?
hpe-mstpd[2916]: Event|2011|LOG_INFO|AMM|1/5|Topology Change received on port lag10 for CIST
------------------------------
Jax
Original Message:
Sent: Mar 02, 2022 09:15 AM
From: Stanislav Naydenov
Subject: AOS-CX M-LAG & Spanning-tree flapping
Hi Jax,
There are no name, revision and instances configured for MSTP on the access switches. Should all switches reside in the same region or how the desired spanning-tree topology should look like?
Two switches will become members of the same region, if the following is matching: same name, version and the same VLANs to instance mapping
If I understand your config correctly, the switches are now in different regions and the topology change is considered as CST topology change.
Additionally make sure you have configured manually a VSX system-mac for the VSX cluster for stable STP operation.
------------------------------
Stanislav Naydenov
Original Message:
Sent: Mar 02, 2022 03:31 AM
From: Thomas Siegenthaler
Subject: AOS-CX M-LAG & Spanning-tree flapping
Hi Jax
it seems as you are using multiple instances on the 8400 switches but only 1 on the access switch. Why don't you match the MSTP configuration?
Regards,
Thomas
------------------------------
Thomas Siegenthaler
Original Message:
Sent: Mar 01, 2022 10:16 PM
From: Jax Dao
Subject: AOS-CX M-LAG & Spanning-tree flapping
Hi Everyone,
I have deployed a campus collapsed LAN core by using a pair of 8400X in VSX and connecting to access switches of 5400R zl2 via M-LAG link of 2x 10G ports, along with spanning tree mode mstp as the illustrated photo for reference.
However, there is an issue occurred when an access switch reboots after a power loss, which causes Topology changes on lag10 and drops traffic of the other access switch on lag20. This leads to multiple end-devices losing their connection to the gateway as well as service link corruption.
hpe-mstpd[2916]: Event|2011|LOG_INFO|AMM|1/5|Topology Change received on port lag10 for MSTI 1
hpe-mstpd[2916]: Event|2011|LOG_INFO|AMM|1/5|Topology Change received on port lag10 for MSTI 2
hpe-mstpd[2916]: Event|2011|LOG_INFO|AMM|1/5|Topology Change received on port lag10 for MSTI 3
hpe-mstpd[2916]: Event|2011|LOG_INFO|AMM|1/5|Topology Change received on port lag10 for CIST
Please advise me on how to mitigate this issue or suggest the best practice in STP config between the aggregation VSX and access switch!
This is the VSX M-LAG config on VSX pair.
interface lag 10 multi-chassis
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
lacp fallback
spanning-tree root-guard
exit
interface lag 20 multi-chassis
no shutdown
no routing
vlan trunk native 1
vlan trunk allowed all
lacp mode active
lacp fallback
spanning-tree root-guard
exit
interface 1/9/2
no shutdown
mtu 9100
lag 10
exit
interface 1/9/3
no shutdown
mtu 9100
lag 20
exit
Spanning tree config on VSX pair
spanning-tree
spanning-tree mode mstp
spanning-tree priority 0
spanning-tree trap topology-change instance 0
spanning-tree config-name productionmstp
spanning-tree config-revision 1
spanning-tree instance 1 vlan 2-99,101-199,888,4000-4094
spanning-tree instance 2 vlan 200-299
spanning-tree instance 3 vlan 100,1000-1099
Default Spanning tree config on access switch
spanning-tree
spanning-tree mode mstp
spanning-tree Trk1 priority 4
spanning-tree A1-A20 admin-edge-port
spanning-tree A1-A20 root-guard tcn-guard bpdu-protection
LACP config on access switch
interface Trk1
tagged vlan 3,11,40,100-101,888,4000
untagged vlan 1
spanning-tree priority 4 loop-guard
exit
------------------------------
Jax Dao
------------------------------