Resolución de Problemas del Tiempo de Convergencia EIGRP en Escenarios de Falla de Link Dual de Catalyst 8500
Contenido
Introducción
Este documento describe el análisis y el procesamiento del Tiempo de Convergencia EIGRP en Escenarios de Falla de Link Dual de Catalyst 8500.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Conceptos y funcionalidad del protocolo de routing de gateway interior (EIGRP) mejorado
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- Plataforma de extremo Cisco Catalyst C8500-12X en la versión 17.12.05a
- Switch Cisco Catalyst C9500 en la versión 17.12.05a
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.
Fondo EIGRP
EIGRP (Enhanced Interior Gateway Routing Protocol) es un protocolo de routing de vector de distancia mejorado de Cisco. Asegura el cálculo de ruteo sin loops a través de DUAL (Algoritmo de actualización difusora) y logra una convergencia rápida cuando hay trayectos alternativos disponibles.
En la resolución de problemas de EIGRP, la información debe distinguirse:
| Tabla/concepto |
Función |
| Tabla de vecino |
Registra los vecinos que han establecido relaciones de adyacencia EIGRP. |
| Tabla de topología |
Guarda las trayectorias candidatas y el estado DUAL aprendido de los vecinos. |
| Tabla de ruteo |
Almacena las rutas que se utilizan en última instancia para el reenvío de tráfico real. |
| Sucesor |
La mejor trayectoria actual, instalada en la tabla de ruteo. |
| Sucesor factible (FS) |
Ruta de respaldo no circular que cumple las condiciones de viabilidad; se puede conmutar directamente en caso de falla de la trayectoria principal. |
Fondo del problema
Descripción de problemas
El comportamiento del problema: Después de apagar administrativamente dos interfaces EIGRP simultáneamente, una de las rutas asociadas con esas interfaces aún se podía observar en la tabla de ruteo por un período corto. Se espera que todas las rutas aprendidas a través de las dos interfaces fallidas desaparezcan inmediatamente después de que ambas interfaces se hayan apagado.
Topología
El generador de tráfico IXIA anunció 15 000 rutas en el dominio EIGRP para simular un entorno de routing a escala de producción.
Conclusión
Este comportamiento es esperado y es causado por el EIGRP DUAL (Diffusing Update Algorithm). No es un defecto de software.
Cuando varias interfaces fallan casi simultáneamente, DUAL intenta instalar una trayectoria factible alternativa antes de iniciar un recálculo completo de toda la red. Como resultado, la tabla de ruteo puede mostrar temporalmente una ruta a través de otro sucesor disponible o sucesor factible hasta que converja la topología.
Procedimiento de prueba
Los debugs se habilitaron en C8500-1 antes de apagar dos interfaces simultáneamente.
debug eigrp fsm
debug eigrp neighbor
debug eigrp packets
debug ip routing
debug ip eigrp
Las interfaces se apagaron simultáneamente.
C8500-1(config)#interface range Te0/0/2, Te0/0/3
C8500-1(config-if-range)#shutdown
Procesamiento DUAL esperado
Aquí se muestra la secuencia de eventos observados durante la convergencia.
Paso 1 - Las interfaces se desactivan
Una vez que las interfaces se cierran administrativamente:
- El estado de la interfaz cambia a INACTIVO.
- Las rutas conectadas se eliminan inmediatamente.
- La adyacencia de vecino se declara inactiva.
- DUAL inicia el recálculo de la topología.
Ejemplo de depuración:
RT: interface Te0/0/2 removed from routing table
RT: interface Te0/0/3 removed from routing table
%DUAL-5-NBRCHANGE: EIGRP-IPv4 500: Neighbor 192.168.11.2 (TenGigabitEthernet0/0/2) is down: interface down
%DUAL-5-NBRCHANGE: EIGRP-IPv4 500: Neighbor 192.168.22.2 (TenGigabitEthernet0/0/3) is down: interface down %LINK-5-CHANGED: Interface TenGigabitEthernet0/0/2, changed state to administratively down %LINK-5-CHANGED: Interface TenGigabitEthernet0/0/3, changed state to administratively down
En este punto, el sucesor original deja de ser válido.
C8500-1#show ip route eigrp
10.0.0.0/24 is subnetted, 15000 subnets D 10.0.0.0 [90/256768] via 198.168.23.2, 00:00:00, TenGigabitEthernet0/0/1 D 10.0.1.0 [90/256768] via 198.168.23.2, 00:00:01, TenGigabitEthernet0/0/1 D 10.0.2.0 [90/256512] via 192.168.22.2, 00:00:02, TenGigabitEthernet0/0/3 <<<<<< not disappear directly D 10.0.3.0 [90/256768] via 198.168.23.2, 00:00:01, TenGigabitEthernet0/0/1 D 10.0.4.0 [90/256512] via 192.168.22.2, 00:00:02, TenGigabitEthernet0/0/3 <<<<<< not disappear directly D 10.0.5.0 [90/256512] via 192.168.22.2, 00:00:02, TenGigabitEthernet0/0/3 <<<<<< not disappear directly D 10.0.6.0 [90/256768] via 198.168.23.2, 00:00:00, TenGigabitEthernet0/0/1 D 10.0.7.0 [90/256768] via 198.168.23.2, 00:00:00, TenGigabitEthernet0/0/1 D 10.0.8.0 [90/256768] via 198.168.23.2, 00:00:01, TenGigabitEthernet0/0/1 D 10.0.9.0 [90/256768] via 198.168.23.2, 00:00:00, TenGigabitEthernet0/0/1 D 10.0.10.0 [90/256512] via 192.168.22.2, 00:00:03, TenGigabitEthernet0/0/3 <<<<<< not disappear directly D 10.0.11.0 [90/256512] via 192.168.22.2, 00:00:03, TenGigabitEthernet0/0/3 <<<<<< not disappear directly D 10.0.12.0 [90/256512] via 192.168.22.2, 00:00:03, TenGigabitEthernet0/0/3
Paso 2 - DUAL busca una ruta alternativa
Antes de inundar las consultas a través de la red, DUAL verifica su tabla de topología en busca de otro sucesor válido.
Ejemplo de información de topología:
| Salto siguiente |
Estado |
|---|---|
| 192.168.11.2 |
Sucesor original (erróneo) |
| 192.168.22.2 |
Mejor ruta alternativa |
| 198.168.23.2 |
Sucesor factible |
El comando debug muestra:
Find FS for destination
EIGRP-IPv4(500): 192.168.11.2 metric INF/INF (invalid) EIGRP-IPv4(500): 192.168.22.2 metric 256512/256256
EIGRP-IPv4(500): 198.168.23.2 metric 256768/256512
Por lo tanto, DUAL selecciona 192.168.22.2(metric = 256512)como el nuevo sucesor.
Paso 3 - Instalación de ruta temporal
La tabla de ruteo se actualiza inmediatamente.
RT: delete route to 10.0.0.0 via 192.168.11.2
RT: updating eigrp 10.0.0.0/8 via 192.168.22.2
... RT: rib update return code: 19 EIGRP-IPv4: routing table not updated thru 192.168.23.2
Aunque ya existe otra ruta a través de 192.168.23.2, no está instalada, porque aún hay disponible una métrica mejor.
Por lo tanto, los usuarios pueden observar que la ruta aún existe aunque una de las interfaces fallidas ya haya sido apagada.
Este es el comportamiento que causó preocupación al administrador de la red.
Paso 4 - La Segunda Ruta También Falla
La segunda interfaz se desactiva posteriormente.
%DUAL-5-NBRCHANGE: Neighbor 192.168.22.2 is down
En este momento:
- El sucesor actual desaparece.
- No queda ningún sucesor válido inmediato.
- DUAL ingresa en el estado Activo.
RT: delete route to 10.0.0.0 via 192.168.22.2
RT: no routes to 10.0.0.0, delayed flush
Paso 5: DUAL recibe una respuesta
DUAL envía consultas y espera las respuestas de los vecinos restantes.
Un vecino restante responde con una ruta alternativa.
EIGRP: Received REPLY on Te0/0/1 from 192.168.23.2 ... RT: add 10.0.0.0/8 via 192.168.23.2, eigrp metric [90/256768]
A continuación, se instala el nuevo sucesor.
Paso 6: Reconvergencia de la red
Una vez completada la convergencia, EIGRP anuncia la topología actualizada.
Send UPDATE
Advertise out Te0/0/1
Todos los vecinos reciben la nueva información de topología.
La red vuelve a un estado estable.
Plazos de convergencia
¿Por qué sigue existiendo la ruta?
La razón clave es que DUAL no elimina inmediatamente un destino si hay disponible otro sucesor válido o sucesor factible.
En su lugar, DIGRP intenta preservar la continuidad de reenvío conmutando el tráfico a otra trayectoria disponible antes de iniciar un nuevo cálculo completo de la topología.
Por lo tanto, después de la primera falla de interfaz:
- La ruta original desaparece.
- Se instala inmediatamente una ruta alternativa mejor.
- El destino permanece presente en la tabla de ruteo.
Sólo después de que la segunda ruta alternativa también deje de estar disponible DUAL iniciará otro nuevo cálculo e instalará la ruta final disponible.
Este comportamiento es totalmente coherente con el objetivo de diseño EIGRP de convergencia rápida.
Conceptos clave DUAL
| Término |
Descripción |
|---|---|
| Sucesor |
Mejor ruta sin loops actual instalada en la tabla de ruteo. |
| Sucesor factible |
Ruta sin loops de respaldo almacenada en la tabla de topología. |
| Distancia factible (FD) |
Métrica calculada más baja para un destino. |
| Distancia informada (RD) |
Métrica anunciada por un vecino. |
| Estado activo |
DUAL está buscando una nueva ruta. |
| Estado pasivo |
La ruta es estable. |
| Recuento de respuestas |
Número de respuestas pendientes antes de que finalice la convergencia. |
| Métrica = Infinito |
Indica que la ruta ya no es accesible. |
| Código de retorno de NERVIO 19 |
La ruta candidata no se instaló porque ya existe una mejor ruta en el RIB |
Conclusión final
El comportamiento observado es el comportamiento EIGRP DUAL esperado en lugar de una anomalía de ruteo.
Cuando dos interfaces se cierran en sucesión rápida:
- EIGRP elimina inmediatamente las rutas asociadas con la interfaz fallida.
- DUAL instala el mejor sucesor alternativo disponible.
- El destino permanece visible en la tabla de routing porque hay una ruta alternativa disponible.
- Si la ruta alternativa también falla, DUAL realiza otro nuevo cálculo.
- Después de recibir respuestas de los vecinos restantes, se instala un nuevo sucesor y se completa la convergencia.
Por lo tanto, la observación de que una ruta permanece en la tabla de ruteo después de apagar simultáneamente dos interfaces es un resultado normal del proceso de convergencia DUAL y no indica un defecto de software.
Información Relacionada
- Comprensión y uso del protocolo de enrutamiento de gateway interior mejorado
- Resuelva problemas comunes de EIGRP
- Soporte técnico y descargas de Cisco
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
31-Aug-2026
|
Versión inicial |
Comentarios