Configuración de la función del protocolo UDLD

Introducción

En este documento se describe cómo el protocolo de Detección de enlace unidireccional (UDLD) puede ayudar a evitar los bucles y las anomalías en el tráfico en las redes con switch.

---

Prerequisites

Requirements

No hay requisitos específicos para este documento.

---

Componentes Utilizados

Este documento describe el funcionamiento general del UDLD. Los ejemplos de configuración y verificación de este documento se validaron en los switches Catalyst de Cisco serie 9300 que ejecutan la versión 17.X del IOS XE de Cisco.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

---

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

---

Definición del problema

El protocolo de árbol de extensión (STP) resuelve la topología física redundante en una topología de reenvío tipo árbol sin bucles. Para ello, bloquea uno o más puertos. Con uno o más puertos bloqueados, no hay loops en la topología de reenvío. STP depende para su funcionamiento de la recepción y transmisión de las Unidades de datos del protocolo de conexión en puente (BPDU). Si un puerto en el estado de bloqueo o descarte STP deja de recibir BPDU del puente designado, el STP finalmente desactualiza la información asociada con ese puerto y la mueve a un estado de reenvío.

Esto puede crear un loop STP donde los paquetes comienzan a recorrer indefinidamente el trayecto en loop y consumen más ancho de banda y recursos. Esto origina una posible interrupción de la red.

¿Cómo es posible que el switch no reciba BPDU mientras el puerto está activo? Esto se debe a un link unidireccional.

---

Un link se considera unidireccional cuando:

• El link funciona en ambos lados de la conexión.

• El lado local no recibe paquetes enviados por el lado remoto, mientras que el lado remoto recibe paquetes enviados por el lado local.

Considere el siguiente escenario, las flechas indican el flujo de BPDU STP:

---

Topología de estado de puerto STP

---

Durante la condición mostrada en esta topología, la interfaz en el switch B hacia el switch C es el puerto designado para el segmento B-C y transmite las BPDU hacia el switch C. La interfaz en el switch C hacia el switch B es un puerto no designado en el STP IEEE 802.1D clásico. O un puerto alternativo en RSTP y permanece en el estado de bloqueo/descarte mientras recibe y procesa BPDU del switch B. Aunque la interfaz en el switch C está en el estado de bloqueo o descarte, el puerto continúa recibiendo y procesando BPDU; estos estados evitan que el puerto reenvíe tramas de datos pero no impiden que reciba BPDU.

---

Considere qué sucede si el link B-C se vuelve unidireccional y la dirección B → C falla. El switch C ya no puede recibir BPDU del switch B, mientras que el switch B puede recibir BPDU transmitidas por el switch C. El switch C conserva la información aprendida de la última BPDU hasta que esa información se desactualiza. Con el STP IEEE 802.1D clásico y la edad máxima predeterminada de 20 segundos, esto puede tardar hasta 20 segundos. Una vez que la información STP se desactualiza, el switch C ya no considera al switch B superior en ese segmento, y el puerto puede pasar de Bloqueo a Escucha, luego Aprendizaje y, finalmente, Reenvío.

---

Esto crea un loop de reenvío de Capa 2 porque ya no hay un puerto bloqueado en el triángulo A-B-C. Las tramas de difusión, unidifusión desconocida y multidifusión pueden circular repetidamente por el bucle, lo que consume ancho de banda, CPU y puede provocar una tormenta de difusión.

Este escenario puede hacer caer la red, que es otro posible problema causado por un link unidireccional como un agujero negro de tráfico.

---

Flujo STP BPDU

---

Cómo funciona el protocolo de detección de link unidireccional

UDLD es un protocolo de capa 2 que complementa los mecanismos de detección de enlaces de capa 1 mediante la identificación de las comunicaciones unidireccionales y las inconsistencias de cableado específicas entre los dispositivos conectados directamente.

---

En la Capa 1, la negociación automática resuelve la señalización física y la detección de fallas. UDLD realiza tareas que la negociación automática no puede realizar, como la detección de identidades de vecinos y el cierre de puertos mal conectados. Al habilitar tanto la negociación automática como el UDLD; Las detecciones de capa 1 y capa 2 actúan conjuntamente para evitar las conexiones unidireccionales físicas y lógicas y el mal funcionamiento de otros protocolos.

UDLD funciona a través del intercambio de paquetes de protocolo entre los dispositivos vecinos. Para establecer una relación de vecino UDLD bidireccional, ambos dispositivos conectados directamente deben soportar el UDLD y tenerlo habilitado en las interfaces conectadas. Verifique el estado bidireccional en ambos dispositivos.

---

Cada puerto de switch configurado para UDLD envía paquetes de protocolo UDLD que contienen el dispositivo de puerto/ID de puerto, y los ID de dispositivo vecino/puerto vistos por UDLD en ese puerto.

