Troubleshooting de STP em Catalyst Switches com Cisco IOS System Software

Introduction

Este documento fornece as diretrizes para usar o software Cisco IOS® para resolver problemas com o Spanning-Tree Protocol (STP). Há comandos específicos que se aplicam somente ao Catalyst 6500/6000; contudo, é possível aplicar a maioria dos princípios a qualquer switch Cisco Catalyst que executa o software Cisco IOS.

A maioria da solução de problemas do STP gira em torno de três problemas:

• loops de encaminhamento

• inundação excessiva causada por alta taxa de Alterações na Topologia STP (TC)

• questões relacionadas com o tempo de convergência

Como o bridging não tem nenhum mecanismo para rastrear se um determinado pacote está sendo encaminhado várias vezes (por exemplo, um TTL (Time to Live, Tempo de Vida IP) é usado para descartar o tráfego que está circulando muito tempo na rede), apenas um caminho pode existir entre dois dispositivos no mesmo domínio de Camada 2 (L2).

A finalidade do STP é bloquear portas redundantes com base em um algoritmo STP, para resolver a topologia física redundante em uma topologia em árvore. Um loop de encaminhamento (como um loop de STP) ocorre quando nenhuma porta em uma topologia redundante é bloqueada e o tráfego é encaminhado em círculos indefinidamente.

Quando o loop de encaminhamento começa, é provável que ele congestione os links de largura de banda mais baixa ao longo de seu caminho — se todos os links tiverem a mesma largura de banda, todos os links provavelmente estarão congestionados. Esse congestionamento causará a perda de pacotes e levará a uma situação de rede inativa no domínio L2 afetado.

Com inundação excessiva, os sintomas podem não ser tão aparentes. Alguns links lentos podem ficar congestionados por tráfego inundado e dispositivos ou usuários por trás desses links congestionados podem sofrer lentidão ou perda total de conectividade.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Vários tipos de árvore de abrangência e como configurá-los. Consulte Configuração de STP e MST IEEE 802.1s para obter mais informações.

• Vários recursos do Spanning Tree e como configurá-los. Consulte Configuração de Recursos STP para obter mais informações.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Catalyst 6500 com mecanismo Supervisor 2

• Cisco IOS Software Release 12.1(13)E

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Por que o STP falha?

O STP faz certas suposições sobre seu ambiente operacional. Estas são as suposições mais relevantes para este documento:

• Cada link entre as duas pontes é bidirecional. Isso significa que, se A se conectar diretamente a B, então A receberá o que B enviou e B receberá o que A enviou, desde que o link esteja ativo entre eles.

• Cada bridge que está executando o STP pode receber, processar e transmitir regularmente BPDUs (STP Bridge Protocol Data Units, Unidades de Dados de Protocolo de Bridge), também conhecidas como pacotes STP.

Embora essas suposições pareçam lógicas e óbvias, há situações em que elas não são atendidas. A maioria dessas situações envolve algum tipo de problema de hardware; no entanto, defeitos de software também podem levar a falhas de STP. Várias falhas de hardware, configurações incorretas ou cabeamento incorreto causam a maioria das falhas de STP, enquanto as falhas de software são responsáveis pela minoria. Falhas de STP também podem ocorrer devido a conexões adicionais desnecessárias que existem entre os switches. As VLANs entram em um estado inativo devido a essas conexões adicionais. Para resolver esse problema, remova todas as conexões indesejadas entre os switches.

Quando uma dessas suposições não é atendida, uma ou mais bridges podem não receber ou processar as BPDUs. Isso significa que a bridge (ou as bridges) não poderão descobrir a topologia de rede. Sem o conhecimento da topologia correta, o switch não pode bloquear os loops. Portanto, o tráfego inundado circulará pela topologia em loop, consumirá toda a largura de banda e desativará a rede.

Exemplos de por que os switches podem não receber BPDUs incluem transceptores defeituosos ou conversores de interface Gigabit (GBICs), problemas de cabeamento ou falhas de hardware na porta, na placa de linha ou no mecanismo Supervisor. Um motivo frequente para falhas de STP é um link unidirecional entre as bridges. Em tal condição, uma bridge envia BPDUs, mas a bridge downstream nunca os recebe. O processamento STP também pode ser interrompido por uma CPU sobrecarregada (99% ou mais), porque o switch não consegue processar BPDUs recebidos. As BPDUs podem ser corrompidas ao longo do caminho de uma bridge para outra, o que também impede o comportamento correto do STP.

Além dos loops de encaminhamento, em que as portas não são bloqueadas, em certas situações, apenas alguns pacotes são encaminhados incorretamente pelas portas de bloqueio. Na maioria dos casos, isso é causado por problemas de software. Tal comportamento pode causar "laços lentos". Isso significa que alguns pacotes estão em loop, mas a maioria do tráfego ainda está fluindo pela rede, porque os links provavelmente não estão congestionados.

As seções restantes neste documento fornecem diretrizes para a identificação e solução de problemas relacionados ao STP mais comuns.

Troubleshooting de Circuitos de Encaminhamento

Os loops de encaminhamento variam muito em sua origem (causa) e efeito. Devido à grande variedade de problemas que podem afetar o STP, este documento só pode fornecer diretrizes gerais sobre como solucionar problemas de loops de encaminhamento.

Antes de começar a solucionar o problema, você deve obter estas informações:

• Um diagrama de topologia real que detalha todos os switches e bridges

• Seus números de porta correspondentes (interconectando)

• Detalhes da configuração do STP, como qual switch é a raiz e a raiz de backup, quais links têm um custo ou prioridade não padrão e a localização das portas de bloqueio

Geralmente, a solução de problemas envolve estas etapas (dependendo da situação, algumas etapas podem não ser necessárias):

