Resolución de problemas OSPF: diagnosticar adyacencias, LSAs y problemas de convergencia

El troubleshooting de OSPF en producción es especialmente crítico cuando un fallo no se manifiesta como una caída total, sino como un «a veces funciona, a veces no»: las adyacencias se quedan atascadas en un estado intermedio, faltan prefijos individuales o la convergencia (tiempo hasta que las rutas se estabilizan tras un cambio) es claramente más larga de lo esperado. OSPF (Open Shortest Path First) es un protocolo de enrutamiento de estado de enlace: los routers intercambian información de estado (LSAs, Link-State Advertisements) y calculan localmente la ruta más corta. Precisamente esta mecánica proporciona señales de diagnóstico muy útiles —si se aborda de forma estructurada.

Este artículo está concebido como un runbook: primero las barandillas de seguridad (impacto, reversión), luego una secuencia de comprobación clara para adyacencias, LSAs/LSDB y problemas de convergencia. Cuando se muestran comandos, se presentan de forma deliberadamente genérica: la sintaxis difiere según la plataforma (Cisco IOS/IOS‑XE, NX‑OS, Juniper Junos, FRRouting, MikroTik, entre otros), pero los estados, contadores y patrones causales son en OSPF en gran medida idénticos.

OSPF‑Troubleshooting: 1) Antes del ingreso: alcance, riesgo y estrategia de reversión

Antes de cambiar «algo» en OSPF, aclare tres puntos: qué está afectado (alcance), cuál es el impacto potencial y cómo volver atrás (rollback). OSPF reacciona a los cambios con frecuencia de forma inmediata; un parámetro mal configurado puede restablecer una adyacencia, volver a inundar LSAs y, con ello, cargar la CPU/Control‑Plane —especialmente en nodos centrales.

Delimitar rápidamente el alcance

• ¿Sólo un enlace / un vecino? Entonces suele deberse a la interfaz, MTU, autenticación o temporizadores.
• ¿Varios vecinos en un área? Entonces son sospechosos el tipo de área, filtros, enlaces virtuales, tipo de red o el consenso DR/BDR.
• ¿«Faltan rutas» sin un problema de vecinos? Entonces probablemente se trate de tipos de LSA, sumarización, filtrado, Max‑LSA, lógica stub/NSSA o redistribución.
• Convergencia lenta a pesar de adyacencias correctas: SPF/LSA‑throttling, LSA‑flapping, errores de interfaz, CPU o una LSDB demasiado grande.

Estrategia de reversión (práctica)

En operación OSPF conviene planificar cada cambio de modo que pueda revertirse sin realizar «grandes» operaciones sobre OSPF:

• Copia de seguridad de la configuración (versionado, referencia de cambio, sello temporal).
• Un parámetro por cambio (no modificar Hello, Auth y tipo de red simultáneamente).
• Ventana de mantenimiento ante posibles resets de vecinos (Auth/MTU/tipo de red/cambio de área).
• Plan B: ruta estática temporal, ajuste temporal de costes (OSPF cost) o un shutdown/no‑shutdown controlado de enlaces individuales —pero como intervención deliberada, no como «prueba y error».

2) Adyacencias OSPF: comprender los estados y probar de forma dirigida

Los estados de vecino (Neighbor States) de OSPF son su primera brújula. Importante: según el tipo de red, no todas las vecindades alcanzan „FULL“. En redes Broadcast y NBMA suele estar FULL sólo la vecindad con el DR/BDR (Designated Router / Backup Designated Router); otras permanecen en 2-WAY, lo cual puede ser correcto. En Point-to-Point es normal que esté FULL entre ambos routers.

Los estados y lo que significan en operación

• DOWN: no se han visto mensajes Hello. Causa frecuente: L2/L3/ACL/Multicast/interfaz caída.
• INIT: se reciben mensajes Hello, pero la propia Router-ID no aparece en el Hello. Típico en tráfico unidireccional o filtros/ACL.
• 2-WAY: bidireccional, pero (en Broadcast/NBMA) no adyacente al DR/BDR. Puede ser correcto.
• EXSTART/EXCHANGE: sincronización de base de datos (DBD). A menudo incompatibilidad de MTU o fragmentación de paquetes/filtrado incorrecto.
• LOADING: se están procesando LSR/LSU (Link State Request/Update), pero no se completan. Frecuente por filtro de LSA, pérdida de paquetes, MTU/fragmentación o un plano de control sobrecargado.
• FULL: LSDB sincronizada (para la vecindad adyacente).

