Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
BayStack 28115 Switch - Rebuild Spanning Tree 1
- Thread starter RikClarke
- Start date
-
1
- #2
thenetwraith
MIS
Spanning tree converges in as little as 120 seconds for a properly configured tree. Large and poorly configured tree's can take longer. Improperly configured tree's may never properly converge.
LATTISPAN changes a few variables, hence, mileage may be different.
General spanning tree tips.
1) Choose ROOT bridge priority carefully. You should have some idea which one or two bridges need to compete for the ROOT. They should either be in the core section of the network (backbone) or be the closest to network conversion hardware (FDDI to Ethernet, etc).
2) Other bridges should become leaf bridges. Set the priority higher for these so they can't compete for ROOT unless the LAN becomes partitioned by failure. Since spanning tree allows multiple links, this should not happen, but.....
3) Spanning tree allows multiple links, but, don't fill every port with a link to every other switch. This will cause convergence delays. Having a couple of links between main ROOT candidate bridges and one link from each ROOT candidate to each LEAF bridge should be enough. (This will allow for a ROOT candidate failure, and still maintain integrity -- should take about 60 seconds to fail-over).
More complex bridge setups are possible. My suggestion for these is:
SETUP a TEST LAN. Don't play with this on a production LAN until you have a majority of the SPAN issues solved. A test LAN will take care of all problems except those generated by heavy traffic and protocol interaction. The test LAN can also be made to simulate bad hardware, by creating failure scenarios. Don't move into production without taking advantage of this type of test.
Spanning tree can either be a great redundancy tool or one of the worst LAN nightmares in the business. Your diligence beforehand pays off in the end....
Reply-to: netwraith@pcrd.net
thenetwraith (There is a picture here, but, you just can't see it!)
LATTISPAN changes a few variables, hence, mileage may be different.
General spanning tree tips.
1) Choose ROOT bridge priority carefully. You should have some idea which one or two bridges need to compete for the ROOT. They should either be in the core section of the network (backbone) or be the closest to network conversion hardware (FDDI to Ethernet, etc).
2) Other bridges should become leaf bridges. Set the priority higher for these so they can't compete for ROOT unless the LAN becomes partitioned by failure. Since spanning tree allows multiple links, this should not happen, but.....
3) Spanning tree allows multiple links, but, don't fill every port with a link to every other switch. This will cause convergence delays. Having a couple of links between main ROOT candidate bridges and one link from each ROOT candidate to each LEAF bridge should be enough. (This will allow for a ROOT candidate failure, and still maintain integrity -- should take about 60 seconds to fail-over).
More complex bridge setups are possible. My suggestion for these is:
SETUP a TEST LAN. Don't play with this on a production LAN until you have a majority of the SPAN issues solved. A test LAN will take care of all problems except those generated by heavy traffic and protocol interaction. The test LAN can also be made to simulate bad hardware, by creating failure scenarios. Don't move into production without taking advantage of this type of test.
Spanning tree can either be a great redundancy tool or one of the worst LAN nightmares in the business. Your diligence beforehand pays off in the end....
Reply-to: netwraith@pcrd.net
thenetwraith (There is a picture here, but, you just can't see it!)
- Status
Similar threads
- Locked
- Question
- Locked
- Question