1. Identifique o loop.

   Quando um loop de encaminhamento se desenvolveu na rede, estes são os sintomas comuns:

   • Perda de conectividade para, de e através das regiões afetadas

   • Utilização alta de CPU em roteadores conectados a segmentos afetados ou VLANs que podem levar a vários sintomas, como o Routing Protocol Neighbor Flapping ou o Hot Standby Router Protocol (HSRP) Active Router Flapping

   • Grande utilização de link (com freqüência, 100)

   • Alta utilização da placa-mãe de switch (comparada à utilização de linha de base)

   • Mensagens de syslog que indicam loop de pacote na rede (por exemplo, mensagens de endereço IP duplicado de HSRP)

   • Mensagens de syslog que indicam mensagens constantes de retransmissão de endereço ou de oscilação de endereço MAC

   • Um aumento no número de saídas provoca cancelamentos em muitas interfaces

   Observação: qualquer um desses motivos sozinho pode indicar problemas diferentes (ou nenhum problema). No entanto, quando muitos desses motivos são observados ao mesmo tempo, é muito provável que um loop de encaminhamento tenha se desenvolvido na rede.

   Observação: a maneira mais rápida de verificar isso é verificar a utilização do tráfego do painel traseiro do switch:

   cat# show catalyst6000 traffic-meter
   
     traffic meter =   13%  Never cleared
              peak =   14%  reached at 12:08:57 CET Fri Oct 4 2002

   Observação: o Catalyst 4000 com software Cisco IOS não suporta atualmente esse comando.

   Se o nível de tráfego atual estiver bem acima do normal ou se o nível da linha de base não for conhecido, verifique se o nível de pico foi alcançado recentemente e se está próximo do nível de tráfego atual. Por exemplo, se o nível de tráfego de pico for de 15% e ele tiver sido alcançado há apenas dois minutos e o nível de tráfego atual for de 14%, isso significa que o switch está funcionando com uma carga excepcionalmente alta.

   Se a carga de tráfego estiver em um nível normal, isso provavelmente significa que não há nenhum loop ou que esse dispositivo não está envolvido no loop. No entanto, ele ainda pode estar envolvido em um loop lento.

2. Descobrir a topologia (o escopo) do circuito.

   Uma vez estabelecido que o motivo da interrupção da rede é um loop de encaminhamento, a prioridade mais alta é parar o loop e restaurar a operação da rede. Para parar o loop, você deve saber quais portas estão envolvidas no loop: examine as portas com a maior utilização de link (pacotes por segundo). O comando show interface Cisco IOS Software exibe a utilização para cada interface.

   Para exibir somente as informações de utilização e o nome da interface (para uma análise rápida), você pode usar a filtragem de saída de expressão regular do software Cisco IOS. Emita o comando show interface | inclua o comando line|\/sec para exibir apenas as estatísticas do pacote por segundo e o nome da interface:

   cat# show interface | include line|\/sec
   
   GigabitEthernet2/1 is up, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/2 is up, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/3 is up, line protocol is up
     5 minute input rate 99765230 bits/sec, 24912 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/4 is up, line protocol is up
     5 minute input rate 1000 bits/sec, 27 packets/sec
     5 minute output rate 101002134 bits/sec, 25043 packets/sec
   GigabitEthernet2/5 is administratively down, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/6 is administratively down, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/7 is up, line protocol is down
     5 minute input rate 0 bits/sec, 0 packets/sec
     5 minute output rate 0 bits/sec, 0 packets/sec
   GigabitEthernet2/8 is up, line protocol is up
     5 minute input rate 2000 bits/sec, 41 packets/sec
     5 minute output rate 99552940 bits/sec, 24892 packets/sec
   

   Preste atenção especial às interfaces com a maior utilização de link. Neste exemplo, são as interfaces g2/3, g2/4 e g2/8; provavelmente são as portas envolvidas no loop.

3. Interromper o loop.

   Para quebrar o loop, você deve desligar ou desconectar as portas envolvidas. É muito importante não apenas parar o loop, mas também encontrar e corrigir a causa raiz do loop. É relativamente mais fácil quebrar o loop.

   Observação: para ajudar na análise de causa subsequente, você não precisa desligar ou desconectar todas as portas de uma só vez; em vez disso, feche um de cada vez. Geralmente, é melhor desligar portas no ponto de agregação afetado pelo loop, como um switch de distribuição ou de núcleo. Se você desligar todas as portas de uma só vez e ativá-las ou reconectá-las uma a uma, isso pode não funcionar; o loop será interrompido e talvez não seja iniciado imediatamente após a porta ofensiva ser reconectada. Portanto, seria difícil correlacionar a falha a qualquer porta específica.

   Observação: é recomendável coletar informações antes de reinicializar os switches para interromper o loop. Caso contrário, a análise subsequente da causa raiz será muito difícil.

   Depois de desativar ou desconectar cada porta, você deve verificar se a utilização do painel traseiro do switch está de volta ao nível normal.

   Observação: lembre-se de que, geralmente, algumas portas não estão sustentando o loop, mas estão inundando o tráfego que chega com o loop. Quando você desliga essas portas de inundação, você só reduzirá a utilização do backplane em uma pequena quantidade, mas não interromperá o loop.

   No próximo exemplo de topologia, o loop é entre os switches A, B e D. Portanto, os links AB, AD e BD são sustentáveis. Se você desligar qualquer um desses links, parará o loop. Os enlaces AC, AE, BC e BE são apenas tráfego de inundação que chegam com o loop.

   

   Depois que a porta de sustentação for desligada, a utilização do backplane baixará para um valor normal. É muito importante observar qual desligamento de porta elevou a utilização do painel traseiro (e a utilização de outras portas) a um nível normal.

   Neste ponto, o loop será interrompido e a operação da rede deverá melhorar; no entanto, como a causa original do loop provavelmente não foi corrigida, ainda pode haver alguns problemas pendentes.

4. Localizar e corrigir a causa do loop.

   Depois que o loop for interrompido, você precisará determinar o motivo pelo qual o loop começou. Esta é frequentemente a parte mais difícil do processo, porque os motivos podem variar. Também é difícil formalizar um procedimento exato que funcione em todos os casos. No entanto, estas são algumas diretrizes gerais:

   • Investigue o diagrama de topologia para encontrar um caminho redundante. Isso inclui a porta de sustentação encontrada na etapa anterior que volta ao mesmo switch (os pacotes de caminho estavam tomando durante o loop). Na topologia de exemplo anterior, esse caminho é AD-DB-BA.

   • Para cada switch no caminho redundante, verifique os seguintes problemas:

   1. O switch sabe a raiz STP correta?

      Todos os switches em uma rede L2 devem concordar com uma raiz STP comum. É um sintoma claro de problemas quando as bridges exibem consistentemente um ID diferente para a raiz do STP em uma determinada VLAN ou instância do STP. Emita o comando show spanning-tree vlan vlan-id para exibir o ID da bridge raiz de uma determinada VLAN:

      cat# show spanning-tree vlan 333
      
      MST03
        Spanning tree enabled protocol mstp
        Root ID    Priority    32771
                   Address     0050.14bb.6000
                   Cost        20000
                   Port        136 (GigabitEthernet3/8)
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
        Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)
                   Address     00d0.003f.8800
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
      Interface        Role Sts Cost      Prio.Nbr Status
      ---------------- ---- --- --------- -------- ------------------------
      Gi3/8            Root FWD 20000     128.136  P2p
      Po1              Desg FWD 20000     128.833  P2p

      O número da VLAN pode ser encontrado na porta, porque as portas envolvidas no loop foram estabelecidas em etapas anteriores. Se as portas em questão forem troncos, todas as VLANs do tronco estarão freqüentemente envolvidas. Se esse não for o caso (por exemplo, se parecer que o loop ocorreu em uma única VLAN), você pode tentar executar o comando show interfaces | incluir comando L2|line|broadcast (somente nos mecanismos Supervisor 2 e posteriores nos switches da série Catalyst 6500/6000, porque o Supervisor 1 não fornece estatísticas de switching por VLAN). Examine apenas as interfaces VLAN. A VLAN com a maior quantidade de pacotes comutados será mais frequentemente aquela em que o loop ocorreu:

      cat# show int | include L2|line|broadcast
      
      Vlan1 is up, line protocol is up
        L2 Switched: ucast: 653704527 pkt, 124614363025 bytes - mcast:
               23036247 pkt, 1748707536 bytes
           Received 23201637 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan10 is up, line protocol is up
        L2 Switched: ucast: 2510912 pkt, 137067402 bytes - mcast:
               41608705 pkt, 1931758378 bytes
           Received 1321246 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan11 is up, line protocol is up
        L2 Switched: ucast: 73125 pkt, 2242976 bytes - mcast:
               3191097 pkt, 173652249 bytes
           Received 1440503 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan100 is up, line protocol is up
        L2 Switched: ucast: 458110 pkt, 21858256 bytes - mcast:
               64534391 pkt, 2977052824 bytes
           Received 1176671 broadcasts, 0 runts, 0 giants, 0 throttles
      Vlan101 is up, line protocol is up
        L2 Switched: ucast: 70649 pkt, 2124024 bytes - mcast:
               2175964 pkt, 108413700 bytes
           Received 1104890 broadcasts, 0 runts, 0 giants, 0 throttles

      Neste exemplo, a VLAN 1 representa o maior número de broadcasts e o tráfego comutado L2.

   2. A porta de raiz foi identificada corretamente?

      A porta de raiz deverá ter o custo mais baixo do bridge raiz (algumas vezes um caminho é menor em termos de saltos, porém maior em termos de custo, porque as portas de baixa velocidade têm custos mais elevados).

      Para determinar qual porta é considerada a raiz de uma determinada VLAN, emita o comando show spanning-tree vlan vlan:

      cat# show spanning-tree vlan 333
      
      MST03
        Spanning tree enabled protocol mstp
        Root ID    Priority    32771
                   Address     0050.14bb.6000
                   Cost        20000
                   Port        136 (GigabitEthernet3/8)
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
        Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)
                   Address     00d0.003f.8800
                   Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
      
      Interface        Role Sts Cost      Prio.Nbr Status
      ---------------- ---- --- --------- -------- ------------------------
      Gi3/8            Root FWD 20000     128.136  P2p
      Po1              Desg FWD 20000     128.833  P2p

   3. As BPDUs são recebidas regularmente na porta raiz e em portas que devem estar bloqueando?

      As BPDUs são enviadas pela bridge raiz a cada intervalo hello (dois segundos por padrão). As bridges não raiz recebem, processam, modificam e propagam as BPDUs recebidas da raiz.

      Emita o comando show spanning-tree interface interface detail para ver se as BPDUs estão sendo recebidas:

      cat# show spanning-tree interface g3/2 detail
      
      Port 130 (GigabitEthernet3/2) of MST00 is backup blocking
         Port path cost 20000, Port priority 128, Port Identifier 128.130.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 4, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 3, received 53
      
      cat# show spanning-tree interface g3/2 detail
      
      Port 130 (GigabitEthernet3/2) of MST00 is backup blocking
         Port path cost 20000, Port priority 128, Port Identifier 128.130.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 5, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 3, received 54
      

      Observação: uma BPDU foi recebida entre as duas saídas do comando (o contador passou de 53 para 54).

      Os contadores mostrados, na verdade, são contadores mantidos pelo próprio processo STP. Isso significa que, se os contadores de recebimento incrementaram, não só a BPDU foi recebida por uma porta física, como também foi recebida pelo processo STP.

      Se o contador de BPDU recebido não estiver incrementando na porta que deve ser a raiz alternativa ou a porta de backup, verifique se a porta está recebendo multicasts (as BPDUs são enviadas como multicast). Emita o comando show interface interface counters:

      cat# show interface g3/2 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/2           14873036             2         89387             0
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/2          114365997         83776        732086            19
      
      cat# show interface g3/2 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/2           14873677             2         89391             0
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/2          114366106         83776        732087            19

      (Uma breve descrição das funções de porta STP pode ser encontrada na seção Resumo resumido das funções de porta STP de Aprimoramentos do Spanning Tree Protocol usando os Recursos de Detecção de Desvio de Loop Guard e BPDU.)

      Se nenhum BPDU for recebido, verifique se a porta não está contando erros. Emita o comando show interface interface interface counters errors:

      cat# show interface g4/3 counters errors
      
      Port     Align-Err    FCS-Err   Xmit-Err    Rcv-Err UnderSize OutDiscards
      Gi4/3        0          0          0          0         0           0
      
      Port  Single-Col Multi-Col  Late-Col Excess-Col Carri-Sen   Runts    Giants
      Gi4/3       0         0         0          0         0        0         0

      É possível que os BPDUs sejam recebidos pela porta física, mas ainda não alcancem o processo STP. Se os comandos usados nos dois exemplos anteriores mostrarem que alguns multicasts são recebidos e que os erros não estão aumentando, verifique se os BPDUs estão sendo descartados no nível do processo STP. Emita o comando remote command switch test spanning-tree process-stats no Catalyst 6500:

      cat# remote command switch test spanning-tree process-stats
      
      ------------------TX STATS------------------
       transmission rate/sec     = 2
       paks transmitted          = 5011226
       paks transmitted (opt)    = 0
       opt chunk alloc failures  = 0
       max opt chunk allocated   = 0
      ------------------RX STATS------------------
       receive rate/sec          = 1
       paks received at stp isr  = 3947627
       paks queued at stp isr    = 3947627
       paks dropped at stp isr   = 0
       drop rate/sec             = 0
       paks dequeued at stp proc = 3947627
       paks waiting in queue     = 0
       queue depth               = 7(max) 12288(total)
      --------------PROCESSING STATS---------------
       queue wait time (in ms)   = 0(avg) 540(max)
       processing time (in ms)   = 0(avg) 4(max)
       proc switch count         = 100
       add vlan ports            = 20
       time since last clearing  = 2087269 sec

      O comando usado neste exemplo exibe estatísticas do processo STP. É importante verificar se os contadores de queda não estão aumentando e se os pacotes recebidos estão aumentando.

      Se os pacotes recebidos não estiverem aumentando, mas a porta física estiver recebendo multicasts, verifique se os pacotes estão sendo recebidos pela interface dentro da banda do switch (a interface da CPU). Emita o comando remoto switch show ibc | i rx_input comando no Catalyst 6500/6000:

      cat# remote command switch show ibc | i rx_input
      
      rx_inputs=5626468, rx_cumbytes=859971138
      
      cat# remote command switch show ibc | i rx_input
      
      rx_inputs=5626471, rx_cumbytes=859971539

      Este exemplo mostra que, entre as saídas, a porta in-band recebeu 23 pacotes.

      Observação: esses 23 pacotes não são apenas pacotes de BPDU; este é um contador global para todos os pacotes recebidos pela porta in-band.

      Se não houver indicação de que as BPDUs estão sendo descartadas no switch ou na porta local, você deve mover para o switch no outro lado do link e verificar se esse switch está enviando BPDUs.

   4. BPDUs são enviadas regularmente em portas não raiz designadas?

      Se, de acordo com a função da porta, a porta estiver enviando BPDUs—mas o vizinho não está recebendo-os—verifique se as BPDUs estão realmente sendo enviadas. Emita o comando show spanning-tree interface interface detail:

      cat# show spanning-tree interface g3/1 detail
      
      Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding
         Port path cost 20000, Port priority 128, Port Identifier 128.129.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 0, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 1774, received 1
      
      cat# show spanning-tree interface g3/1 detail
      
      Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding
         Port path cost 20000, Port priority 128, Port Identifier 128.129.
         Designated root has priority 0, address 0007.4f1c.e847
         Designated bridge has priority 32768, address 00d0.003f.8800
         Designated port id is 128.129, designated path cost 2000019
         Timers: message age 0, forward delay 0, hold 0
         Number of transitions to forwarding state: 0
         Link type is point-to-point by default, Internal
         Loop guard is enabled by default on the port
         BPDU: sent 1776, received 1

      Neste exemplo, dois BPDUs foram enviados entre as saídas.

      Observação: o processo STP mantém a BPDU: contador enviado. Isso significa que o contador indica que a BPDU foi enviada em direção à porta física, para ser eventualmente enviada. Verifique se os contadores de porta estão aumentando para pacotes multicast transmitidos. Emita o comando show interface interface counters. Isso pode ajudar a determinar se os BPDUs estão saindo ou não:

      cat# show interface g3/1 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/1          127985312         83776        812319            19
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/1          131825915          3442        872342           386
      
      cat# show interface g3/1 counters
      
      Port            InOctets   InUcastPkts   InMcastPkts   InBcastPkts
      Gi3/1          127985312         83776        812319            19
      
      Port           OutOctets  OutUcastPkts  OutMcastPkts  OutBcastPkts
      Gi3/1          131826447          3442        872346           386

      Com todas essas etapas, a ideia é encontrar o switch ou link onde as BPDUs não são recebidas, enviadas ou processadas.

      É possível, no entanto improvável, que o STP tenha calculado o estado correto para a porta, mas devido a um problema no plano de controle, ele não pôde definir esse estado no hardware de encaminhamento. Um loop pode ser criado se a suposta porta de bloqueio não for bloqueada no nível de hardware. Se você suspeitar de tal problema em sua rede, entre em contato com o Suporte Técnico da Cisco para obter assistência adicional.