Secuencia de comprobación para „Neighbor no llega a FULL“

Trabaje de afuera hacia adentro: primero conectividad e interfaz, luego parámetros OSPF y, finalmente, LSDB/Exchange.

Paso A: ¿Es posible la conectividad L3 para OSPF?

OSPF usa el protocolo IP 89 (no TCP/UDP). En redes Broadcast los Hellos se envían a 224.0.0.5 (AllSPFRouters) y 224.0.0.6 (AllDRouters). En Point-to-Point también puede usarse multicast, según plataforma/tipo de red. Firewalls, ACLs, Security-Groups o CoPP (Control Plane Policing) deben permitirlo.

Enfoque mínimo de captura (Linux-Host como Tap/Span para análisis; en routers suele haber funciones integradas de captura de paquetes):

# Auf einem Mirror-Port oder Capture-Host:
# OSPF-Protokoll 89 und Multicast-Ziele prüfen
sudo tcpdump -ni eth0 'ip proto 89 or (ip multicast and (host 224.0.0.5 or host 224.0.0.6))'

Lo que debe ver: paquetes Hello periódicos (por defecto 10 s en Broadcast, 30 s en NBMA — puede variar). Si sólo se observa en una dirección, encaja con INIT (unidireccional). Si no se ve nada: L2/VLAN, interfaz o filtrado.

Paso B: ¿Coinciden los parámetros „must-match“?

Para una vecindad OSPF deben coincidir parámetros centrales. Cuáles exactamente depende del tipo de red y del conjunto de funciones, pero estos son los clásicos:

• Area-ID: ambos extremos deben estar en el mismo contexto de área OSPF (p. ej., Area 0 como backbone).
• Hello/Dead-Interval: deben coincidir; de lo contrario el vecino ignorará los Hellos.
• Netztyp (Broadcast, Point-to-Point, NBMA): influye en la elección de DR/BDR y en la expectativa de adyacencias.
• Autenticación: el tipo (p. ej. Simple/MD5/HMAC según la plataforma) y la clave deben coincidir. Importante: la autenticación a menudo es „silenciosa“ — claves erróneas causan Down/Init.
• Stub-Flag/Tipo de área: en áreas Stub/NSSA los tipos de área deben ser consistentes; de lo contrario la adyacencia falla.

Fallo típico en la práctica: cambios en el tipo de área o en la autenticación suelen provocar reinicios inmediatos de vecinos. Planifíquelo como un evento operativo (monitorización, ventana de mantenimiento).

Paso C: Aclarar correctamente incompatibilidades de MTU

MTU-Mismatch es una de las causas más frecuentes de EXSTART/EXCHANGE. OSPF negocia tamaños de paquete durante la sincronización de la base de datos; si un extremo envía paquetes más grandes de los que el otro acepta, verá retransmisiones, bucles de intercambio o estados bloqueados. Esto ocurre con frecuencia tras cambios en VLAN/MPLS/túneles, cuando solo en un lado se ha ajustado la L2-MTU.

• Indicio: el vecino oscila entre EXSTART y EXCHANGE o queda detenido allí.
• Por qué: los paquetes DBD/LSU se descartan o quedan fragmentados/bloqueados.
• Riesgo: un «Schnellfix» mediante MTU-Ignore puede enmascarar los síntomas, pero los problemas reales de fragmentación/Path-MTU permanecen.

Operativamente recomendable: establecer la MTU de forma consistente en ambos extremos y, si procede, verificar la Path-MTU a lo largo del trayecto (p. ej. en L3-Portchannels, QinQ, GRE/IPsec, VXLAN-Underlay).

Paso D: DR/BDR y tipo de red como fuente de errores

