STP Configuration for SG300/SF300

[redbus]

I have configured RSTP on a set of switches I managed and just want to confirm I have done this correctly.

These switches are used within a business centre all in L2 mode with around 30 VLANs to keep each suites traffic seperate along with VoIP and wireless seperated.  Each switch has RSTP enabled, the trunk link ports for data-sw2/voice-sw1/voice-sw2/voice-sw3 have been set to a cost of 64 all other ports have a cost of 128.  The data-sw1 STP priority is set to 4096 with all other switches set to 8192.

Main reason I have enabled RSTP is due to a couple of occasions when a cable has been connected from one of the data ports to the voice ports such as data-sw2 to voice-sw1 which has caused the root port to change from the trunk port.

Does this look to be the correct configuration to always keep the trunk ports indicated in the diagram above set to forwarding?

Thanks.

[Jon Marshall]

Colin

Setting the STP priority on the root switch should work fine. When you say -

Main reason I have enabled RSTP is due to a couple of occasions when a cable has been connected from one of the data ports to the voice ports such as data-sw2 to voice-sw1 which has caused the root port to change from the trunk port

i'm assuming that this type of thing happened before you set the port costs and the STP priorities ?

If so i'm not sure how that happended. Assuming with no extra configuration data-sw1 had the lowest priority then it would be elected as the root bridge. So all uplinks to data-sw1 from the other switches would be the root ports. If you then connected a cable between the data-sw2 and voice-sw1 switches that should not have changed the root port ie.

data-sw2 now receives BPDU's direct from data-sw1. It also receives BPDUs from voice-sw1 but the cost of those BPDUs would be worse as they have gone through an extra switch so the root port should not have changed. Actually what should have happened is one of the ports on the connection between data-sw2 and voice-sw1 should have been blocked as connecting that cable would cause a loop and the other port would be the designated port.

So it's not clear, to me at least, how connecting that cable changed the root ports on either data-sw2 or voice-sw1.

Jon

[redbus]

Hi Jon,

Thanks for the reply.

Yes they have had two instances when a cable connected from data-sw2 to voice-sw1 and also an extra cable from data-sw1 to voice-sw1 has caused some users to be unable the network.  Soon as this was realised logged into the switch locally and seen that they root port had changed.  Before I changed the switches to RSTP today they were set to MSTP and they were not configured correctly.  I though because VLANs were in use it should have been MSTP but now relise RSTP is sufficient.

Each of the trunk links is configured to carry VLANs 1-30, all other ports are set to access mode and untagged in whichever VLAN is required. 

Hoping all is ok now - will give it a test when I next get a chance onsite when I have a downtime window.

Thanks.

[Jon Marshall]

Colin

Okay, if they were not configured correctly that may explain it.

What you have now should ensure that even if cables are connected between switches (not the data-sw1 switch) then RSTP should block one end of the link. The root port should not change from the trunk uplink from each switch.

If it doesn't work as expected feel free to come back with any queries.

Jon