5. Restaurar a redundância.

   Quando o dispositivo ou link que está causando o loop for encontrado, esse dispositivo deve ser isolado da rede ou devem ser tomadas ações para resolver o problema (como substituir a fibra ou GBIC). Os links redundantes, desconectados na Etapa 3, devem ser restaurados.

   É importante fazer o mínimo possível de manipulação para o dispositivo ou link que está causando o loop, pois muitas condições que levam a um loop podem ser muito transitórias, intermitentes e instáveis. Isso significa que, se a condição for removida durante ou após a solução de problemas, pode levar algum tempo até que tal condição ocorra novamente. É possível que a condição nunca mais ocorra. Todos os esforços devem ser feitos para preservar a condição, para que ela possa ser investigada mais detalhadamente pelo Suporte Técnico da Cisco. É importante coletar informações sobre a condição antes de redefinir os switches. Se uma condição for removida, é geralmente impossível determinar a causa raiz do loop. Encontrar o dispositivo ou link que dispara o loop é uma grande conquista, mas você precisa garantir que outra falha do mesmo tipo não cause o loop novamente. Para obter mais informações, consulte a seção Como proteger a rede contra loops de encaminhamento deste documento.

Troubleshooting de Alterações Excessivas de Topologia Causando Inundações

A função do mecanismo TC é corrigir as tabelas de encaminhamento L2 após a alteração da topologia de encaminhamento. Isso é necessário para evitar uma interrupção de conectividade porque, após um TC, alguns endereços MAC anteriormente acessíveis através de determinadas portas podem se tornar acessíveis através de diferentes portas. O TC reduz o tempo de envelhecimento da tabela de encaminhamento em todos os switches na VLAN onde ocorre o TC; assim, se o endereço não for reaprendido, ele envelhecerá e ocorrerá inundação para garantir que os pacotes cheguem ao endereço MAC de destino.

O TC é acionado pela alteração do estado STP de uma porta para ou do estado de encaminhamento STP. Depois do TC, mesmo que o endereço MAC de destino específico tenha expirado, a inundação não deve continuar por muito tempo. O endereço será reaprendido pelo primeiro pacote que vem do host cujo endereço MAC foi eliminado. O problema pode surgir quando os TCs estão ocorrendo repetidamente, com intervalos curtos. Os switches sempre envelhecerão suas tabelas de encaminhamento, portanto a inundação será quase constante.

Observação: com STP rápido ou STP múltiplo (IEEE 802.1w e IEEE 802.1s), o TC é acionado por uma alteração do estado da porta para o encaminhamento, bem como pela alteração de função de designado para raiz. Com o Rapid STP, a tabela de encaminhamento L2 é imediatamente descarregada, ao contrário do 802.1d, que reduz o tempo de envelhecimento. A descarga imediata da tabela de encaminhamento restaura a conectividade mais rapidamente, mas provoca mais inundação.

O TC deve ser um evento raro em uma rede bem configurada. Quando um link em uma porta do switch é ativado ou desativado, há eventualmente um TC, quando o estado STP da porta é alterado para ou de encaminhamento. Quando uma porta não está sincronizada, o resultado pode ser inundação e TCs repetitivos.

As portas com o recurso portfast STP habilitado não causarão TCs ao entrarem ou saírem do estado de encaminhamento. A configuração de portfast em todas as portas de dispositivos finais (como impressoras, computadores e servidores) deve limitar os TCs para um valor inferior e isso é altamente recomendado. Para obter mais informações sobre TCs, consulte Entendendo as alterações de topologia do protocolo Spanning-Tree.

Se houver TCs repetitivos na rede, você deve identificar a origem desses TCs e tomar medidas para reduzi-los, para reduzir a inundação ao mínimo.

Com 802.1d, as informações de STP sobre um evento de TC são propagadas entre as ligações através de uma notificação de TC (TCN), que é um tipo especial de BPDU. Se você seguir as portas que estão recebendo BPDUs TCN, poderá encontrar o dispositivo que está originando TCs.

Estabelecer se a Inundação é Causada pelos TCs do STP.

Normalmente, você pode determinar que há inundação de desempenho lento, quedas de pacotes em links que não devem estar congestionados e o analisador de pacotes mostrando vários pacotes unicast para o mesmo destino que não está no segmento local.

Para obter mais informações sobre inundação unicast, consulte Inundação Unicast em Redes de Campus Comutadas.

Em um Catalyst 6500/6000 que executa o software Cisco IOS, você pode verificar o contador do mecanismo de encaminhamento (somente no mecanismo Supervisor 2) para estimar a quantidade de inundação. Emita o comando remoto switch show earl statistics | i MISS_DA|ST_FR comando:

cat# remote command switch show earl statistics | i MISS_DA|ST_FR

         ST_MISS_DA     =       18                      530308834
         ST_FRMS        =       97                      969084354

cat# remote command switch show earl statistics | i MISS_DA|ST_FR

         ST_MISS_DA     =       4                       530308838
         ST_FRMS        =       23                      969084377

Neste exemplo, a primeira coluna mostra a alteração desde a última vez que este comando foi executado, e a segunda coluna mostra o valor cumulativo desde a última reinicialização. A primeira linha mostra a quantidade de quadros inundados e a segunda linha mostra a quantidade de quadros processados. Se os dois valores estiverem próximos, ou se o primeiro valor estiver aumentando em uma taxa alta, pode ser que o switch esteja inundando o tráfego. No entanto, isso só pode ser usado em conjunto com outras formas de verificar a inundação, pois os contadores não são granulares. Há um contador por switch, não por porta ou VLAN. É normal ver alguns pacotes de inundação, pois o switch sempre inundará se o endereço MAC de destino não estiver na tabela de encaminhamento. Isso ocorrerá quando o switch receber um pacote com um endereço de destino que ainda não foi aprendido.

Rastrear a origem dos TCs

Se o número da VLAN for conhecido pela VLAN onde está ocorrendo inundação excessiva, verifique os contadores STP para ver se o número de TCs é alto ou se está aumentando regularmente. Emita o comando show spanning-tree vlan vlan-id detail (neste exemplo, a VLAN 1 é usada):

cat# show spanning-tree vlan 1 detail

VLAN0001 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, sysid 1, address 0007.0e8f.04c0
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 0, address 0007.4f1c.e847
  Root port is 65 (GigabitEthernet2/1), cost of root path is 119
  Topology change flag not set, detected flag not set
  Number of topology changes 1 last change occurred 00:00:35 ago
          from GigabitEthernet1/1
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

Se o número da VLAN não for conhecido, use o analisador de pacotes ou verifique os contadores TC para todas as VLANs.

