Configurar o recurso de protocolo UDLD

Introdução

Este documento descreve como o protocolo Unidirectional Link Detection (UDLD) pode ajudar a evitar loops e anomalias de tráfego em redes comutadas.

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) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Conventions

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

Definição do problema

O Spanning-Tree Protocol (STP) resolve a topologia física redundante em uma topologia de encaminhamento de árvore sem loops.

Para fazer isso, ele bloqueia uma ou mais portas. Com uma ou mais portas bloqueadas, não há loops na topologia de encaminhamento. A operação do STP depende de recepção e transmissão de BPDUs (Unidades de Dados de Protocolo de Ponte). Se o processo de STP que é executado no switch com uma porta no estado blocking não receber BPDUs de seu switch upstream (designado), o STP eventualmente envelhece as informações de STP para a porta e as move para o estado forwarding .

Isso pode criar um loop STP no qual os pacotes começam a circular indefinidamente ao longo do caminho em loop e consomem cada vez mais largura de banda e recursos. Isso leva a uma possível interrupção da rede.

Como é possível que o switch não receba BPDUs enquanto a porta estiver ativa? O motivo é um link unidirecional.

Um link é considerado unidirecional quando:

• O enlace está ativado em ambos os lados da conexão.

• O lado local não recebe os pacotes enviados pelo lado remoto, enquanto o lado remoto recebe pacotes enviados pelo lado local.

Considere este cenário. As setas indicam o fluxo de STP BPDUs.

Durante a operação normal, a ponte B é uma porta designada no link B-C. A Ponte B envia BPDUs para C, que é o bloqueio da porta. A porta é bloqueada enquanto C vê BPDUs de B naquele lnk.

Agora, considere o que acontece se o link B-C falhar na direção de C. C deixa de receber tráfego de B, no entanto, B ainda recebe tráfego de C.

up

C não recebe BPDUs no link B-C e expira as informações recebidas com o último BPDU. Isso leva até 20 segundos, o que depende do temporizador de STP maxAge. Uma vez que as informações de STP são expiradas na porta, essa porta transiciona do estado de bloqueio para o estado listening, learning e, eventualmente, para estado forwarding do STP. Isso cria um loop, pois não há porta bloqueada no triângulo A-B-C. Os pacotes circulam ao longo do caminho (B ainda recebe pacotes de C), que consome largura de banda adicional até que os links sejam completamente preenchidos.

Esse cenário pode desativar a rede. Outro possível problema que pode ser causado por um link unidirecional é um buraco negro de tráfego.

Como funciona o protocolo de deteção de enlace unidirecional

O UDLD é um protocolo Camada 2 (L2) que funciona com os mecanismos de Camada 1 (L1) para determinar o status físico de um link. Na Camada 1, a autonegociação toma conta da sinalização física e da detecção de falhas. O UDLD executa tarefas que a autonegociação não pode executar, como a detecção das identidades de vizinhos e o encerramento de portas desconectadas. Quando você habilita a autonegociação e o UDLD, as detecções da Camada 1 e da Camada 2 trabalham junto para impedir conexões unidirecionais físicas e lógicas e o funcionamento incorreto de outros protocolos.

O UDLD funciona através da troca de pacotes de protocolo entre os dispositivos vizinhos. Para que o UDLD funcione, ambos os dispositivos no link devem suportar o UDLD e tê-lo habilitado nas respectivas portas.

Cada porta de switch configurada para UDLD envia pacotes de protocolo UDLD que contêm o dispositivo de porta/ID de porta e os IDs de dispositivo/porta vizinhos vistos pelo UDLD nessa porta. As portas vizinhas veem seu próprio ID de dispositivo/porta (eco) nos pacotes recebidos do outro lado. Se a porta não vê sua própria ID de dispositivo/porta nos pacotes UDLD recebidos por um período de tempo específico, o link é considerado unidirecional.

Este algoritmo de eco permite a detecção destes problemas:

• O link está ativo nos dois lados, mas os pacotes são recebidos apenas por um lado.

• Erros de conexão (fio) quando as fibras de recepção e transmissão não estão conectadas à mesma porta no lado remoto.

Uma vez que o link unidirecional é detectado pelo UDLD, a respectiva porta é desabilitada e esta mensagem é mostrada no console:

UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled

O desligamento da porta pelo UDLD permanece desabilitado até que seja habilitado manualmente ou até que o timeout de desabilitação de porta expire (se configurado).

Modos de operação de UDLD

O UDLD pode operar em dois modos: normal e assertivo: .

• No modo normal, se o estado do link da porta foi identificado como bidirecional e houver timeout das informações de UDKD, nenhuma ação é tomada pelo UDLD. O estado da porta para o UDLD é marcado como indeterminado. A porta se comporta de acordo com seu estado STP.
• No modo agressivo, se o estado do link da porta for identificado como bidirecional e houver timeout das informação de UDLD enquanto o link na porta ainda estiver ativo, o UDLD tentará restabelecer o estado da porta. Se não houver êxito, a porta é colocada no estado errdisable.

As informações de tempo de inatividade do UDLD ocorrem quando a porta que executa o UDLD não recebe pacotes UDLD da porta vizinha durante o tempo de espera. O tempo de espera da porta é determinado pela porta remota e depende do intervalo de mensagem no lado remoto. Quanto menor o intervalo da mensagem, menor o tempo de espera e mais rápida a detecção. As implementações recentes de UDLD permitem a configuração de intervalo de mensagem. Informações sobre UDLD podem expirar devido à alta taxa de erros na porta, causada por algum problema físico ou incompatibilidade de duplex. Tal queda de pacote não significa que o link é unidirecional e o UDLD no modo normal não desativa tal link.

