Configurar o recurso do protocolo UDLD

Introdução

Este documento descreve como o protocolo Unidirecional 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 descreve a operação geral do UDLD. Os exemplos de configuração e verificação neste documento foram validados nos Cisco Catalyst 9300 Series Switches com Cisco IOS XE versão 17.X.

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 uma porta no estado de bloqueio ou descarte de STP parar de receber BPDUs da ponte designada, o STP eventualmente envelhecerá as informações associadas a essa porta e as moverá para um estado de encaminhamento.

Isso pode criar um loop STP no qual os pacotes começam a circular indefinidamente ao longo do caminho em loop e consomem 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? Isso ocorre devido a 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 pacotes enviados pelo lado remoto, enquanto o lado remoto recebe pacotes enviados pelo lado local.

Considere o próximo cenário, as setas indicam o fluxo de STP BPDUs:

---

Topologia de Estado da Porta STP

---

Durante a condição mostrada nessa topologia, a interface no switch B em direção ao switch C é a porta designada para o segmento B-C e transmite BPDUs em direção ao switch C. A interface no switch C em direção ao switch B é uma porta não designada no IEEE 802.1D STP clássico. Ou uma porta alternativa em RSTP e permanece no estado blocking/discarding enquanto recebe e processa BPDUs do switch B. Embora a interface no switch C esteja no estado blocking ou discarding, a porta continua a receber e processar BPDUs; esses estados impedem que a porta encaminhe quadros de dados, mas não a impedem de receber BPDUs.

---

Considere o que acontece se o link B-C se tornar unidirecional e a direção B → C falhar. O switch C não pode mais receber BPDUs do switch B, enquanto o switch B pode receber BPDUs transmitidos pelo switch C. O switch C retém as informações aprendidas do último BPDU até que essas informações expirem. Com o IEEE 802.1D STP clássico e o Max Age padrão de 20 segundos, isso pode levar até 20 segundos. Quando as informações de STP expirarem, o switch C não considerará mais o switch B superior nesse segmento e a porta poderá fazer a transição de Blocking para Listening, Learning e, finalmente, Forwarding.

---

Isso cria um loop de encaminhamento de Camada 2 porque não há mais uma porta bloqueada no triângulo A-B-C. Quadros de broadcast, unicast desconhecido e multicast podem circular repetidamente no loop, consumindo largura de banda, CPU e potencialmente resultando em uma tempestade de broadcast.

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

---

Fluxo de STP BPDU

---

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

O UDLD é um protocolo da Camada 2 que complementa os mecanismos de detecção de link da Camada 1, identificando comunicações unidirecionais e inconsistências de cabeamento específicas entre dispositivos diretamente conectados.

---

Na Camada 1, a autonegociação resolve a sinalização física e a detecção de falhas. O UDLD executa tarefas que a autonegociação não pode executar, como detectar identidades de vizinhos e desligar portas desconectadas. Ao habilitar a autonegociação e o UDLD; As detecções de Camada 1 e Camada 2 trabalham em conjunto para evitar conexões unidirecionais físicas e lógicas e o mau funcionamento de outros protocolos.

O UDLD funciona através da troca de pacotes de protocolo entre os dispositivos vizinhos. Para estabelecer uma relação de vizinhança UDLD bidirecional, ambos os dispositivos conectados diretamente devem suportar o UDLD e tê-lo habilitado nas interfaces conectadas. Verifique o estado bidirecional em ambos os dispositivos.

---

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.

---

Quando o UDLD detecta uma condição unidirecional, ele coloca a interface local de detecção no estado err-disable. O estado da interface remota depende da detecção do UDLD remoto e do comportamento do link físico. Uma mensagem semelhante é impressa no console:

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

---

Uma interface desabilitada pelo UDLD permanece no estado err-disable até que seja recuperada manualmente ou um temporizador de recuperação errdisable habilitado expire. Corrija a falha de fibra, transceptor, cabeamento ou interface remota antes da recuperação. Use shutdown e no shutdown para recuperação manual. Nas plataformas que suportam isso, a redefinição de udld redefine as interfaces desabilitadas/desligadas pelo UDLD. Após a recuperação, execute os comandos show interfaces status err-disabled, show udld <interface-id> e show udld neighbors para confirmar se a interface está operacional e se a relação UDLD é bidirecional. Examine os logs do sistema para confirmar se a falha não se repete.

---

Modos de operação de UDLD

O UDLD pode operar em dois modos: normal e agressivo:

---

Modo normal

Quando o UDLD é habilitado em uma interface suportada, o modo normal é o modo operacional padrão, a menos que o modo agressivo seja explicitamente configurado. O UDLD funciona com mecanismos de Camada 1, como autonegociação, para validar um link. Os mecanismos de Camada 1 detectam a sinalização física e falhas de link, enquanto o UDLD identifica dispositivos vizinhos e verifica os fios de fibra que se conectam às portas corretas.

No modo normal, o UDLD detecta uma condição unidirecional quando os fios de fibra estão desconectados entre portas e os mecanismos de Camada 1 não detectam o erro de cabeamento. Se os fios de fibra se conectam às portas corretas, mas o tráfego flui em apenas uma direção, o modo normal de UDLD marca o link lógico como indeterminado e não desabilita a porta. Esse comportamento depende dos mecanismos da Camada 1 para detectar a falha física. Se um fio de fibra for desconectado e a negociação automática detectar a falha física, o link não permanecerá ativo. O UDLD não executa nenhuma ação de desligamento porque a Camada 1 já detectou o problema e o estado do link lógico do UDLD é indeterminado.

---

Modo agressivo

O modo agressivo inclui os recursos de detecção do modo normal e fornece proteção adicional para links de fibra óptica ponto a ponto e de par trançado. Ele detecta fios de fibra desconectados e condições nas quais um endpoint não pode enviar ou receber tráfego, uma porta permanece ativa enquanto a outra está inativa ou um fio de fibra se desconecta.

---

Os pacotes hello de UDLD atuam como heartbeat para o link ponto a ponto. Se o UDLD parar de receber esses pacotes depois que o link tiver sido estabelecido como bidirecional, o modo agressivo tentará restabelecer a relação bidirecional. Se o UDLD não puder restaurar a relação, ele desabilita a porta local afetada para impedir o uso continuado de um link cuja operação bidirecional não possa ser verificada.

Quando ambos os fios de fibra parecem operacionais para a Camada 1, o UDLD agressivo verifica se eles se conectam às portas vizinhas corretas e se o tráfego flui bidirecionalmente entre os vizinhos esperados. A autonegociação não pode executar essa validação de identidade de porta e vizinho porque opera na Camada 1.

---

Temporizadores de mensagem e espera UDLD

As informações de UDLD expiram quando uma porta que executa o UDLD não recebe pacotes UDLD da porta vizinha durante o tempo de espera. Esses temporizadores se aplicam à manutenção de informações de vizinho UDLD nos modos normal e agressivo; a ação após a expiração depende do modo configurado e da condição detectada. 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. Implementações recentes de UDLD permitem a configuração de intervalos 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 desabilita o link.

---

É importante escolher o intervalo correto de mensagem para garantir o tempo de detecção adequado. O intervalo de mensagens deve 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 mensagem padrão neste exemplo é de 15 segundos. Para o cenário clássico do temporizador STP IEEE 802.1D descrito, o tempo estimado de expiração de informações de UDLD é menor que o tempo estimado para que a porta bloqueada atinja o estado de encaminhamento.

Essa comparação não garante que o UDLD assertivo coloque a interface no estado err-disable antes que o STP altere a topologia de encaminhamento. O tempo aproximado para que as informações de vizinho UDLD expirem é três vezes o intervalo de mensagens. Por exemplo:

Texpiration ≈ message_interval × 3

---

Com o intervalo de mensagens padrão Texpiration ≈ 15 × 3 = 45 segundos. Para a operação do IEEE 802.1D STP clássico, o tempo aproximado para uma porta bloqueada envelhecer suas informações de STP armazenadas e passar pelos estados de escuta e aprendizado para o estado de encaminhamento é:

Tforward = max_age + (2 × forward_delay)

---

Com os temporizadores STP padrão: Tforward = 20 + (2 × 15) = 50 segundos - Ao comparar a expiração de informações de vizinho UDLD com a transição de porta STP, selecione um intervalo de mensagem que mantenha: Texpiration < Tforward

No modo agressivo, após a expiração das informações de vizinho UDLD, o UDLD tenta restabelecer a relação bidirecional enviando uma mensagem por segundo durante oito segundos. Se o estado bidirecional não puder ser restabelecido, o UDLD desabilita a porta local.

---

Exemplos de condições adicionais detectadas pelo modo agressivo incluem:

• O link físico está ativo em ambos os lados, mas a porta em um lado não transmite nem recebe mensagens UDLD.
• O link está ativo em um lado e inativo no outro. Por exemplo, em algumas interfaces de fibra, desconectar a fibra de transmissão da porta local pode deixar o link local ativo enquanto o link remoto faz a transição para baixo. Esse comportamento depende da plataforma, interface, transceptor e mecanismos da camada física.

---

Algumas implementações de Ethernet PHY fornecem sinalização de falha remota ou mecanismos de negociação de link que podem fazer com que um ou ambos os endpoints do link fiquem inativos após falhas físicas específicas. O comportamento varia por plataforma, tipo de interface, transceptor, meio físico e modo de negociação. O UDLD fornece validação da Camada 2 para condições unidirecionais que a sinalização da camada física não detecta. Quando um ponto final não pode transmitir/receber, ou quando um ponto final está ativo enquanto o outro está inativo, o próprio link com falha não fornece um caminho de encaminhamento completo e não forma um loop de encaminhamento. No entanto, uma interface que permaneça ativa pode continuar encaminhando o tráfego para um caminho não funcional, resultando em um buraco negro de tráfego. O UDLD agressivo detecta a perda de comunicação bidirecional e desabilita a porta local afetada se não puder restabelecer a relação de UDLD.

---

Configuração e monitoramento

Ative o UDLD em ambas as interfaces conectadas. Configure o mesmo modo UDLD em ambos os pontos finais para fornecer detecção de falha local consistente e comportamento de desabilitação por erro:

9300-1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
9300-1(config)#interface TenGigabitEthernet1/1/6
9300-1(config-if)#udld port 
9300-1(config-if)#end

9300-2#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
9300-2(config)#interface TenGigabitEthernet1/1/6
9300-2(config-if)#udld port 
9300-2(config-if)#end

Execute os comandos show udld <interface-id> e show udld neighbors em ambos os pontos finais do link. Confirme se cada interface está operacionalmente habilitada, se o estado atual é Bidirectional e se os identificadores de porta e dispositivo vizinho esperados são exibidos:

9300-1#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
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: 37500 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8CA00  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8C180
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-2  

9300-1#show udld neighbors 
Port           Device Name     Device ID    Port ID         Neighbor State
----           -----------     ---------    -------         --------------
Te1/1/6 F87A41A8CA00 1 Te1/1/6 Bidirectional  

Total number of bidirectional entries displayed: 1

9300-2#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
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: 32500 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8C180  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8CA00
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-1  

9300-2#show udld neighbors 
Port           Device Name     Device ID    Port ID         Neighbor State
----           -----------     ---------    -------         --------------
Te1/1/6 F87A41A8C180 1 Te1/1/6 Bidirectional 
Total number of bidirectional entries displayed: 1

---

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

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

9300-2#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
9300-2(config)#interface TenGigabitEthernet1/1/6
9300-2(config-if)#udld port aggressive 
9300-2(config-if)#end

---

Execute o comando show udld <interface-id> em ambos os pontos finais para verificar se o modo agressivo está habilitado operacionalmente:

9300-1#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
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: 31200 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8CA00  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8C180
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-2  

9300-2#show udld TenGigabitEthernet1/1/6

Interface Te1/1/6
---
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: 38600 ms
    Cache Device index: 1
    Current neighbor state: Bidirectional
    Device ID: F87A41A8C180  
    Port ID: Te1/1/6  
    Neighbor echo 1 device: F87A41A8CA00
    Neighbor echo 1 port: Te1/1/6

    TLV Message interval: 15 sec
    No TLV fast-hello interval
    TLV Time out interval: 5
    TLV CDP Device name: 9300-1

---

Execute o comando udld message time para alterar o intervalo de mensagem:

9300-1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
9300-1(config)#udld message time ?
  <1-90>  Time in seconds between sending of messages in steady state

---

Nos Cisco Catalyst 3000 e 9000 Series Switches, o valor de tempo da mensagem udld varia de 1 a 90 segundos, e o padrão é 15 segundos. Consulte os guias de referência de comando para verificar o intervalo aceito e o padrão em outros sistemas.

---

Informações Relacionadas

• Suporte técnico e downloads da Cisco

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

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

Histórico de revisões

Revisão	Data de publicação	Comentários
2.0	18-Aug-2026	Ortografia, gramática e linhas horizontais inseridas atualizadas para separar seções para facilitar a leitura.
1.0	09-Jul-2007	Versão inicial