Etapas para prevenir o excesso de TCs

Você pode monitorar o número de contadores de alterações de topologia para ver se ele está aumentando regularmente. Em seguida, mova-se para a bridge conectada à porta mostrada, para receber o último TC (no exemplo anterior, a porta GigabitEthernet1/1) e veja de onde o TC veio para aquela bridge. Esse processo deve ser repetido até que a porta da estação final sem o portfast STP habilitado seja encontrada ou até que o link não sincronizado seja encontrado e precise ser corrigido. O procedimento inteiro precisará ser repetido se os TCs ainda estiverem vindo de outras origens. Se o link pertencer a um host final, você deve configurar o recurso portfast para impedir a geração de TCs.

Observação: na implementação STP do software Cisco IOS, o contador para TCs só aumentará se um TCN BPDU for recebido por uma porta em uma VLAN. Se uma BPDU de configuração normal com um flag TC definido for recebida, o contador TC não será incrementado. Isso significa que, se você suspeitar que um TC seja o motivo da inundação, é melhor começar a rastrear as fontes do TC a partir da bridge raiz do STP nessa VLAN. Terá as informações mais precisas sobre a quantidade e a origem dos TC.

Troubleshooting de Problemas Relacionados ao Tempo de Convergência

Existem situações em que a operação real do STP não coincide com o comportamento esperado. Estes são os dois problemas mais frequentes:

• A convergência ou reconvergência do STP demora mais do que o esperado.

• A topologia resultante é diferente do esperado.

Na maioria das vezes, estes são os motivos para esse comportamento:

• Uma incompatibilidade entre a topologia real e a documentada.

• Configuração incorreta, como uma configuração inconsistente de temporizadores STP, diâmetro de STP superior ou configuração incorreta de portfast

• CPU do switch sobrecarregado durante convergência ou reconvergência

• Defeito de software

Como mencionado anteriormente, este documento só pode fornecer diretrizes gerais para a solução de problemas, devido à grande variedade de problemas que podem afetar o STP.

Para entender por que a convergência leva mais tempo do que o esperado, examine a sequência de eventos do STP para descobrir o que estava acontecendo e em que ordem. Como a implementação STP no software Cisco IOS não tem registro especial (exceto eventos específicos, como inconsistências de porta), você pode usar os recursos de depuração STP do software Cisco IOS para entender o que está acontecendo.

Para o STP, com um Catalyst 6500/6000 que executa o software Cisco IOS, o processamento é feito no Switch Processor (SP) (ou Supervisor), de modo que as depurações precisam ser ativadas no SP. Para grupos de bridge do software Cisco IOS, o processamento é feito no Route Processor (RP), portanto, as depurações precisam ser ativadas no RP (MSFC).

Comandos de depuração de STP

Muitos comandos de depuração STP são destinados ao uso da engenharia de desenvolvimento. Eles não fornecem nenhuma saída significativa para alguém sem conhecimento detalhado da implementação do STP no software Cisco IOS. Algumas depurações podem fornecer uma saída que pode ser lida instantaneamente, como alterações de estado de porta, alterações de função, eventos como TCs e um dump de BPDUs recebidos e transmitidos. Esta seção não fornece uma descrição completa de todas as depurações, mas apresenta brevemente as mais usadas.

Observação: ao usar comandos debug, habilite o mínimo necessário de depurações. Se as depurações em tempo real não forem necessárias, registre a saída para o registro em vez de imprimi-la para o console. Depurações excessivas podem sobrecarregar a CPU e interromper a operação do switch. Para direcionar a saída de depuração para o log em vez de para o console ou para sessões Telnet, emita os comandos logging console informational e no logging monitor no modo de configuração global.

Para ver o registro de eventos geral, emita o comando debug spanning-tree event para Per VLAN Spanning-Tree (PVST) e Rapid-PVST. Essa é a primeira depuração que dá uma ideia geral do que está acontecendo com o STP.

No modo MST (Multiple Spanning-Tree), ele não funciona para emitir o comando debug spanning-tree event. Portanto, emita o comando debug spanning-tree mstp role para ver as alterações na função da porta.

Para ver as alterações de estado do STP da porta, emita o comando debug spanning-tree switch state junto com o comando debug pm vp:

cat-sp# debug spanning-tree switch state

Spanning Tree Port state changes debugging is on

cat-sp# debug pm vp

Virtual port events debugging is on
Nov 19 14:03:37: SP:     pm_vp 3/1(333): during state forwarding, got event 4(remove)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333):
  forwarding -> notforwarding

port 3/1 (was forwarding) goes down in vlan 333

Nov 19 14:03:37: SP: *** vp_fwdchange: single: notfwd: 3/1(333)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): notforwarding -> present
Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/1(333)
Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): present -> not_present
Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/1(333)
Nov 19 14:03:37: SP:     pm_vp 3/2(333): during state notforwarding,
  got event 4(remove)
Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): notforwarding -> present
Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/2(333)

Port 3/2 (was not forwarding) in vlan 333 goes down

Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): present -> not_present
Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/2(333)

Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state not_present,
  got event 0(add)
Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): not_present -> present
Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/1(333)
Nov 19 14:03:53: SP:     pm_vp 3/1(333): during state present,
  got event 8(linkup)
Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): present ->
  notforwarding
Nov 19 14:03:53: SP: STP SW: Gi3/1 new blocking req for 0 vlans
Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/1(333)

Port 3/1 link goes up and blocking in vlan 333

Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state not_present,
  got event 0(add)
Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): not_present -> present
Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/2(333)
Nov 19 14:03:53: SP:     pm_vp 3/2(333): during state present,
  got event 8(linkup)
Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): present ->
  notforwarding
Nov 19 14:03:53: SP: STP SW: Gi3/2 new blocking req for 0 vlans
Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/2(333)

Port 3/2 goes up and blocking in vlan 333

Nov 19 14:04:08: SP: STP SW: Gi3/1 new learning req for 1 vlans
Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 0 vlans
Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 1 vlans
Nov 19 14:04:23: SP:     pm_vp 3/1(333): during state notforwarding,
  got event 14(forward_notnotify)
