04-06-2025 03:37 PM - edited 04-06-2025 03:52 PM
Hi ,
Currently, we have the following connectivity in one of our offices, and the CORE-1 switch acts as the RSTP root bridge. Between CORE-1 and CORE-2 switches, we have a PO1 (port-channel) trunk interlink.
Recently, one of my colleague tried to add a new vlan across multiple trunk links and when he tried to configure switchport trunk allowed vlan add xxx ,in po1 interlink from CORE-2 Switch, switchport trunk allowed vlan "add" syntax wasn't copied correctly and did override all the vlans in that PO1 trunk link. (This was rectified and resolved immediately)
During this time, Operations teams had noticed that most of the Access points dissociated from the Wireless controller and reconnected back with in 30 seconds due to RSTP recalculation.
My question is , what are the additional steps we can take to minimise such service impacts when a single changes goes wrong in one link impacting entire building .
I am looking for some advice regarding design/topology/configuration changes should consider on this ?
Solved! Go to Solution.
04-07-2025 12:36 AM - edited 04-07-2025 12:42 AM
the main reasons for behaving RSTP in the same manner as "non-rapid" Standard RSTP are
1) single switches in the LAN operating in non-RSTP-Mode
- since they don't participate in "RSTP Handshaking" which is the way RSTP improves convergence time - and at least parts of the network have to fall back to "timer-based" 30sec convergence when topology-changes occur
2) Edge-Ports not configured as "STP Portfast" or "STP port-type-Edge" or Server/Trunk-Ports not configured as "STP port-type-edge-TRUNK"
=> any edge port (ports with no RSTP-Bridge behind) has to be configured as edge-port or edge-trunk-port
otherwise the switch "has to wait" (timer based, no handshaking for rapid convergence) and the whole STP-Convergence acts as non-RSTP with 30s delay.
=> a single edge-port in the LAN not configured as edge-port can break the whole STP-convergence behaviour
Doing this, you can expect "RSTP-Behaviour" with sub-second failover.
There have been STP-bugs in the code, yes - but 99% of all STP-"30s"-slow-convergence-issues I've been seeing in the field have been fixed using both config-check rules - at some part of your network it fails back to "classic STP"...
04-08-2025 05:32 AM
Hello @sasanka1912 ,
for Rapid STP to work as expected it is really important that all access ports in all access layer switches are configured as STP edge ports also known as spanning-tree portfast as it is explained by @r.heitmann .
it is not enough to have spanning-tree mode rapid-pvst to have fast convergence.
Hope to help
Giuseppe
04-09-2025 09:56 AM
Yup. What @r.heitmann "b" case was trying to avoid is also explained here: https://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/10583-62.html#toc-hId--925083550
04-06-2025 09:49 PM - edited 04-06-2025 09:51 PM
Hello @sasanka1912
Regarding your topology, ensure proper STP root bridge and backup configurations, assigning CORE-1 as the root with the lowest priority and CORE-2 as the secondary with a slightly higher one.
Avoid using dynamic vtp modes by setting all switches to vtp transparent mode and manually managing vlan popagation to prevent un-intended overwrites.
On the "operational side", enforce etherchanel consistency by using lacp instead of static configuration, and enable features like BPDU guard on access ports and loop guard on trunk links to catch misconfigurations early...
For long term stability, see to migrate into a L3 core design, which reduces the scope of L2 domains and the impact of STP events.
04-07-2025 12:57 AM
M02@rt37 Thanks for your reply and Core 1 and Core-2 currently configured as STP priority with 8192 and 16384.
Port channels are configured as channel-group xxx mode on on both ends instead of active/passive to for LACP.
all the switches are configured with VTP transparent mode as well.
Finally re-l3 DESIGN instead of L2 , do you have example configuration /topology you may be able to advise ?
04-07-2025 01:12 AM
"Routed access is an alternative configuration in which Layer 3 is extended all the way to the access layer switches. In this design, access layer switches act as full Layer 3 routed nodes (providing both Layer 2 and Layer 3 switching), and the access-to-distribution Layer 2 uplink trunks are replaced with Layer 3 point-to-point routed links. Consequently, the Layer 2/ Layer 3 demarcation point is moved from the distribution switch to the access switch, as illustrated in Figure 22-10."
source: CCNP ENCOR 350-401_Chap.22 "Enterprise Network Architecture"
Because there are no L2 links to block, this design eliminates the need for STP and both uplinks from access to distribution can be used, increasing the effective bandwidth available.
04-07-2025 01:21 AM
M02@rt37 Thanks .Will look further in to this ..
04-07-2025 03:47 AM
You're welcome @sasanka1912
You talk about AP and Wireless Controller... so I suppose your are focus on a Campus Design ? not Datacenter ? right ?
04-07-2025 04:50 AM
M02@rt37 yes That's correct .. This is a campus set up..
04-07-2025 12:36 AM - edited 04-07-2025 12:42 AM
the main reasons for behaving RSTP in the same manner as "non-rapid" Standard RSTP are
1) single switches in the LAN operating in non-RSTP-Mode
- since they don't participate in "RSTP Handshaking" which is the way RSTP improves convergence time - and at least parts of the network have to fall back to "timer-based" 30sec convergence when topology-changes occur
2) Edge-Ports not configured as "STP Portfast" or "STP port-type-Edge" or Server/Trunk-Ports not configured as "STP port-type-edge-TRUNK"
=> any edge port (ports with no RSTP-Bridge behind) has to be configured as edge-port or edge-trunk-port
otherwise the switch "has to wait" (timer based, no handshaking for rapid convergence) and the whole STP-Convergence acts as non-RSTP with 30s delay.
=> a single edge-port in the LAN not configured as edge-port can break the whole STP-convergence behaviour
Doing this, you can expect "RSTP-Behaviour" with sub-second failover.
There have been STP-bugs in the code, yes - but 99% of all STP-"30s"-slow-convergence-issues I've been seeing in the field have been fixed using both config-check rules - at some part of your network it fails back to "classic STP"...
04-07-2025 12:59 AM
04-08-2025 12:26 PM
@r.heitmann @Giuseppe Larosa Thanks for the details. I spotted that ports are not configured as STP Portfast. Will raise a change to correct those..
04-08-2025 02:40 PM
@sasanka1912 wrote:
@r.heitmann @Giuseppe Larosa Thanks for the details. I spotted that ports are not configured as STP Portfast. Will raise a change to correct those..
BTW, another important reason for using portfast on edge ports, it makes them known as edge ports, so they don't send TCNs every time the port goes down/up.
Also, there a global configuration command (spanning-tree portfast default) to make all access ports, by default, portfast.
04-07-2025 11:09 AM
30 seconds is an long time for rapid STP convergence except perhaps if a root election was triggered.
You say you're sure rapid STP is configured on all devices, not pvst, but to confirm, you meant rapid-pvst is configured, correct?
How many VLANs are on the cores?
Do VLANs span edge switches?
What link is blocked between the triangle of the two cores and an edge switch? I.e. do you block the port-channel or a switch uplink?
04-07-2025 02:15 PM - edited 04-08-2025 01:15 AM
@Joseph W. Doherty : All the switches are configured with Rapid-PVST, and we have around 12 VLANs in the core. Core switches act as the gateway, as we have SVIs configured for all those VLANs in the core, and OSPF will redistribute connected routes and advertise them into the WAN.
Re- Do VLANs span edge switches? yes ,Core SVI's acts as the gateway for vlans on the edges.
What link is blocked between the triangle ? - From every access switch , we have port channels connecting to Core-1 and Core-2 and currently all the port channels connecting to core-2 have been blocked.
04-08-2025 05:32 AM
Hello @sasanka1912 ,
for Rapid STP to work as expected it is really important that all access ports in all access layer switches are configured as STP edge ports also known as spanning-tree portfast as it is explained by @r.heitmann .
it is not enough to have spanning-tree mode rapid-pvst to have fast convergence.
Hope to help
Giuseppe
04-08-2025 02:44 PM
For other reasons, only "sharing" a VLAN with one L2 edge device and its L3 switches, is (usually) better.
You're using a FHRP on the core L3 switches? Which, and how is the active gateway selected, i.e. always on core1 or shared between the two cores? If the former, outbound WAN traffic just using one link or two links?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide