Switches de LAN : Spanning Tree Protocol

Entendendo as Alterações de Topologia do Spanning-Tree Protocol

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (10 Outubro 2005) | Feedback

Interativo: Este documento oferece uma análise personalizada de seu dispositivo Cisco.

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Finalidade do Mecanismo de Alteração de Topologia
Princípio de Operação
      Notificação da Bridge Raiz
      Broadcast do Evento para a Rede
O Que Fazer Quando Houver Muitas Alterações na Topologia da Rede
      Tráfego Inundado
      Problema em Ambientes com Bridge ATM LANE
      Como Evitar a Geração de TCNs com o Comando portfast
      Rastreamento da Origem de uma TCN
Conclusão
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Ao monitorar as operações doSTP (Spanning-Tree Protocol), você poderá ficar preocupado ao ver os contadores de alterações de topologia serem incrementados no log de estatísticas. Essas alterações são normais no STP. Entretanto, um número excessivo de alterações poderá afetar o desempenho da rede. Este documento explica que a finalidade dessa topologia é:

  • Alterar o mecanismo em ambientes PVST (per-VLAN spanning tree) e PVST+.

  • Determinar o que dispara um evento de alteração de topologia.

  • Descrever os problemas relacionados ao mecanismo de alteração de topologia.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração padrão. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documentos, consulte as Convenções de Dicas Técnicas da Cisco.

Finalidade do Mecanismo de Alteração de Topologia

Com base nos frames recebidos, uma bridge cria uma tabela que associa a uma porta os endereços MAC (Media Access Control) dos hosts que podem ser acessados através dessa porta. Essa tabela é utilizada para encaminhar os frames diretamente à sua porta de destino. Portanto, a inundação é evitada.

O tempo de validade padrão dessa tabela é 300 segundos (cinco minutos). Somente após um host ter permanecido em silêncio por cinco minutos, sua entrada desaparece da tabela da bridge. O exemplo apresentado aqui mostra por que você poderia desejar que esse tempo fosse mais curto:

Nesta rede, considere que a bridge B1 esteja bloqueando o seu link com a bridge B4. A e B são duas estações com uma conexão estabelecida. O tráfego de A para B é encaminhado a B1, B2, B3 e, depois, a B4. O esquema mostra a tabela de endereços MAC aprendida pelas quatro bridges nessa situação:

17a.gif

Agora, suponha que haja uma falha no link entre B2 e B3. A comunicação entre A e B é interrompida pelo menos até que B1 coloque sua porta para B4 no modo de encaminhamento (máximo de 50 segundos com parâmetros padrão). Entretanto, quando A deseja enviar um frame para B, B1 ainda possui uma entrada que leva a B2, e o pacote é enviado para um "buraco negro". O mesmo se aplica quando B deseja alcançar A. A comunicação é perdida por cinco minutos, até que as entradas referentes aos endereços MAC de A e B expirem.

17b.gif

Os bancos de dados de encaminhamento implementados por bridges são muito eficientes em uma rede estável. Entretanto, há várias situações em que o tempo de validade de cinco minutos é um problema após uma alteração da topologia da rede. O mecanismo de alteração de topologia é uma solução para esse tipo de problema. Assim que uma bridge detecta uma alteração na topologia da rede (um link que se torna inativo ou que entra no modo de encaminhamento), ela anuncia o evento para toda a rede com bridge.

A seção Princípio de Operação explica como esse mecanismo é implementado na prática. Em seguida, todas as bridges são notificadas e reduzem o tempo de validade para forward_delay (15 segundos, por padrão) durante determinado período (max_age + forward_delay). É preferível reduzir o tempo de validade do que limpar a tabela, uma vez que os hosts ativos no momento, que transmitem efetivamente o tráfego, não são removidos da tabela.

Neste exemplo, assim que a bridge B2 ou B3 detecta que o link ficou inativo, ela envia notificações de alteração de topologia. Todas as bridges ficam a par do evento e reduzem o seu tempo de validade para 15 segundos. Como B1 não recebe pacotes de B em sua porta que leva a B2 em 15 segundos, ela expira a entrada destinada a B nessa porta. O mesmo acontece com a entrada destinada a A na porta que leva a B3 em B4. Posteriormente, quando o link entre B1 e B4 entra no modo de encaminhamento, o tráfego é imediatamente inundado e reaprendido nesse link.

