topic Re: STP Safe Implementation Plans in ExtremeSwitching (EXOS/Switch Engine)

STP Safe Implementation Plans

gbrown — Mon, 31 Mar 2025 13:31:27 GMT

Long story short, I have recently began working at a university and I come from a Cisco background. The university is purely Extreme in switching and wireless. They have been having a problem for years where if someone does accidentally cause a loop a large portion of the campus shuts down. This has already happened a couple of times now since I started working here and is to me of the utmost importance to fix.

The issue lies with the 3rd party that installed the switches. They implemented ELRP only at the core. Therefore, when a loop occurs, it disables the corresponding port on the core which shuts off access to everything connecting off of it.

Anyways, I would like to implement STP for all of the switches. This summer, we plan to do a core upgrade. I have already setup the new core in a mlag setup. 2 7520s with the isc lag between them and mlagging two 5520s. Below is the configuration I am thinking for STP:

create vlan stpd_bpdu tag 4064
        configure vlan 4064 add ports all tagged
        configure stpd s0 mode dot1w
        enable stpd s0 rapid-root-failover
        configure stpd s0 default-encapsulation pvst-plus
        enable stpd s0 auto-bind vlan 4064
        configure stpd s0 ports link-type edge {edge_ports}
        configure stpd s0 ports edge-safeguard enable {edge_ports}
        configure stpd s0 ports bpdu-restrict enable {edge_ports} recovery-timeout 120
        configure stpd s0 tag 4064
        configure stpd s0 ports restricted-tcn on {edge_ports}
        enable stpd s0

In addition, the core will get:

configure stpd s0 priority 4096

Since stp configuration is quite a bit different than Cisco, I was wondering if this looks about right? I'm planning on introducing this to the core and then slowly rolling out towards the edge.

Re: STP Safe Implementation Plans

FredrikB-NN2 — Tue, 01 Apr 2025 12:48:09 GMT

Unless you actually have rings, I'd recommend ditching STP except for STP Edgeport in access. From what you write, the problem isn't the networking staff connecting stuff irresponsibly, but users that connect stuff that cause loops, right? Extreme has a protocol called ELRP which could be an alternative to STP Edgeport, but it has limitations that I don't like personally. STP Edgeport is a generic function that will give you all the protection you need without the massive drawbacks of STP. I guess I don't have to tell you about random topology changes and switches that can't keep up when this occurs, right?

STP was a great invention by Radia Perlman in the 80's, but come on, we've evolved! MLAG/SMLT or SPBm (and/or CWDM/DWDM) will give you the redundancy you need without 40 year old loop resolution protocols!

If you still actually need to build rings, you have EAPS as an alternative, but I can't say I prefer that due to lacking stability, especially in combination with stacks. For those cases, activate STP on the ring interfaces only, nothing else. Why would you? Nobody configures EAPS, ELRP or any other loop protection on all ports "just in case" as Cisco's argument for STP is.

If you still insist on STP, go for root bridge prio 0. Why is everyone so afraid of setting the best value, 0??? It has absolutely no drawbacks and you protect against more cases than with 4k. In switches from other vendors it is even possible to set the system ID, so there, I set the main root bridge to 00:00:00:00:00:01 and the secondary to 00:00:00:00:00:02, both with prio 0. At least nothing can beat that even if another unit could potentially have the same prio and ID. I have seen industrial switches with prio 0 and a low numbered MAC address taking out a factory plant.

Re: STP Safe Implementation Plans

Paul_W — Tue, 01 Apr 2025 13:03:44 GMT

+1 for using ELRP on all access port, and only use STP on switch uplinks if you want.
You can also configure ELRP to only disable for 300 second, so the loop "pings" every 5 minutes which is helpful as it resurfaces on the logs. That is handy if your logs are being filled up by other issues, and the device/user will periodically come up again to keep it from being forgotten. Don't forget to configure it on all VLANs, and keep the frequency from overwhelming your CPU.

Re: STP Safe Implementation Plans

Brian_Anderson1 — Tue, 01 Apr 2025 13:19:12 GMT

If you decide to go with stp, in the deployments I do, I leave spanning tree off of uplinks, and keep all the topo changes to the switch(es) in the closet.

Only advantage I've found stp over elrp is the bpdu restrict, to keep other switches from being plugged into network. If that isn't a concern I'd go ELRP, a lot simpler config.

Re: STP Safe Implementation Plans

Bill_Handler — Tue, 01 Apr 2025 13:43:01 GMT

GBrown,

We prefer ELRP to STP due to the fact that ELRP mitigates loops with 3rd party devices/dumb switches. We implement ELRP at nearly all levels except the core just for that reason. Usually in the core there are not connections to edge devices. I think a better option may to re-do the ELRP configuration so that your dedicated uplink ports are not part ELRP, while all your edge ports are configured for ELRP. This will also cut down on the number of ELRP packets flowing across the network uselessly. We've found in our deployments that using ELRP to disable the offending port for 300 seconds (as someone else mentioned) is also a good practice.

Are you all using XMC/XIQ-SE? Using the custom alarm feature to get more information on when a loop occurs is very beneficial. The trap lacks information to tell where the loop is - specific port numbers.

It may be worthwhile to reach out to your Extreme Partner (or a different one if the partner caused this issue...) or your Extreme Engineer for additional information.

Thanks,

Bill

Re: STP Safe Implementation Plans

Brent_Addis — Tue, 01 Apr 2025 18:42:44 GMT

Hellloooo The 90's called, they want their technology back 🤣.

I spent 15 years as a cisco engineer myself so know where you are coming from, but honestly, MSTP is a lot of work for very little gain, especially if you have MLAGS.

Why not roll ELRP out to the rest of the network? It's faster, safer and doesn't suffer from conversion times. You can setup ELRP exclusion ports which will listen out for ELRP loops but not lock the port.

Re: STP Safe Implementation Plans

Gabriel_G — Wed, 02 Apr 2025 13:04:53 GMT

Hi!

If you're interoping with Cisco, this config with PVST+ seems OK, provided that the carrier VLAN is tagged on all relevant ports. There are restrictions on using PVST+ with an untagged native VLAN.

You do not need to add ports to STP and also auto-bind the VLAN, you can just auto-bind the VLAN to STP which will also add all current and future ports in that VLAN to STP at the same time.

If you're doing all Extreme, keeping the MSTP mode and dot1d encapsulation defaults is probably easier.
In a very basic setup, the only configuration you'd need from defaults is:

enable stpd s0 auto-bind vlan <Auto-Bind All VLANs to s0>
enable stpd s0 #Enabled by default
#Edge Ports
configure stpd <STPD> ports link-type edge <Ports>

configure stpd <STPD> ports edge-safeguard enable <Ports> {recovery-timeout <Seconds>}

configure stpd <STPD> ports bpdu-restrict enable <Ports> {recovery-timeout <Seconds>}

An edge port configured with BPDU-restrict is disabled if an STP BPDU is received on the port. Equivalent to Cisco BPDU-guard.

An edge port configured with edge-safeguard immediately enters the forwarding state and transmits BPDUs. If a loop is detected, STP disables the port. By default, an edge port without edge-safeguard configured immediately enters the forwarding state but does not transmit BPDUs unless a BPDU is received by that edge port. Equivalent to Cisco spantree portfast.

Both commands have an optional recovery-timeout, the duration that the port is disabled in either event. If the recovery-timeout period is not specified, the port is disabled permanently until manually re-enabled or the switch is rebooted.

Hope that helps!