Kassinipedia

OSPFv3 - Troubleshooting

Se lee en 5 min

Lo que funciona igual que en v2

Estos problemas se diagnostican con la misma lógica que OSPFv2 — mira
esa página:

  • Timers Hello/Dead que deben coincidir.
  • MTU mismatch → atasco en EXSTART/EXCHANGE.
  • Area ID que debe coincidir.
  • Elección de DR/BDR (prioridad, no apropiativa, priority 0).
  • Flapping y recálculos de SPF (show ospfv3 statistics).
  • Redistribución, seed metric, E1 vs E2.
  • Backbone discontiguo y virtual links.

Orden de diagnóstico

show ipv6 interface brief      → ¿IPv6 up? ¿link-local presente?
show ospfv3 interface Gi0/0    → Instance ID, network type, timers, área
show ospfv3 interface brief    → columna AF (¿familia activada?)
show ospfv3 neighbor           → ¿existe el vecino? ¿en qué estado?
show ospfv3 database prefix    → ¿está el prefijo (Type 9)?
show ipv6 route ospf           → rutas IPv6
show ip route ospfv3           → rutas IPv4 (modo AF)
--- común con v2 (misma lógica) ---
show ospfv3 statistics         → flapping / SPF
show ospfv3 virtual-links      → backbone discontiguo
debug ipv6 ospf adj | hello    → último recurso

(Sintaxis tradicional: "show ipv6 ospf ..." en lugar de "show ospfv3 ...")

1. La adyacencia no se forma — causas propias de v3

Además de las causas compartidas con v2, en OSPFv3 revisa:

Causa propia de v3Dónde confirmarlo
Instance ID distinto entre extremosshow ospfv3 interface Gi0/0
IPv6 no habilitado en la interfazshow ipv6 interface brief
Falta la Link Local Address (FE80::)show ipv6 interface Gi0/0
Address-family no activada en la interfazshow ospfv3 interface brief (columna AF)

Instance ID mismatch

El Instance ID debe coincidir en ambos extremos del enlace. Si no
coincide, los routers descartan los Hellos del otro y la adyacencia
nunca forma — sin un mensaje de error obvio. Por defecto es 0; el
problema aparece cuando alguien lo cambió en un solo lado.

2. IPv6 y link-local — la base sobre la que corre v3

OSPFv3 opera sobre direcciones link-local (FE80::), no sobre las IPv6
globales. Consecuencias al diagnosticar:

  • Si la interfaz no tiene link-local activa, OSPFv3 no puede operar
    aunque tenga una IPv6 global configurada. Normalmente la link-local se
    genera sola al habilitar IPv6 (ipv6 enable o al poner una IPv6).

  • El next-hop de todas las rutas v3 es una FE80:: — es lo esperado,
    no un fallo.

  • IPv6 unicast routing debe estar habilitado globalmente, o el router
    no reenvía tráfico IPv6 aunque OSPFv3 aprenda las rutas.

Dónde confirmar: show ipv6 interface Gi0/0 (link-local presente) ·
show ipv6 route ospf (next-hops FE80::)

3. Router ID ausente o en 0.0.0.0

En v3 el problema es más frecuente que en v2:

  • El Router ID siempre es un número de 32 bits en formato IPv4, aunque
    la red sea solo IPv6.

  • Si el router no tiene ninguna interfaz IPv4 de la que derivarlo y no
    lo configuraste manualmente, el proceso no arranca o queda con RID
    0.0.0.0.

  • Por eso en v3 la práctica estándar es configurar el router-id
    manualmente     siempre.

  • Un cambio de RID no aplica hasta clear ospfv3 process (o
    clear ipv6 ospf process en sintaxis tradicional).

Dónde confirmar: show ospfv3 (campo Router ID)

4. Confusión entre address-families (modo AF)

Cuando un mismo proceso transporta IPv6 e IPv4, surgen problemas de
“la ruta no está donde la busco”:

  • Buscar una ruta IPv4 con el comando IPv6 → show ipv6 route ospf
    no muestra rutas IPv4 aunque existan. Para IPv4 en v3 usa
    show ip route ospfv3.

  • La address-family no está activada en la interfaz → aunque el
    proceso exista, esa familia no forma vecinos ahí. Confírmalo en la
    columna AF de show ospfv3 interface brief.

  • Adyacencia formada en una familia pero no en la otra → revisa que
    ambas familias estén habilitadas y sin shutdown en los dos extremos.

Dónde confirmar: show ospfv3 interface brief (columna AF) ·
show ospfv3 neighbor (cabecera de address-family)

5. FULL pero falta la ruta — matiz de v3

La lógica es la misma que en v2, con una vuelta de tuerca propia de v3:

  • El direccionamiento no viaja en los Type 1/2, sino en los
    Link LSA (Type 8) e Intra-Area Prefix LSA (Type 9).

  • Por eso, si la adyacencia está en FULL y el Router LSA existe pero
    falta un prefijo, el problema suele estar en el Intra-Area Prefix
    LSA    , no en el Router LSA.

¿Está el prefijo en el LSA correcto?

En v2 mirabas el Router/Network LSA para los prefijos. En v3 esos LSAs
ya no llevan direcciones — revisa el Type 9 (prefix) con
show ospfv3 database prefix. Un Router LSA presente pero sin su
prefijo asociado apunta directo ahí.

Dónde confirmar: show ospfv3 database prefix · show ospfv3 database link

6. Acciones de reparación (Comandos clear)

  • clear ospfv3 process (AF) / clear ipv6 ospf process
    (tradicional) → reinicia todo el proceso: re-evalúa Router ID, re-forma
    adyacencias y corre SPF completo. Necesario tras cambiar el router-id.

  • clear ospfv3 neighbor → resetea adyacencias sin reiniciar el
    proceso (opción suave).

Cuidado en producción

Igual que en v2, clear ospfv3 process interrumpe brevemente todo el
routing OSPFv3 del router. Úsalo en ventana de mantenimiento.

7. Leer los debug

debug consume CPU; úsalo puntual y cierra con undebug all.

  • debug ipv6 ospf hello → observa los Hellos v3 en vivo. Un
    Instance ID mismatch o un Hello rechazado aparece aquí cuando la
    salida normal no da pistas.

  • debug ipv6 ospf adj → la negociación de adyacencia paso a paso:
    imprime el motivo exacto de un atasco (MTU, autenticación IPsec,
    parámetros).

Autenticación en v3

OSPFv3 no usa la autenticación propia de v2 (null/plaintext/MD5), sino
IPsec nativo de IPv6. Un problema de auth en v3 es en realidad un
problema de la SA de IPsec — se diagnostica del lado de IPsec, no
con los parámetros de OSPF.

Vista Gráfica