Princípio de Operação

Esta seção explica como uma bridge anuncia uma alteração de topologia no nível da BPDU (Bridge Protocol Data Unit). .

Uma breve explicação do que ocorre quando uma bridge considera que detectou uma alteração de topologia já foi fornecida. A definição exata é:

  • Quando uma porta que estava fazendo encaminhamento é desativada (por exemplo, é bloqueada).

  • Quando uma porta entra no modo de encaminhamento e a bridge tem uma porta designada. (Isso significa que a bridge não é independente.)

O processo de envio de uma notificação para todas as bridges da rede envolve dois passos:

  • A bridge notifica a bridge raiz da spanning tree.

  • A bridge raiz faz "broadcast" das informações para toda a rede.

Notificação da Bridge Raiz

Em uma operação normal do STP, uma bridge recebe continuamente BPDUs de configuração da bridge raiz em sua porta raiz. Entretanto, ela nunca envia uma BPDU para a bridge raiz. Para que isso seja possível, uma BPDU especial denominada TCN (notificação de alteração de topologia) foi introduzida. Portanto, quando uma bridge precisa sinalizar uma alteração de topologia, ela começa a enviar TCNs na sua porta-raiz. A bridge designada recebe a TCN, reconhece-a e gera outra TCN para sua própria porta raiz. O processo continua até que a TCN atinja a bridge raiz.

17c.gif

A TCN é uma BPDU muito simples que não contém absolutamente nenhuma informação enviada por uma bridge a cada hello_time segundos (esse é o hello_time configurado localmente, e não o especificado nas BPDUs de configuração). A bridge designada reconhece a TCN enviando imediatamente de volta uma BPDU de configuração normal com o conjunto de bits TCA (reconhecimento de alteração na topologia). A bridge que notifica a alteração na topologia não para de enviar sua TCN até que a bridge designada a reconheça. Portanto, a bridge designada responderá à TCN mesmo que não receba a BPDU de configuração de sua raiz.

Broadcast do Evento para a Rede

Quando a raiz reconhece que houve um evento de alteração de topologia na rede, ela começa a enviar suas BPDUs de configuração com o conjunto de bits TC (alteração de topologia). Essas BPDUs são retransmitidas por todas as bridges da rede com esse conjunto de bits. Como resultado, todas as bridges ficam a par da situação de alteração de topologia e podem reduzir seu tempo de validade para forward_delay. As bridges recebem BPDUs de alteração de topologia nas portas de encaminhamento e de bloqueio.

O bit TC é definido pela raiz para um período igual a max_age + forward_delay segundos, que, por padrão, é 20+15=35 segundos.

17d.gif

O Que Fazer Quando Houver Muitas Alterações na Topologia da Rede

A seguir são apresentados alguns dos problemas que podem ser gerados pela TCN, bem como algumas informações sobre como limitar as alterações de topologia e localizar sua origem.

Caso tenha a saída de um comando show-tech support de seu dispositivo Cisco, você poderá utilizar a Output Interpreter (somente clientes registrados) para exibir possíveis problemas e correções. Para utilizar a Output Interpreter (somente clientes registrados), você deverá ser um cliente registrado, estar conectado e ter o JavaScript ativado.

Tráfego Inundado

Quanto mais hosts houver na rede, maiores serão as chances de ocorrer uma alteração de topologia. Por exemplo, um host conectado diretamente dispara uma alteração de topologia quando é desligado e religado. Em redes muito grandes (e planas), poderá chegar um momento em que elas tenham permanentemente o status de alteração de topologia, como se o tempo de validade estivesse configurado como 15 segundos, o que resulta em um alto nível de inundação. Veja aqui o pior cenário que ocorreu com um cliente que estava executando um backup de um servidor.

17e.gif

