Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The topic covers a few topics, so I would try to break this down further as means to provide more information as well as gain a better understanding about the technology.

First some background - we are running a local LAN Party with a lot of attendees. Connected computers vary between 200 and 600 (could be more). We have Netgear FS726T managed switches, with gigabit links leading to a core gigabit switch. The network is setup at least a couple of hours before people come in and is used for 24-48 hours. On those Netgear switches, we've enabled 802.1d to avoid loops, but everything is left with default settings.

We have control over the following STP 802.1d settings (with their ranges):

  • Bridge priority (0-65535)
  • Bridge Max Age (6-20)
  • Bridge Hello Time (1-10)
  • Bridge Forward Delay (4-30)

Per port:

  • Path cost (1-65535)
  • Priority (0-255)

Here are some follow up questions:

  • how can the 802.1d settings be tweaked to best suit this scenario?
  • can these changes have impact on network performance (both lag and transfer speeds)?

These are the changes I've been considering along with reasons why - is my thinking correct?

  • maximize age to avoid rebuilding the spanning tree calculations as much as possible (because the network won't change once it's established)
  • maximize hello time to minimize chatter (similar reasons to above)
  • minimize forward delay to start sending actual packets as quickly as possible
  • increase path cost on standard ports to avoid connected machines from hijacking traffic
  • decrease path cost on the link to the core switch to indicate preferable path
  • increase priority on the link to the core (same as above)

Any information and partial answers would be appreciated. Information on where to find more information on the topic would also be appreciated.

Thank you

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

see http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml

there are a lot of things involved with those timers, some of the things you seem to be concerned about look like premature optimization...

things you should do:

You want your core switch to be the spanning tree root. Set the bridge priority on your core switch to the lowest value. IOS lets you use the special priority 'primrary' which sets it to 8192, so I suppose you could use that. Make sure end user ports have portfast and bdpuguard or whatever Netgear supports for saying "this port should not feed other switches"

maximize hello time to minimize chatter (similar reasons to above)

I would not touch this, it affects everything else. I'm pretty sure increasing the hello time increases the time it takes to detect a loop, which is not what you want.

minimize forward delay to start sending actual packets as quickly as possible

This can be helpful if a cable is unplugged, but really it is only going to save you at most 30 seconds or so, which may not be enough to make it worthwhile.

increase path cost on standard ports to avoid connected machines from hijacking traffic

In ciscoland for end user ports you would enable portfast and bdpuguard and all that fun stuff.. end user ports should not be participating in spanning tree in the first place, so the port cost isn't really relevant.

decrease path cost on the link to the core switch to indicate preferable path

Should not need to do this if you make the core the spanning tree root

increase priority on the link to the core (same as above)

Should not need to do this if you make the core the spanning tree root

can these changes have impact on network performance (both lag and transfer speeds)?

No. The only thing they can help with is faster recovery if someone unplugs/reboots a switch. I'm going to assume that if that were to happen, any game in progress is going to get interrupted, so having it come back online after 15 seconds instead of 45 isn't going to make much of a difference to the players.

If you don't have a looped topology(aka redundant layer 2 links) then spanning tree isn't actually doing a whole lot.

share|improve this answer
add comment

maximize age to avoid rebuilding the spanning tree calculations as much as possible (because the network won't change once it's established)

The optimisations and changes that you're proposing are moot if the topology of the network won't be changing anyway. Spanning-tree is a low impact protocol in the first place. 600 ports / stations isn't that much in the big scheme of things considering spanning-tree.

The beauty of STP is that in the vast majority if cases, it looks after itself - by tinkering with the default, tried and tested defaults, you're risking making things worse for your event -- and may impact on your end users for the relatively short time they're using your network.

decrease path cost on the link to the core switch to indicate preferable path

increase priority on the link to the core (same as above)

It's almost as if you're trying to defeat the purpose of STP in the first place; what if you suddenly have to change the topology of your network (a switch or link goes down, and theres a STP convergence event?), you're going to spend time reconfiguring costs/priorities - something you wouldn't need to do if STP was left alone. By all means, configure a switch as a BDPU root and you won't need to worry about manual path costs.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.