En segmentos Broadcast o NBMA se elige un DR/BDR. Eso influye en con quién se establece una adyacencia completa. Si espera que «todos a todos FULL», pero está en Broadcast con DR/BDR, es normal ver 2-WAY hacia vecinos no-DR. Se vuelve problemático cuando DR/BDR cambia constantemente (Flapping) o el DR no es accesible.

• Causas típicas: dominio L2 inestable, pérdida de paquetes, prioridades diferentes, o reinicios de gateways.
• Impacto: sincronizaciones repetidas de la LSDB, mayor inundación de LSA, problemas de convergencia.

3) LSAs y LSDB: Cuando faltan rutas o parecen «inconsistentes»

Si los vecinos están en FULL, pero faltan rutas o están mal ponderadas, los LSAs y la Link-State Database (LSDB, la base de datos de topología interna de OSPF) son el siguiente foco. OSPF no calcula «de la nada»: si una información no existe como LSA en la LSDB, tampoco puede aparecer en la tabla de enrutamiento.

Tipos de LSA en la práctica (breve y operativo)

• Type 1 (Router-LSA): describe los enlaces de un router dentro de una Area. Base para SPF.
• Type 2 (Network-LSA): lo genera el DR en Broadcast/NBMA y describe el segmento de red compartido.
• Type 3 (Summary-LSA): generado por ABRs (Area Border Routers) para redes resumidas o reinyectadas entre Areas.
• Type 4 (ASBR-Summary): muestra el camino hacia un ASBR (Autonomous System Boundary Router) que inyecta rutas externas.
• Type 5 (External-LSA): rutas externas (Redistribution), no permitidas en Stub-Areas.
• Type 7 (NSSA-External): rutas externas en NSSA-Areas; en el ABR se traducen a Type 5.

Por qué esto importa: si, por ejemplo, en una Stub-Area espera de repente Type-5-External, no es que «OSPF esté roto», sino que el diseño o la definición del Area no coincide con la expectativa.

Ruta de diagnóstico: «Falta la ruta» en cinco pasos

1. ¿Está el prefijo presente en la LSDB? Si no: comprobar origen/redistribución/ABR/filtros.
2. ¿Está presente en el tipo de LSA correcto? Externo (Tipo 5/7) vs. interno (Tipo 1/3).
3. ¿Proviene del área esperada? Comprobar el diseño de áreas y las rutas ABR.
4. ¿Se está instalando? Distancia administrativa, fallo de RIB, preferencia de ruta o políticas pueden impedir la instalación.
5. ¿Se sigue anunciando? Filtros, sumarización, traducción NSSA, o problemas Max-LSA/LSA-Refresh.

Para la recopilación de datos es útil crear una colección estandarizada de „Show“ por plataforma. Ejemplo (como runbook de plantilla; adapte los comandos concretos a su SO):

# Runbook: Daten sammeln (als Vorlage, Kommandos je nach Plattform ersetzen)
# 1) OSPF Nachbarn + Zustände
# 2) OSPF Interface-Details (Timer, Netztyp, MTU, Auth)
# 3) LSDB-Auszug: relevante LSA-Typen und betroffene Präfixe
# 4) Routingtabelle: Präfix vorhanden? über welchen Next-Hop?
# 5) Logs: Neighbor-Resets, Auth-Fehler, MTU/DBD-Hinweise

Causas típicas de LSAs ausentes o „extrañas“

• Area-Mismatch / falscher Area-Typ: Stub/NSSA inconsistentes, violación del diseño del backbone, enlaces virtuales no estables.
• Filtros OSPF o políticas de rutas: filtrado de entrada o salida de Summary-/External-LSAs (dependiente de la plataforma).
• Sumarización: El ABR agrega; los prefijos individuales dejan de aparecer de forma granular. Eso es intencionado, pero puede complicar la resolución de problemas.
• Problemas de redistribución: Las rutas externas no se insertan (p. ej. reglas de coincidencia ausentes) o se propagan con el tipo incorrecto (E1/E2).
• Max-LSA / límites de LSDB: Algunas plataformas pueden eliminar vecinos o rechazar LSAs cuando la LSDB se desborda; relevante en dominios de gran tamaño.