Nov 19 14:04:23: SP: @@@ pm_vp 3/1(333): notforwarding ->
  forwarding
Nov 19 14:04:23: SP: *** vp_list_fwdchange: forward: 3/1(333)

Port 3/1 goes via learning to forwarding in vlan 333

Para entender por que o STP se comporta de uma certa maneira, é frequentemente útil ver as BPDUs que são recebidas e enviadas pelo switch:

cat-sp# debug spanning-tree bpdu receive

Spanning Tree BPDU Received debugging is on
Nov  6 11:44:27: SP: STP: VLAN1 rx BPDU: config protocol = ieee,
  packet from GigabitEthernet2/1  , linktype IEEE_SPANNING ,
  enctype 2, encsize 17
Nov  6 11:44:27: SP: STP: enc 01 80 C2 00 00 00 00 06 52 5F 0E 50 00 26 42 42 03
Nov  6 11:44:27: SP: STP: Data 0000000000000000074F1CE8470000001380480006525F0E4
  080100100140002000F00
Nov  6 11:44:27: SP: STP: VLAN1 Gi2/1:0000 00 00 00 000000074F1CE847 00000013
  80480006525F0E40 8010 0100 1400 0200 0F00

Essa depuração funciona para os modos PVST, Rapid-PVST e MST; mas não decodifica o conteúdo das BPDUs. Entretanto, você pode usá-lo para garantir que os BPDUs sejam recebidos.

Para observar o conteúdo da BPDU, emita o comando debug spanning-tree switch rx decode junto com o debug spanning-tree switch rx process para PVST e Rapid-PVST. Emita o comando debug spanning-tree mstp bpdu-rx para visualizar o conteúdo do BPDU para MST:

cat-sp# debug spanning-tree switch rx decode

Spanning Tree Switch Shim decode received packets debugging is on

cat-sp# debug spanning-tree switch rx process

Spanning Tree Switch Shim process receive bpdu debugging is on

Nov  6 12:23:20: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026
Nov  6 12:23:20: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1
Nov  6 12:23:20: SP:     42 42 03 SPAN
Nov  6 12:23:20: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013
Nov  6 12:23:20: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

Nov  6 12:23:22: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026
Nov  6 12:23:22: SP:     encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1
Nov  6 12:23:22: SP:     42 42 03 SPAN
Nov  6 12:23:22: SP:     CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013
Nov  6 12:23:22: SP:     B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00

Para o modo MST, você pode habilitar o decodificador de BPDU detalhado com este comando debug:

cat-sp# debug spanning-tree mstp bpdu-rx

Multiple Spanning Tree Received BPDUs debugging is on
Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]
Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]
Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019
Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0
Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768
Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15
Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1
Nov 19 14:37:43: SP: MST:   ist_m_id :0005.74
Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated]
Nov 19 14:37:43: SP: MST:   Proto:0 Version:3 Type:2 Role: DesgFlags[   F    ]
Nov 19 14:37:43: SP: MST:   Port_id:32897 cost:2000019
Nov 19 14:37:43: SP: MST:   root_id  :0007.4f1c.e847 Prio:0
Nov 19 14:37:43: SP: MST:   br_id    :00d0.003f.8800 Prio:32768
Nov 19 14:37:43: SP: MST:   age:2 max_age:20 hello:2 fwdelay:15
Nov 19 14:37:43: SP: MST:   V3_len:90 PathCost:30000 region:STATIC rev:1
Nov 19 14:37:43: SP: MST:   ist_m_id :0005.7428.1440 Prio:32768  Hops:18
  Num Mrec: 1
Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]
Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897
  Cost:2000028.1440 Prio:32768  Hops:18  Num Mrec: 1
Nov 19 14:37:43: SP: MST: stci=3  Flags[ F    ] Hop:19 Role:Desg [Repeated]
Nov 19 14:37:43: SP: MST:         br_id:00d0.003f.8800 Prio:32771 Port_id:32897
  Cost:20000

Observação: para o Cisco IOS Software Release 12.1.13E ou posterior, as depurações condicionais para STP são suportadas. Isso significa que você pode depurar BPDUs que são recebidos ou transmitidos por porta ou por VLAN.

Emita os comandos debug condition vlan vlan_num ou debug condition interface interface, para limitar o escopo da saída debug para cada interface ou por VLAN.

Protegendo a rede contra loops de encaminhamento

Para lidar com a incapacidade do STP em lidar corretamente com certas falhas, a Cisco desenvolveu vários recursos e aprimoramentos para proteger as redes contra loops de encaminhamento.

A solução de problemas do STP ajuda a isolar e possivelmente encontrar a causa de uma falha específica, enquanto a implementação dessas melhorias é a única maneira de proteger a rede contra loops de encaminhamento.

Estes são métodos para proteger sua rede contra loops de encaminhamento:

1. Ative a detecção de link unidirecional (UDLD) em todos os links de switch para switch. Para obter mais informações sobre o UDLD, consulte Compreendendo e Configurando o Recurso Unidirectional Link Detection Protocol.