Los puertos vecinos ven su propio dispositivo/ID de puerto (echo) en los paquetes recibidos del otro lado. Si el puerto no detecta su propio dispositivo /ID de puerto en los paquetes UDLD entrantes durante un período específico, el link se considera unidireccional.

Este algoritmo de eco permite la detección de estos problemas:

• El link está activo en ambos lados, sin embargo los paquetes sólo son recibidos por un solo lado.

• Errores de conexión (cable) cuando las fibras de recepción y transmisión no están conectadas al mismo puerto en el lado remoto.

---

Una vez que el UDLD detecta una condición unidireccional, coloca la interfaz local de detección en el estado err-disable. El estado de la interfaz remota depende de la detección del UDLD remoto y del comportamiento del link físico. Se imprime un mensaje similar en la consola:

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

---

Una interfaz inhabilitada por UDLD permanece en el estado err-disable hasta que se recupera manualmente o caduca un temporizador de recuperación errdisable habilitado. Corrija la falla de fibra, transceptor, cableado o interfaz remota antes de la recuperación. Utilice shutdown y no shutdown para la recuperación manual. En las plataformas que lo soportan, udld reset restablece las interfaces inhabilitadas/apagadas por UDLD. Después de la recuperación, ejecute los comandos show interfaces status err-disabled, show udld <interface-id> y show udld neighbors para confirmar que la interfaz está operativa y que la relación UDLD es bidireccional. Revise los registros del sistema para confirmar que el fallo no se repite.

---

Modos de funcionamiento del UDLD

El UDLD puede funcionar en dos modos: normal y agresivo:

---

Modo normal

Cuando se habilita el UDLD en una interfaz soportada, el modo normal es el modo operativo predeterminado a menos que se configure explícitamente el modo agresivo. UDLD funciona con mecanismos de Capa 1, como la negociación automática, para validar un link. Los mecanismos de capa 1 detectan la señalización física y los fallos de enlace, mientras que el UDLD identifica los dispositivos vecinos y verifica los hilos de fibra que se conectan a los puertos correctos.

En el modo normal, el UDLD detecta una condición unidireccional cuando los hilos de fibra están mal conectados entre los puertos y los mecanismos de Capa 1 no detectan el error de cableado. Si los hilos de fibra se conectan a los puertos correctos pero el tráfico fluye en una sola dirección, el modo normal UDLD marca el link lógico como indeterminado y no inhabilita el puerto. Este comportamiento se basa en los mecanismos de la capa 1 para detectar la falla física. Si se desconecta un hilo de fibra y la negociación automática detecta el fallo físico, el link no permanece activo. El UDLD no realiza ninguna acción de apagado porque la Capa 1 ya ha detectado el problema, y el estado del link lógico del UDLD es indeterminado.

---

Modo agresivo

El modo agresivo incluye las funciones de detección del modo normal y proporciona protección adicional para los enlaces de par trenzado y de fibra óptica punto a punto. Detecta los hilos de fibra mal conectados y las condiciones en las que un terminal no puede enviar ni recibir tráfico, un puerto permanece activo mientras el otro está inactivo o un hilo de fibra se desconecta.

---

Los paquetes de saludo UDLD actúan como un latido para el link punto a punto. Si el UDLD deja de recibir estos paquetes después de que el link se haya establecido como bidireccional, el modo agresivo intenta restablecer la relación bidireccional. Si el UDLD no puede restaurar la relación, inhabilita el puerto local afectado para evitar el uso continuo de un link cuya operación bidireccional no se puede verificar.

Cuando ambos hilos de fibra parecen operativos para la Capa 1, el UDLD agresivo verifica que se conectan a los puertos vecinos correctos y que el tráfico fluye bidireccionalmente entre los vecinos esperados. La negociación automática no puede realizar esta validación de vecino e identidad de puerto porque funciona en la Capa 1.

---

Temporizadores de mensaje y espera UDLD

La información UDLD caduca cuando un puerto que ejecuta UDLD no recibe paquetes UDLD del puerto vecino durante el tiempo de espera. Estos temporizadores se aplican al mantenimiento de la información de vecino UDLD en los modos normal y agresivo; la acción posterior a la expiración depende del modo configurado y de la condición detectada. El tiempo de espera del puerto está determinado por el puerto remoto y depende del intervalo del mensaje del lado remoto. Cuanto más corto sea el intervalo del mensaje, más corto será el tiempo de espera y más rápida será la detección. Las implementaciones recientes de UDLD permiten la configuración de intervalos de mensajes. La información de UDLD puede desactualizarse debido a una tasa de errores alta en el puerto causada por el mismo problema físico o por una discordancia del dúplex. Tal caída de paquetes no significa que el link sea unidireccional y el UDLD en el modo normal no inhabilita el link.

---

Es importante elegir el intervalo de mensaje adecuado para garantizar un tiempo de detección adecuado. El intervalo de mensaje debe ser lo suficientemente rápido como para detectar el link unidireccional antes de que se cree el loop de reenvío; sin embargo, no debe sobrecargar la CPU del switch. El intervalo de mensajes predeterminado en este ejemplo es de 15 segundos. Para el escenario clásico de temporizador IEEE 802.1D STP descrito, el tiempo estimado de vencimiento de la información UDLD es menor que el tiempo estimado para que el puerto bloqueado alcance el estado de reenvío.

Esta comparación no garantiza que el UDLD agresivo coloque la interfaz en el estado err-disable antes de que el STP cambie la topología de reenvío. El tiempo aproximado de vencimiento de la información de vecino UDLD es tres veces el intervalo del mensaje. Por ejemplo:

Texpiration ≈ message_interval × 3

---

Con el intervalo de mensaje predeterminado Texpire ≈ 15 × 3 = 45 segundos. Para el funcionamiento clásico de STP IEEE 802.1D, el tiempo aproximado para que un puerto bloqueado caduque su información de STP almacenada y realice la transición a través de los estados de escucha y aprendizaje al estado de reenvío es:

Tforward = max_age + (2 × forward_delay)

---

Con los temporizadores STP predeterminados: Tforward = 20 + (2 × 15) = 50 segundos -Al comparar el vencimiento de la información de vecino UDLD con la transición del puerto STP, seleccione un intervalo de mensaje que mantenga: Tvencimiento < Tforward

En el modo agresivo, una vez que caduca la información de vecino UDLD, el UDLD intenta restablecer la relación bidireccional enviando un mensaje por segundo durante ocho segundos. Si el estado bidireccional no se puede restablecer, el UDLD inhabilita el puerto local.

---

Algunos ejemplos de condiciones adicionales detectadas por el modo agresivo son:

• El link físico está activo en ambos lados, pero el puerto en un lado no transmite ni recibe mensajes UDLD.
• El link está arriba en un lado y abajo en el otro. Por ejemplo, en algunas interfaces de fibra, la desconexión de la fibra de transmisión del puerto local puede dejar el link local activo mientras el link remoto no funciona. Este comportamiento depende de la plataforma, la interfaz, el transceptor y los mecanismos de la capa física.

---

Algunas implementaciones de Ethernet PHY proporcionan mecanismos de negociación de link o señalización de falla remota que pueden hacer que uno o ambos extremos del link dejen de funcionar después de fallas físicas específicas. El comportamiento varía según la plataforma, el tipo de interfaz, el transceptor, los medios y el modo de negociación. UDLD proporciona validación de Capa 2 para condiciones unidireccionales que la señalización de capa física no detecta. Cuando un terminal no puede transmitir/recibir, o cuando un terminal está activo mientras el otro está inactivo, el link fallido en sí no proporciona una trayectoria de reenvío completa y no forma un loop de reenvío. Sin embargo, una interfaz que permanece activa, puede continuar reenviando tráfico a una trayectoria no funcional, lo que resulta en un agujero negro de tráfico. El UDLD agresivo detecta la pérdida de la comunicación bidireccional e inhabilita el puerto local afectado si no puede restablecer la relación UDLD.

---

Configuración y control

Habilite el UDLD en ambas interfaces conectadas. Configure el mismo modo UDLD en ambos extremos para proporcionar una detección de fallas local consistente y un comportamiento err-disable:

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

Ejecute los comandos show udld <interface-id> y show udld neighbors en ambos extremos del link. Confirme que cada interfaz esté habilitada operacionalmente, que el estado actual sea Bidireccional y que se muestren los identificadores de puerto y el dispositivo vecino esperado:

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

---

El UDLD agresivo se puede configurar en la interfaz con el 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

---

Ejecute el comando show udld <interface-id> en ambos extremos para verificar que el modo agresivo 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

---

Ejecute el comando udld message time para cambiar el intervalo de mensajes:

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

---

En los Cisco Catalyst 3000 y 9000 Series Switches, el valor de tiempo del mensaje udld varía de 1 a 90 segundos, y el valor predeterminado es 15 segundos. Consulte las guías de referencia de comandos para verificar el rango aceptado y el valor predeterminado en otros sistemas.

---

Información Relacionada

• Soporte técnico y descargas de Cisco

• Para los switches Catalyst 3560, consulte la Configuración UDLD

• Para los switches Catalyst 9300, consulte Cómo Configurar el UDLD 
• Para los switches Catalyst 9500, consulte Cómo Configurar el UDLD

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
2.0	18-Aug-2026	Ortografía, gramática, líneas horizontales insertadas actualizadas para separar secciones y facilitar su lectura.
1.0	09-Jul-2007	Versión inicial