Configurações ótimas de desempenho para o Spanning Tree Protocol (802.1d) para ambiente de LAN (jogos)

6

O tópico aborda alguns tópicos, então eu tentaria dividir isso ainda mais como meio de fornecer mais informações, bem como obter um melhor entendimento sobre a tecnologia.

Primeiro, alguns antecedentes - estamos administrando uma LAN Party local com muitos participantes. Computadores conectados variam entre 200 e 600 (pode ser mais). Temos switches gerenciados Netgear FS726T, com links gigabit levando a um switch gigabit central. A rede é configurada pelo menos duas horas antes de as pessoas entrarem e serem usadas por 24 a 48 horas. Nesses comutadores Netgear, ativamos o 802.1d para evitar loops, mas tudo fica com as configurações padrão.

Temos controle sobre as seguintes configurações do STP 802.1d (com seus intervalos):

  • Prioridade de ponte (0-65535)
  • Idade máxima da ponte (6-20)
  • Bridge Hello Time (1-10)
  • Atraso de encaminhamento de ponte (4-30)

Por porta:

  • Custo do caminho (1-65535)
  • Prioridade (0-255)

Aqui estão algumas perguntas de acompanhamento:

  • como as configurações do 802.1d podem ser ajustadas para melhor se adequarem a esse cenário?
  • estas alterações podem ter impacto no desempenho da rede (tanto a latência quanto a velocidade de transferência)?

Estas são as mudanças que eu estive considerando junto com as razões pelas quais - meu pensamento está correto?

  • maximiza a idade para evitar reconstruir os cálculos da árvore de abrangência o máximo possível (porque a rede não será alterada depois de estabelecida)
  • maximizar o tempo de ola para minimizar a conversa (motivos semelhantes aos acima)
  • minimize o atraso de encaminhamento para começar a enviar pacotes reais o mais rápido possível
  • aumenta o custo do caminho em portas padrão para evitar que máquinas conectadas trafeguem tráfego
  • diminuir o custo do caminho no link para o comutador principal para indicar o caminho preferencial
  • aumenta a prioridade no link para o núcleo (o mesmo que acima)

Qualquer informação e respostas parciais serão apreciadas. Informações sobre onde encontrar mais informações sobre o tema também serão apreciadas.

Obrigado

    
por Ivan Peevski 05.03.2010 / 04:41

2 respostas

3

veja link

há muitas coisas envolvidas com esses timers, algumas das coisas com as quais você parece se preocupar parecem ser uma otimização prematura ...

coisas que você deve fazer:

Você deseja que seu switch de núcleo seja a raiz da árvore de abrangência. Defina a prioridade da ponte no seu comutador principal para o valor mais baixo. O IOS permite que você use a prioridade especial 'primrary', que a define como 8192, então eu suponho que você poderia usar isso. Certifique-se de que as portas do usuário final tenham portfast e bdpuguard ou o que o Netgear suportar para dizer "esta porta não deve alimentar outros switches"

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

Eu não tocaria nisso, isso afetaria todo o resto. Tenho certeza que aumentar o tempo de ola aumenta o tempo necessário para detectar um loop, que não é o que você deseja.

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

Isso pode ser útil se um cabo for desconectado, mas na verdade ele economizará no máximo 30 segundos, o que pode não ser suficiente para valer a pena.

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

Na ciscoland para portas de usuário final você habilitaria portfast e bdpuguard e todas essas coisas divertidas. as portas de usuário final não deveriam estar participando da árvore de abrangência, então o custo da porta não é realmente relevante.

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

Não precisa fazer isso se você fizer o núcleo da raiz da árvore de abrangência

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

Não precisa fazer isso se você fizer o núcleo da raiz da árvore de abrangência

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

Não. A única coisa que eles podem ajudar é uma recuperação mais rápida se alguém desconectar / reinicializar um switch. Suponho que, se isso acontecer, qualquer jogo em andamento será interrompido, portanto, tê-lo novamente on-line após 15 segundos, em vez de 45, não fará muita diferença para os jogadores. / p>

Se você não tiver uma topologia em loop (também conhecida como links redundantes da camada 2), a árvore de abrangência não estará realmente fazendo muito.

    
por 05.03.2010 / 05:20
3

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

As otimizações e alterações que você está propondo são irrelevantes se a topologia da rede não estiver mudando de qualquer maneira. Spanning-tree é um protocolo de baixo impacto em primeiro lugar. 600 portas / estações não são muito no grande esquema das coisas, considerando a spanning tree.

A beleza da STP é que, na grande maioria dos casos, ela cuida de si mesma - alterando os padrões padrão, experimentados e testados, você está arriscando a piorar as coisas para o seu evento - e pode impactar no seu fim usuários pelo tempo relativamente curto que estão usando sua rede.

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)

É quase como se você estivesse tentando derrotar o propósito de STP em primeiro lugar; E se de repente você tem que mudar a topologia da sua rede (um switch ou link desce, e há um evento de convergência de STP?), você vai gastar tempo reconfigurando custos / prioridades - algo que você não precisaria fazer se STP foi deixado sozinho. Por todos os meios, configure um switch como uma raiz de BDPU e você não precisará se preocupar com os custos do caminho manual.

    
por 05.03.2010 / 06:19