2. Ative o protetor de loop em todos os switches. Para obter mais informações sobre o Loop Guard, consulte Melhorias do Spanning-Tree Protocol usando o Loop Guard e os Recursos de Detecção de Desvio de BPDU.

   Quando ativados, o UDLD e o Loop Guard eliminam a maioria das causas possíveis para loops de encaminhamento. Em vez de criar um loop de encaminhamento, o link ofensivo (ou todos os links dependentes do hardware com falha) é desligado ou bloqueado.

   Observação: embora esses dois recursos pareçam um pouco redundantes, cada um tem seus recursos exclusivos. Portanto, use ambos os recursos ao mesmo tempo para fornecer o mais alto nível de proteção. Para uma comparação detalhada de UDLD e Loop Guard, consulte Proteção de Loop vs. Detecção de Link Unidirecional.

   Há opiniões diferentes em relação ao uso de UDLD agressivo ou normal. Observe que uma UDLD agressiva não proporcionará uma proteção maior contra os loops quando comparada ao modo de UDLD normal. O UDLD agressivo detecta cenários de bloqueio de porta (quando o enlace está ativo, mas não há buracos de tráfego associados). A desvantagem dessa funcionalidade adicional é que a UDLD agressiva pode potencialmente desativar enlaces quando nenhuma falha consistente estiver presente. Frequentemente, as pessoas confundem a modificação do intervalo de hello UDLD com o recurso UDLD agressivo. Isto está incorreto. Os cronômetros podem ser modificados nos dois modos UDLD.

   Observação: em casos raros, o UDLD agressivo pode desligar todas as portas de uplink, que basicamente isola o switch do resto da rede. Por exemplo, isso pode acontecer quando ambos os switches upstream estão tendo uma utilização de CPU muito alta e quando o UDLD do modo agressivo é usado. Portanto, é recomendável configurar errordisable-timeouts, se o switch não tiver gerenciamento fora de banda em vigor.

3. Ative o portfast em todas as portas da estação final.

   Você deve habilitar o portfast para limitar a quantidade de TCs e as subsequentes inundações, o que pode afetar o desempenho da rede. Use somente esse comando com portas que se conectam às estações finais. Caso contrário, um loop acidental de topologia pode causar um loop de pacote de dados e interromper a operação do switch e da rede.

   Cuidado: tenha cuidado ao usar o comando no spanning-tree portfast. Esse comando remove apenas qualquer comando portfast específico da porta. Este comando implicitamente ativa o portfast se você definir o comando spanning-tree portfast default no modo de configuração global e se a porta não for uma porta de tronco. Se você não configurar o portfast globalmente, o comando no spanning-tree portfast é equivalente ao comando spanning-tree portfast disable.

4. Defina EtherChannels para o modo desejável em ambos os lados (onde suportado) e a opção não silenciosa.

   O modo desejável ativará o protocolo de agregação de porta (PAgP) para assegurar a consistência do tempo de corrida entre peers de canais. Isso oferece um grau adicional de proteção contra loops, especialmente durante as reconfigurações do canal (como quando os links entram ou saem do canal e a detecção de falha de link). Há um Channel Misconfiguration Guard integrado, que é ativado por padrão e impede loops de encaminhamento devido a configuração incorreta do canal ou outras condições. Para obter mais informações sobre esse recurso, consulte Understanding EtherChannel Inconsistency Detection.

5. Não desative a negociação automática (se suportada) em links de switch para switch.

   Os mecanismos de negociação automática podem transmitir informações de falha remota, que é a maneira mais rápida de detectar falha no lado remoto. Se uma falha for detectada no lado remoto, o lado local desativará o link mesmo se o link ainda estiver recebendo pulsos. Comparada aos mecanismos de detecção de alto nível, como o UDLD, a autonegociação é muito rápida (em microssegundos), mas não tem a cobertura de ponta a ponta do UDLD (como todo o datapath: CPU—lógica de encaminhamento—porta1—porta2—lógica de encaminhamento—CPU versus porta1—porta2). O modo UDLD agressivo fornece uma funcionalidade semelhante à da autonegociação em relação à detecção de falhas. Quando a negociação é suportada nos dois lados do enlace, não há necessidade de habilitar o UDLD do modo agressivo.

6. Tenha cuidado ao ajustar os temporizadores STP.

   Os temporizadores STP dependem uns dos outros e da topologia de rede. O STP pode não funcionar corretamente com modificações arbitrárias feitas nos cronômetros. Para obter mais informações sobre temporizadores STP, consulte Entendendo e ajustando temporizadores do Spanning Tree Protocol.

7. Se houver a possibilidade de ocorrerem ataques de recusa de serviço, proteja o perímetro de STP da rede com o Protetor de Raiz.

   O Protetor de Raiz e o Protetor de BPDU permitem que você proteja o STP contra influências externas. Se tal ataque for possível, o Root Guard e o BPDU Guard devem ser usados para proteger a rede. Para obter mais informações sobre o Root Guard e o BPDU Guard, consulte estes documentos:

   • Melhoria de protetor de raiz do protocolo de árvore de abrangência

   • Aprimoramento do Protetor de BPDU do Portfast de Árvore Estendida

8. Ative o BPDU Guard em portas habilitadas para portfast para impedir que o STP seja afetado por dispositivos de rede não autorizados (como hubs, switches e roteadores de bridging) conectados às portas.

   Se o Protetor de Raiz estiver configurado corretamente, ele já impedirá que o STP seja influenciado do exterior. Se o BPDU Guard estiver ativado, ele desativará as portas que estão recebendo qualquer BPDU (não apenas BPDUs superiores). Isso pode ser útil se tais incidentes precisarem ser investigados, pois o BPDU Guard produz a mensagem de syslog e desliga a porta. Deve-se observar que os loops de vida curta não são impedidos pelas Proteções de Raiz ou BPDU, se duas portas habilitadas para portfast estiverem conectadas diretamente ou através do hub.

9. Evite o tráfego do usuário na VLAN de gerenciamento. O gerenciamento da VLAN está incluído em um bloco de construção, e não na rede inteira.

   A interface de gerenciamento do switch recebe pacotes de broadcast na VLAN de gerenciamento. Se ocorrerem broadcasts excessivos (como uma tempestade de broadcast ou um aplicativo com mau funcionamento), a CPU do switch pode ficar sobrecarregada, o que pode possivelmente distorcer a operação do STP.

10. Um posicionamento raiz STP previsível (codificado) e raiz STP de backup.

    A raiz STP e a raiz STP de backup devem ser configuradas para que a convergência, no caso de falhas, ocorra de forma previsível e crie uma topologia ideal em cada cenário. Não deixe a prioridade STP no valor padrão, para evitar a seleção imprevisível do switch raiz.

Informações Relacionadas

• Suporte a Produtos de LAN
• Suporte de tecnologia de switching de LAN
• Suporte Técnico e Documentação - Cisco Systems