@Kevin-Davis said in RSTP Topology Change Causes Server Problems:
We have three clustered windows servers utilizing aggregated trunk lines to connect to our switches. As I understand it, when a switch is added to the network, RSTP will initiate a topology change?
Right, it has to calculate for the addition of the switch and run STP to see whether or not it will become the
root bridge. The easiest way to eliminate that quickly is to assign a lower priority to the switch you want to be the root bridge.
When this happens, are all ports not running portfast placed into discarding--this is equivalent to disabled, blocking and learning in the original STP (802.1D).
Portfast means that it immediately switch into to
forwarding state. We do this if we're telling the switch to not expect BPDUs from the connecting devices.
So if the ports you're connecting to are not sending out BPDUs, then these ports would switch from their off state to forwarding if in
portfast. If it receives a BPDU the it forward or blocks based on the RSTP process.
For whatever reason, all our hosts lost heartbeat at the same time and it was coincident with plugging in a new switch so I can only assume this is what killed our cluster. If all of this is correct, will adding "spanning-tree portfast trunk" fix the issue? (a command I didn't know existed)
I haven't tried this command. This command allows you to make a link to a trunk without having to go through the RSTP process. But having said that, you may have the use case for it. Usually, where you see this in a router on a stick configuration (a router with a trunk) and of course in your description...a server that has a trunk link as well (as the fact that it a layer 3 device, networkwise, that is trunked on server side as well.).
The good thing is you can simply try typing it in...if it works, it's your solution! if not simply remove the configuration.