É importante poder selecionar o intervalo da mensagem correta para garantir o tempo de detecção adequado. O intervalo de mensagem precisa ser rápido o suficiente para detectar o link unidirecional antes que o loop de encaminhamento seja criado; no entanto, ele não deve sobrecarregar a CPU do switch. O intervalo de mensagens padrão é de 15 segundos e é rápido o suficiente para detectar o link unidirecional antes que o loop de encaminhamento seja criado com os temporizadores STP padrão. O tempo de detecção é aproximadamente igual a três vezes o intervalo das mensagens.

Por exemplo: _Tdetection~ message_interval x3

Este é 45 segundos para o intervalo de mensagens padrão de 15 segundos.

É necessário _{Treconvergence}=max_age + 2x forward_delay para o STP reconvergir em caso de falha de link unidirecional. Com os temporizadores padrão, o tempo necessário é 20+2x15=50 segundos.

Recomenda-se manter _Tdetection< _{Treconvergence} e escolher _{um intervalo de mensagem apropriado.}

No modo agressivo, uma vez que as informações são envelhecidas, o UDLD faz uma tentativa de restabelecer o estado do link e enviar pacotes a cada segundo durante oito segundos. Se o estado do link anda não for determinado, ele é desabilitado.

O modo agressivo adiciona detecção adicional destas situações:

• A porta está presa (em um lado a porta não transmite nem recebe. No entanto, o link está ativo em ambos os lados).

• O link está ativo em um dos lados e inativo, no outro lado. Esse problema pode ser observado nas portas de fibra quando a fibra de transmissão está desconectada na porta local, o link permanece ativo no lado local. No entanto, ele está inativo< /tt>no lado remoto.

Mais recentemente, as implementações de hardware dos FastEthernet de fibra possuem funções do Far End Fault Indication (FEFI) para desativar o link ambos os lados nessas situações. Em GigabitEthernet, uma função semelhante é fornecida pela negociação de link. Em geral, portas de cobre não são suscetíveis a esse tipo de problema, pois usam pulsos de links de Ethernet para monitorar o link. É importante mencionar que, em ambos os casos, nenhum loop de encaminhamento ocorre porque não há conectividade entre as portas. No entanto, se o link estiver ativo em um lado e inativo no outro, poderá ocorrer um blecaute de tráfego. UDLD agressivo for designado para impedir isso.

Disponibilidade

O UDLD está disponível no modo normal e agressivo no Cisco IOS® Software Release 12 e posterior.

Configuração e monitoramento

Execute o comando show udld para verificar se o UDLD está habilitado nas interfaces:

Switch#show udld

Interface Gi1/0/1
---
Port enable administrative configuration setting: Disabled
Port enable operational state: Disabled
Current bidirectional state: Unknown

Interface Gi1/0/2
---
Port enable administrative configuration setting: Disabled
Port enable operational state: Disabled
Current bidirectional state: Unknown

Interface Gi1/0/3
---
Port enable administrative configuration setting: Disabled
Port enable operational state: Disabled
Current bidirectional state: Unknown

O UDLD agressivo pode ser configurado na interface com o  udld port aggressive comando:

Switch#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#interface gigabitEthernet1/0/1
Switch(config-if)#udld port aggressive 
Switch(config-if)#end
Switch#

Execute oshow udld  e show udld neighbors para verificar se o UDLD está habilitado ou desabilitado na porta e qual é o estado do link e do vizinho:

Switch#show udld GigabitEthernet1/0/1

Interface Gi1/0/1
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15000 ms
Time out interval: 5000 ms

Port fast-hello configuration setting: Disabled
Port fast-hello interval: 0 ms
Port fast-hello operational state: Disabled
Neighbor fast-hello configuration setting: Disabled
Neighbor fast-hello interval: Unknown


Entry 1
---
Expiration time: 31600 ms
Cache Device index: 1
Current neighbor state: Bidirectional
Device ID: 346288238580 
Port ID: Gi4/0/1 
Neighbor echo 1 device: 70B4F35F080
Neighbor echo 1 port: Gi1/0/1

TLV Message interval: 15 sec
No TLV fast-hello interval
TLV Time out interval: 5
TLV CDP Device name: MXC.TAC.M.02-3850-01

Switch#show udld neighbors 
Port      Device Name    Device ID   Port ID     Neighbor State
----      -----------    ---------   -------     --------------
Gi1/0/1   346288238580   1           Gi4/0/1     Bidirectional

Total number of bidirectional entries displayed: 1

Use o udld message time para alterar o intervalo de mensagens:

Switch(config)#udld message time 10
UDLD message interval set to 10 seconds

O intervalo pode variar de 1 a 90 segundos, com o padrão de 15 segundos.

Informações Relacionadas

• Suporte técnico e downloads da Cisco

• Para Catalyst 3560 Switches, consulte Configuração do UDLD.

• Para o Catalyst 4500/4000 que executa o Cisco IOS, consulte Configuração do UDLD.

• Para Catalyst 9300 Switches, consulte Como Configurar o UDLD
• Para Catalyst 9500 Switches, consulte Como Configurar o UDLD