0% del curso completado
OSPFv3 para IPv6 (3.3)
📋 En esta lección
OSPFv3 es OSPF para IPv6 — y la buena noticia es que ya lo sabes casi todo: mismos conceptos, mismos estados, mismo SPF, mismo DR/BDR. Aquí aprendes lo que cambia: configuración solo por interfaz, transporte sobre link-local, el RID que sigue siendo un número IPv4, y la verificación con los
show ipv6 ospf. La lección más corta del módulo — a propósito.
Lo que NO cambia
Todo el modelo de las lecciones 7.3-7.4 se conserva intacto en OSPFv3 (RFC 5340):
- Link-state con LSDB y SPF/Dijkstra — el mapa idéntico por área y el cálculo local.
- Vecindades y estados — Hello/Dead 10/40, Down → Init → 2-Way → ExStart → Exchange → Loading → Full; los mismos requisitos de coincidencia (área, timers) y las mismas averías (MTU en ExStart).
- DR/BDR en multiacceso — misma elección (prioridad, luego RID), misma no-preempción, mismo 2-Way legítimo entre DROTHERs.
- Coste = referencia/BW con la misma trampa de la referencia por defecto — y el mismo
auto-cost reference-bandwidthcoherente en todo el dominio. - Área 0, single-area para el CCNA, passive-interface, AD 110.
Si dominas OSPFv2, OSPFv3 se aprende en los diez minutos que tarda esta lección. El examen lo sabe — y pregunta precisamente las diferencias.
Lo que SÍ cambia
1. El Router ID sigue siendo "una IPv4" — y ahora puede ser obligatorio
El RID de OSPFv3 mantiene el formato de 32 bits (1.1.1.1). En un router dual stack con interfaces IPv4, puede autoelegirse como siempre; en un router solo-IPv6 no hay de dónde deducirlo: sin router-id manual, el proceso no arranca (%OSPFv3-4-NORTRID). Otra razón — ya la última que te faltaba — para configurarlo a mano siempre.
2. Configuración solo por interfaz — network ha muerto
OSPFv3 eliminó el comando network. Las interfaces se activan una a una — el "estilo moderno" de la lección 7.4, ahora único:
R1(config)# ipv6 unicast-routing ← el interruptor del Módulo 6
R1(config)# ipv6 router ospf 1
R1(config-rtr)# router-id 1.1.1.1
R1(config-rtr)# passive-interface GigabitEthernet0/0
R1(config-rtr)# exit
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ipv6 ospf 1 area 0
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ipv6 ospf 1 area 0
Y al activarse en la interfaz, OSPFv3 anuncia todos los prefijos IPv6 de esa interfaz (recuerda: varias GUAs conviven con naturalidad — lección 6.4).
3. Todo viaja en link-local
La consecuencia natural del Módulo 6: los Hellos y las actualizaciones de OSPFv3 usan como origen la link-local de la interfaz, hacia los multicast ff02::5 (todos los routers OSPF — el heredero de 224.0.0.5) y ff02::6 (DR/BDR — el heredero de 224.0.0.6).
Dos consecuencias operativas:
show ipv6 ospf neighbormuestra vecinos por su link-local — no por su GUA. No te desconcierte verFE80::2como dirección del vecino: es lo correcto (y otra razón para las link-locals manuales legibles de la lección 6.4).- Las rutas aprendidas tienen next-hop link-local (
via FE80::2, GigabitEthernet0/1) — coherente con las estáticas IPv6 de la lección 7.2 y el gateway de SLAAC.
Matiz fino: los routers OSPFv3 pueden formar vecindad incluso sin GUAs en el enlace (las link-locals bastan) — y, a diferencia de OSPFv2, no exigen estar en la misma subred global para la adyacencia. En la práctica diseñarás los enlaces con sus /64 o /127 igualmente.
4. La default en IPv6
El mismo patrón del borde (lección 7.4), con la sintaxis del Módulo 6:
R1(config)# ipv6 route ::/0 2001:db8:acad:ff::1
R1(config)# ipv6 router ospf 1
R1(config-rtr)# default-information originate
El interior la recibe como OE2 ::/0.
Verificación: los mismos comandos, con ipv6 delante
R1# show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
2.2.2.2 1 FULL/DR 00:00:33 4 Gi0/1
R1# show ipv6 ospf interface Gi0/1 ← área, tipo de red, coste, link-local usada
R1# show ipv6 route ospf
O 2001:DB8:ACAD:2::/64 [110/2]
via FE80::2, GigabitEthernet0/1
OE2 ::/0 [110/1], tag 1
via FE80::2, GigabitEthernet0/1
R1# show ipv6 ospf database ← la LSDB v3
R1# show ipv6 protocols ← proceso, RID, interfaces participantes
El flujo de diagnóstico es el de la 7.4 — vecinos → database → rutas → coste — con los prefijos de comando en ipv6. Y el checklist de vecindad pierde un punto (la subred común ya no es requisito) pero gana otro: ¿ipv6 unicast-routing está activo? — sin él no hay OSPFv3 que valga (lección 6.4).
Dual stack: dos OSPF en paralelo
En una red dual stack conviven dos procesos independientes: OSPFv2 para IPv4 y OSPFv3 para IPv6 — dos LSDBs, dos SPF, dos conjuntos de vecindades sobre los mismos cables. La independencia de pilas de la lección 6.4, aplicada al routing: un fallo en las vecindades v3 no toca a v2 (y viceversa), y ambas se diagnostican por separado. Mantén los RIDs iguales en ambos procesos (1.1.1.1 en v2 y v3 para R1): no es obligatorio, pero convierte cualquier salida de diagnóstico en un texto coherente.
Relación con otros conceptos
- Toda la mecánica viene de 7.3-7.4; esta lección solo cambia el transporte y la sintaxis.
- Las link-locals protagonistas (origen de Hellos, identidad de vecinos, next-hops) son las del Módulo 6 — y las manuales
fe80::1/fe80::2de la lección 6.4 rinden aquí su dividendo. - ff02::5 y ff02::6 amplían el catálogo multicast de la lección 6.1.
- La default
::/0inyectada se apoya en las estáticas IPv6 de la 7.2.
Resumen
OSPFv3 = el OSPF que ya sabes, sobre IPv6: mismos estados, DR/BDR, coste, áreas y AD 110. Los cambios: RID manual obligado en routers solo-IPv6 (sigue siendo formato IPv4), configuración exclusivamente por interfaz (ipv6 router ospf 1 + ipv6 ospf 1 area 0 — network ya no existe), y todo sobre link-local: Hellos a ff02::5/ff02::6, vecinos identificados por su fe80:: y next-hops link-local en las rutas (sin exigir subred global común). Default al dominio con default-information originate (OE2 ::/0). En dual stack, OSPFv2 y OSPFv3 corren en paralelo e independientes — RIDs iguales por legibilidad, diagnósticos separados por definición, y ipv6 unicast-routing como prerrequisito de todo.