4) Problemas de convergencia: cuando OSPF tarda „demasiado“ o parece inestable

La convergencia no es solo „el routing volverá en algún momento“. En operación importa si sus aplicaciones (VoIP, ERP, VDI, Storage, API-Gateways) se estabilizan dentro de los segundos definidos. La convergencia OSPF se compone de varios tiempos: detección del evento (Dead-Timer o BFD), flooding de LSAs, cálculo SPF, instalación en la tabla de enrutamiento y, si procede, programación de la FIB en hardware.

Primero diferenciar: lento vs. inestable

• Lento: Tras un evento de enlace tarda reproduciblemente „demasiado“, pero luego se estabiliza.
• Inestable: los vecinos presentan flapping, las LSAs se vuelven a inundar continuamente y las rutas cambian con frecuencia.

Causas frecuentes de convergencia lenta

• Dead-Interval demasiado alto: la detección del evento tarda demasiado (clásico 40s). Solución: ajuste de timers o BFD (Bidirectional Forwarding Detection; comprobación de liveness más rápida por debajo de OSPF).
• Control plane sobrecargado: el procesamiento de SPF y LSA compite con otras tareas; visible como alta CPU o encolamiento.
• LSDB grande: muchos LSAs significan más flooding y tiempos de cálculo SPF más largos.
• SPF/LSA-Throttling: los mecanismos de protección limitan los cálculos durante tormentas de eventos; útiles contra la inestabilidad, pero perjudican la respuesta «inmediata».
• Problemas L2: pérdida de paquetes/jitter en el enlace; OSPF debe retransmitir, la adjacency se resincroniza.

Causas frecuentes de convergencia inestable (flapping)

• Física: errores CRC, desajuste de dúplex/velocidad, ópticas inestables, enlaces inalámbricos/WAN variables.
• ECMP/Asimetría: el tráfico toma rutas diferentes, los retornos se filtran (síntoma INIT).
• Cambio de DR/BDR en segmentos broadcast por inestabilidad L2 o conflictos de prioridad.
• Configuración errónea: temporizadores distintos, rotación de claves de autenticación solo en un lado, MTU no ajustada en todos los puntos tras un cambio.

Estrategia de medición y observación (apta para monitoring)

Para «Monitoraggio» importa que no solo depure la convergencia una vez, sino que la haga mensurable de forma continua:

• Tiempo de actividad del vecino y tasa de flaps: número de transiciones de estado por hora/día.
• LSA-Churn: cuántos LSAs se generan/refresh/son retransmitidos por unidad de tiempo.
• Ejecuciones SPF: frecuencia y duración de los cálculos SPF (si la plataforma proporciona métricas).
• Tasas de errores de interfaz: CRC, descartes de entrada, descartes por cola, potencia óptica (en fibra).
• Correlación de eventos: Link-Down/Up, cambio de vecino OSPF, pico de CPU, posteriormente alarmas de aplicaciones.

Si solo mide «el ping ya responde», pasa por alto microinterrupciones que, por ejemplo, causan tormentas de TCP reset o pérdidas de paquetes.

5) Listas de comprobación prácticas: asegurar rápidamente que no se le escape nada

Lista de comprobación A: el vecino no alcanza estado UP

• Interfaz up/up, VLAN/etiquetado/trunking correctos
• Direccionamiento IP / máscara de subred correctos, sin IP duplicada
• OSPF activado en la interfaz correcta (verificar passive-interface)
• Los timers Hello/Dead coinciden
• ID de área y tipo de área coinciden (Stub/NSSA)
• Autenticación: método + clave/Key-ID consistentes
• MTU consistente en ambos lados; fragmentación/PMTUD no bloqueadas
• Tipo de red consistente (p2p vs broadcast); comportamiento DR/BDR entendido
• ACL/Firewall/CoPP permite IP Proto 89 y multicast

Lista de comprobación B: vecinos en FULL, pero falta la ruta

• ¿Prefijo presente en la LSDB? Si no: origen/redistribución/ABR/filtros
• Tipo de LSA plausible (interno vs externo; traducción NSSA)
• ¿Resumen en ABR activo? Verificar expectativa respecto a rutas detalladas
• ¿Tabla de ruteo/RIB instalada? distancia administrativa/política/siguiente salto recursivo
• ¿Forwarding/FIB correcto? (programación en hardware, contexto VRF)

Lista de comprobación C: convergencia demasiado lenta

• Detección de eventos: Dead-Interval vs. BFD
• LSA-Flooding: pérdida de paquetes, retransmisiones, errores de interfaz
• SPF: CPU/memoria, parámetros de SPF-throttling, tamaño de LSDB
• Diseño: áreas demasiado grandes, demasiados ABR/ASBR, redistribución innecesaria
• Fuente de cambios: enlaces inestables, port-channels que hacen flap, ópticas defectuosas

6) Implementación: correcciones típicas — y cuándo fracasan

En el troubleshooting es tentador aplicar soluciones rápidas («workarounds»). Es mejor: aislar la causa y luego aplicar la corrección con un análisis claro de efectos secundarios.

Ajuste de temporizadores y BFD

El ajuste de temporizadores (Hello/Dead reducir) puede acelerar la convergencia, pero aumenta la sensibilidad al jitter y a pérdidas breves de paquetes. BFD suele ser la alternativa más limpia: proporciona detección rápida de enlace/ruta, mientras OSPF mantiene la lógica de topología. BFD puede fallar por rutas asimétricas, errores en el offload de hardware o por intervalos demasiado agresivos en el WAN.

Solucionar problemas de MTU y Path-MTU

La solución sostenible es la consistencia: misma MTU, misma encapsulación y no bloquear ICMP si se necesita PMTUD (Path MTU Discovery). «MTU Ignore» puede ayudar a corto plazo, pero es arriesgado: grandes LSUs o el tráfico de aplicaciones pueden seguir fragmentándose o perderse.

Racionalizar el diseño de áreas

Muchos problemas de convergencia y con LSAs son consecuencia del diseño: dominios de flooding demasiado grandes, Externals innecesarios o límites de área poco claros. Una planificación limpia de Area-0, una redistribución limitada y una summarización sensata reducen el LSA-Churn. Esto puede fracasar por razones organizativas (esfuerzo de cambios) o por dependencias, si las aplicaciones esperan rutas IP „fijas“.

Estabilizar DR/BDR

Si el flapping de DR/BDR es un problema, ayudan prioridades claras y segmentos L2 estables. En algunos diseños, Point-to-Point (cuando sea posible) es más fácil de operar que grandes dominios de broadcast. Puede fracasar si el diseño L2 (p. ej. Campus-VLANs) no es fácilmente modificable.

7) Documentación y rutina operativa: del Troubleshooting a la estabilidad

Los problemas de OSPF reaparecen cuando el conocimiento operativo no se incorpora „al proceso“. Dos elementos sencillos han demostrado su eficacia:

• Paquete de diagnóstico estandarizado: ¿Qué salidas recopila usted en eventos Neighbor-/LSA-/Convergence? ¿Dónde se almacenan? ¿Quién las analiza?
• Change-Guardrails: Para rotación de claves de autenticación, cambios de MTU, cambios de área y redistribución existe un runbook breve con comprobaciones antes/después y rollback.

Planifique además límites de capacidad: si la LSDB crece (ubicaciones, VRFs, nuevos Externals), no solo aumenta la necesidad de memoria, sino también la carga de cálculo y de flooding. Las tendencias tempranas valen más aquí que un único „Después de la ampliación todo iba lento“.

Conclusión: Con una secuencia de comprobación fija los problemas de OSPF son manejables

La resolución de problemas de OSPF es mucho más sencilla si usted separa la diagnosis de forma consistente en tres niveles: relaciones de vecinos (estados y parámetros Must-match), LSAs/LSDB (¿está la información presente y en el tipo correcto?) y Convergence (detección de eventos, flooding, SPF, instalación). Con un runbook claro, capturas reproducibles y monitorización de flaps, LSA-Churn y errores de interfaz, encontrará las causas más rápido y evitará soluciones que solo desplazan los síntomas.

Para este tema también son importantes la relación de vecinos Ospf y las LSA Ospf. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en la práctica.