A expiração da entrada do dispositivo que recebe o backup foi um desastre, pois fez com que um tráfego muito intenso atingisse todos os usuários. Consulte a seção Como Evitar a Geração de TCNs com o Comando portfast para saber como evitar a geração de TCNs.

Problema em Ambientes com Bridge ATM LANE

Este caso é mais crítico do que a inundação normal do tráfego decorrente de uma expiração rápida. Mediante o recebimento de uma alteração de topologia em uma VLAN, as placas LANE (LAN emulation) de um Catalyst switch reconfirmam sua tabela LE-arp para a ELAN (emulated LAN) correspondente. Como todas as placas LANE na ELAN emitem o mesmo pedido ao mesmo tempo, isso poderá sobrecarregar o LES (LAN Emulation Server) se houver muitas entradas a serem reconfirmadas. Problemas de conectividade foram observados nesse cenário. Se a rede for sensível a uma alteração de topologia, o verdadeiro problema não será a alteração em si, mas o design da rede. É recomendável limitar o máximo possível a geração de TCNs para poupar a CPU do LES (pelo menos). Consulte a seção Como Evitar a Geração de TCNs com o Comando portfast para limitar a geração de TCNs.

Como Evitar a Geração de TCNs com o Comando portfast

O recurso portfast é uma alteração proprietária da Cisco na implementação do STP. O comando é aplicado a portas específicas e tem dois efeitos:

  • As portas ativadas são colocadas diretamente no modo STP de encaminhamento, em vez de passarem pelo processo de reconhecimento e escuta. O STP ainda é executado em portas com portfast.

  • O switch nunca gera uma TCN quando uma porta configurada para portfast é ativada ou desativada.

Ative o recurso portfast nas portas em que há grande probabilidade de os hosts conectados ativarem e desativarem seus links (normalmente estações finais que os usuários desligam e religam com frequência). Esse recurso não deve ser necessário para portas de servidor. Ele deve ser evitado nas portas que levam a hubs ou a outras bridges. Uma porta que entra diretamente no estado de encaminhamento em um link redundante poderá causar loops temporários de bridging.

As alterações de topologia podem ser úteis, portanto, não ative o recurso portfast em uma porta na qual a ativação ou a desativação de um link é um evento relevante para a rede.

Rastreamento da Origem de uma TCN

Uma notificação de alteração de topologia em si não é um evento ruim, mas, como um bom administrador de rede, é melhor que você saiba sua origem para ter certeza de que ela não está relacionada a um problema real. Identificar a bridge que emitiu a alteração de topologia não é uma tarefa fácil. Entretanto, ela não é tecnicamente complexa.

A maioria das bridges conta somente o número de TCNs emitidas ou recebidas. Os Catalyst 4500/4000, 5500/5000 e 6500/6000 podem mostrar a porta e o ID da bridge que enviou a última alteração de topologia recebida. Assim, partindo da raiz, é possível chegar à bridge de origem. Consulte o comando show spantree statistics para obter mais informações.

Caso tenha a saída de um comando show-tech support de seu dispositivo Cisco, você poderá utilizar a Output Interpreter (somente clientes registrados) para exibir possíveis problemas e correções. Para utilizar a Output Interpreter (somente clientes registrados),você deverá fazer login como um cliente registrado e ter o JavaScript ativado.

Conclusão

É importante lembrar que uma TCN não inicia um recálculo de STP. Esse receio ocorre porque as TCNs costumam ser associadas a ambientes STP instáveis; as TCNs são uma consequência disso e não a sua causa. A TCN tem impacto somente no tempo de validade. Ela não altera a topologia nem cria um loop.

O número ou a taxa de alterações de topologia em si não é um problema. O problema é saber o que a alteração significa. Uma rede em bom estado poderá apresentar uma elevada taxa de alterações de topologia. Entretanto, teoricamente, a alteração deve estar relacionada a um evento relevante na rede, como a ativação ou a desativação de um servidor ou a transição do estado de um link. Isso é alcançado com a ativação do recurso portfast nas portas que são ativadas e desativadas como parte de sua operação normal.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 12013