Troubleshooting OSPF

El protocolo de enrutamiento dinámico Open Shortest Path First (OSPF) es un protocolo de

enrutamiento de estado de enlace que utiliza el algoritmo de ruta más corta (SPF) de Dijkstra. Es un
protocolo de enrutamiento extremadamente escalable debido a su implementación de diseño
jerárquico. OSPF puede enrutar para los protocolos IPv4 e IPv6. Este capítulo se centra en la
resolución de problemas de OSPFv2 y OSPFv3 utilizando las configuraciones clásicas y las
configuraciones más recientes de la familia de direcciones OSPF.

Antes de que se puedan intercambiar rutas entre los enrutadores OSPF en la misma LAN o en una
WAN, se debe formar una relación de vecino OSPF. Hay muchas razones por las cuales no se formará
una relación de vecindad, y como solucionador de problemas, necesita estar al tanto de ellas. Este
capítulo profundiza en estas razones y le brinda las herramientas necesarias para identificarlas y
resolver problemas de vecinos con éxito.

Una vez que se formen las relaciones de vecinos, los enrutadores vecinos intercambiarán OSPF LSA,
que contienen información sobre las rutas. En varios casos, las rutas pueden terminar
desaparecidas, y debe poder determinar por qué faltan las rutas. Este capítulo analiza las diversas
formas en que las rutas OSPF podrían perderse, cómo puede identificar las razones por las que faltan
y cómo puede resolver los problemas relacionados con las rutas.

Troubleshooting OSPFv2

OSPF establece relaciones vecinas enviando paquetes de saludo (hello packets) a las interfaces que
participan en el proceso OSPF. Para habilitar el proceso OSPF en una interfaz y colocarlo en un área
OSPF, use el comando network ip_address wildcard_mask area area_id en el modo de configuración
OSPF del enrutador o el comando ip ospf process_id area area_id en el modo de configuración. Por
ejemplo, el siguiente comando network area habilita OSPF en todas las interfaces con una dirección
IP de 10.1.1.0 a 10.1.1.255 y las coloca en el área 0: red 10.1.1.0 0.0.0.255 área 0. El siguiente
comando de configuración de interfaz habilita el proceso OSPF en la interfaz y lo coloca en el área
51: ip ospf 1 área 51. Debido a que hay dos formas diferentes de habilitar OSPFv2 en una interfaz,
debe tener mucho cuidado al solucionar las adyacencias vecinas para que no se lo lleve por el
camino equivocado, pensando que el proceso OSPF no estaba habilitado en una interfaz cuando en
realidad lo era. Esta es su advertencia para verificar ambos lugares.

Los enrutadores OSPF recibirán LSA de cada enrutador dentro de la misma área, lo que significa que
aprenden acerca de las rutas directamente desde la fuente dentro de la misma área. Como
resultado, es necesario que los LSA se inunden en el área. Esto es obligatorio porque cada enrutador
en un área debe tener el mismo LSDB exacto para esa área. Esto hace que la resolución de problemas
de rutas OSPF que faltan sea más difícil que los protocolos de enrutamiento vector distancia porque
es más difícil seguir la ruta, especialmente en un dominio OSPF de áreas múltiples.

Troubleshooting OSPFv2 Adyacencias vecinas

Para verificar los vecinos OSPFv2, use el comando show ip ospf neighbor. En el ejemplo 15-1, verá
una salida de muestra del comando show ip ospf neighbor. Enumera la ID del vecino, que es la ID
del enrutador (RID) (router ID ) del vecino, la prioridad del vecino para el proceso de elección del
enrutador designado (designated router) / enrutador designado como respaldo (backup designated
router) (DR / BDR), el estado del vecino (en pocas palabras) y si son un DR, BDR u otro. Además,
muestra el tiempo muerto, que es cuánto tiempo esperará el enrutador local hasta que declare que
el vecino está inactivo si no escucha otro paquete de saludo dentro de ese tiempo (el valor
predeterminado es 40 segundos en una LAN). También puede ver la dirección IP de la interfaz del
vecino desde la que enviaron el paquete de saludo y la interfaz del enrutador local que se utiliza
para llegar a ese vecino.

Cuando una adyacencia de vecinos OSPF se forma exitosamente, recibirá un mensaje de syslog
similar al siguiente:

%OSPF-5-ADJCHG: Process 1, Nbr 10.1.23.2 on GigabitEthernet1/0 from LOADING to FULL,

Loading Done

Aquí hay una lista de razones por las cuales una relación de vecino OSPFv2 podría no formarse:

 La interfaz está fuera de servicio (Interface is down): la interfaz tiene que estar arriba /
arriba (up/up).
 Interfaz que no ejecuta (not running) el proceso OSPF: si la interfaz no está habilitada para
OSPF, no enviará paquetes de saludo ni formará una adyacencia.
 Temporizadores no coincidentes (Mismatched timers): los temporizadores de saludo y
muertos tienen que coincidir entre vecinos.
 Números de área no coincidentes (Mismatched area numbers): ambos extremos de un
enlace deben estar en la misma área OSPF.
 Tipo de área no coincidente (Mismatched area type): además de un tipo de área OSPF
normal, un tipo de área podría ser stub or not-so-stubby area (NSSA). Los routers deben
ponerse de acuerdo sobre el tipo de área en la que se encuentran.
 Diferentes subredes: los vecinos deben estar en la misma subred.
 Interfaz pasiva (Passive interface): la función de interfaz pasiva suprime el envío y la
recepción de paquetes de saludo al mismo tiempo que permite publicitar la red de
interfaces.
 Información de autenticación no coincidente (Mismatched authentication information):
si una interfaz OSPF está configurada para autenticación, la interfaz OSPF en el otro extremo
del enlace debe configurarse con información de autenticación coincidente.
 ACL: una ACL que niega paquetes a la dirección de multidifusión OSPF 224.0.0.5.
  MTU no coinciden (MTU mismatch): la unidad de transmisión máxima de las interfaces
vecinas debe coincidir.
 Tipos de red no coincidentes (Mismatched network types): según las características de tipo
de red OSPF y los valores predeterminados, es posible que dos vecinos configurados con un
tipo de red OSPF diferente no formen una adyacencia.

Las adyacencias no se establecen con la recepción inmediata de mensajes de saludo. Por el

contrario, una adyacencia transiciones a través de múltiples estados, se describe en la Tabla
siguiente:

Estado Descripción
Down Este estado indica que no se han recibido hellos de un vecino.
Attempt Este estado ocurre después de que un enrutador envía un hello de unidifusión
(unicast) (a diferencia de un saludo de multidifusión (multicast)) a un vecino
configurado y aún no ha recibido un saludo de ese vecino.
Init Este estado ocurre en un enrutador que ha recibido un mensaje de saludo de su
vecino; sin embargo, el RID de OSPF del enrutador de recepción no estaba incluido
en el mensaje de saludo. Si un enrutador permanece en este estado durante un
período prolongado, es probable que algo impida que ese enrutador reciba
correctamente los paquetes de saludo del enrutador vecino.
2Way Este estado ocurre cuando dos enrutadores OSPF han recibido mensajes hello entre
sí, y cada enrutador vio su propio RID OSPF en el mensaje hola que recibió. El estado
de 2 vías es un estado aceptable para permanecer entre DROthers en una LAN
Ethernet.
Exstart Este estado ocurre cuando los enrutadores que forman una adyacencia de vecinos
contiguos deciden quién enviará primero su información de enrutamiento. Esto se
logra usando el RID. El enrutador con el RID más alto se convierte en el maestro y el
otro se convierte en el esclavo. El maestro enviará la información de enrutamiento
primero. En una red de accesos múltiples, primero deben determinarse DR y BDR
antes de que comience este estado. Sin embargo, el DR no tiene que ser el maestro
porque cada elección de maestro / esclavo es por vecino. Si un enrutador permanece
en este estado durante un período prolongado, podría existir una discrepancia
máxima en la unidad de transmisión (MTU) (Maximum Transmission Unit) entre los
enrutadores vecinos, o podría existir un RID OSPF duplicado.
Exchange Este estado ocurre cuando los dos enrutadores que forman una adyacencia se envían
uno a otro paquete de descriptor de base de datos (DBD) (database descriptor) que
contienen información sobre la base de datos de un estado de enlace de un
enrutador. Cada enrutador compara los paquetes DBD recibidos del otro enrutador
para identificar las entradas faltantes en su propia base de datos. Si un enrutador
permanece en este estado durante un período prolongado, podría existir una falta de
coincidencia de MTU entre los enrutadores vecinos.
Loading En función de las entradas de base de datos de estado (link-state database) de enlace
que faltan identificadas en el estado de intercambio, el estado de carga (Loading
state) se produce cuando cada enrutador vecino solicita al otro enrutador que envíe
esas entradas faltantes. Si un enrutador permanece en este estado durante un
período prolongado, es posible que se haya dañado un paquete o que un enrutador
tenga problemas de memoria. Alternativamente, es posible que una condición de
 este tipo pueda resultar de los enrutadores vecinos que tienen una falta de
coincidencia MTU.
Full Este estado indica que los enrutadores OSPF vecinos han intercambiado con éxito su
información de estado de enlace entre sí, y se ha formado una adyacencia.

Cuando no se forma una relación de vecino OSPF, el vecino no aparece en la tabla contigua. Por lo
tanto, necesitará la asistencia de un diagrama de red preciso y el comando show cdp neighbors para
verificar quiénes deberían ser los vecinos.

Al resolver problemas de adyacencias OSPF, debe conocer cómo verificar los parámetros asociados
con cada uno de los motivos enumerados anteriormente. Veámoslos individualmente.

La interfaz está abajo (Interface Is Down)

La interfaz debe estar activa si planea formar una adyacencia de vecinos OSPF. Como ya hemos
visto, podemos verificar el estado de una interfaz con el comando show ip interface brief.

La interfaz no ejecuta el proceso OSPF

Si el modo de configuración de OSPF del router en modo network ip_address wildcard_mask area
area_id o el comando ip ospf process_id area area_id de la interfaz no está configurado
correctamente, OSPF puede no estar habilitado en las interfaces adecuadas. Como resultado, los
paquetes de saludo (hello packets) no se enviarán y las relaciones de vecinos no se formarán.
También debe especificar el área OSPF a la que pertenece la interfaz. Por lo tanto, si el comando es
correcto, excepto la ID del área, la interfaz está participando en el proceso OSPF pero en el área
incorrecta. Esto evitará que se forme una relación de vecino también. Puede verificar qué interfaces
están participando en el proceso OSPF con el comando show ip ospf interface brief, como se
muestra en el Ejemplo 15-2. En este ejemplo, dos interfaces están participando en el proceso 1 de
OSPF. Ambas están en el área 1 y son las interfaces de enrutador designadas para las redes de acceso
múltiple. También puede verificar la dirección IP y las máscaras de las interfaces junto con la
cantidad de relaciones de vecinos completos (full neighbor relationships) que se han formado a
partir de la interfaz, en comparación con el número total de vecinos fuera de la interfaz.

Recuerde que las interfaces pasivas de OSPF se muestran en esta salida.

La salida de show ip protocols muestra la network ip_addrees wildcard_mask area area_id

declarada, así como aquellas interfaces que fueron habilitadas para OSPF con el commando ip ospf
process_id area area_id. Enfóquese en el texto resaltado en el Ejemplo 15-3. Tenga en cuenta que
indica enrutamiento para redes. Esas no son las redes por las que estamos enrutando. Estamos
enrutando para las redes asociadas con las interfaces OSPF se habilitará en función de la declaración
del área de la red. En este caso, 10.1.1.1 0.0.0.0 área 1 realmente significa la red 10.1.1.1 0.0.0.0
área 1. Por lo tanto, la interfaz con esta dirección IP se habilitará para el proceso OSPF y se colocará
en el área 1. Además, puede ver qué interfaces se configuraron explícitamente para participar en el
proceso OSPF con el comando ip ospf process_id area area_id. En este ejemplo, es Gigabit Ethernet
1/0 que se habilitó para OSPF con el comando ip ospf 1 area 1 y Gigabit Ethernet 0/0 se habilitó
para OSPF con la red 10.1.1.1 0.0.0.0 area 1 router Modo de configuración OSPF.

Como puede ver, la declaración del área de red es extremadamente importante, al igual que el
comando ip ospf area. Si se configura mal, las interfaces que deberían participar en el proceso OSPF
podrían no funcionar, y las interfaces que no deberían participar en el proceso OSPF podrían serlo.
Además, es posible que participen pero en el área incorrecta, lo que hace que las relaciones vecinas
no se formen. Por lo tanto, debería ser capaz de reconocer problemas relacionados con estos dos
comandos.

Si se habilita una interfaz para OSPF con ambos comandos de network area y ip ospf area, el
comando ip ospf area tendrá prioridad.

Temporizadores no coincidentes (Mismatched Timers)

A diferencia del protocolo de enrutamiento de puerta de enlace interior mejorado (EIGRP) (Gateway
Routing Protocol), los temporizadores OSPF tienen que coincidir entre vecinos para formar una
adyacencia contigua. El temporizador hello (hello timer) tiene un valor predeterminado de 10
segundos para los tipos de red de difusión (broadcast) y de punto a punto (point-to-point ) y de 30
segundos para los tipos de red no de difusión (nonbroadcast) y de punto a multipunto (point-to-
multipoint). El temporizador inactivo (dead timer) tiene un valor predeterminado de 40 segundos
para los tipos de red de difusión (broadcast) y de punto a punto (point-to-point) y de 120 segundos
para los tipos de red no de difusión (nonbroadcast) y de punto a multipunto (point-to-multipoint).
Para verificar los temporizadores actuales (current timers) asociados con una interfaz OSPF, emita
el comando show ip ospf interface interface_type interface_number, como se muestra en el
Ejemplo 15-4. En este ejemplo, Gigabit Ethernet 1/0 está utilizando los temporizadores
predeterminados de 10 y 40. Al determinar si los temporizadores coinciden, utilice el método de
detectar la diferencia entre las salidas en ambos enrutadores.

Usar el comando debug ip ospf hello cuando la solución de problemas de adyacencias revele
temporizadores que no coinciden, como se muestra en el Ejemplo 15-5. En este ejemplo, el paquete
recibido (R) tiene un dead de 44 y un hola de 11. El dispositivo local (C) tiene un dead de 40 y un
hola de 10.
Números de área no coincidentes

OSPF utiliza el concepto de áreas para que sea un protocolo de enrutamiento dinámico
extremadamente escalable. Para que los enrutadores OSPF formen una adyacencia contigua, sus
interfaces vecinas deben estar en la misma área. Puede verificar el área de la que forma parte una
interfaz OSPF utilizando el comando show ip ospf interface interface_type interface_number, como
se muestra en el Ejemplo 15-6, o el comando show ip ospf interface brief, como se muestra en el
Ejemplo 15-7. Al determinar si las ID de área coinciden, use el método de detectar el punto entre
las salidas (spot-the-difference) en ambos enrutadores.
El uso del comando debug ip ospf adj cuando la resolución de problemas de adyacencias revelará
números de área no coincidentes, como se muestra en el Ejemplo 15-8. En este ejemplo, el paquete
recibido tiene una ID de área de 1 y la interfaz local está participando en el área 2.
Tipo de área no coincidente (Mismatched Area Type)
El tipo de área de OSPF predeterminado se clasifica como un área normal. Sin embargo, puede
convertir un área normal en un área de conexión o área de NSSA para controlar los tipos de LSA que
se enviarán al área desde un Enrutador de borde de área (ABR). Para que los enrutadores dentro de
un área formen adyacencias, deben acordar el tipo de área. Dentro del paquete de saludo (hello
packet), hay un indicador de área de stub que está diseñado para indicar el tipo de área en la que
se encuentra el vecino. Puede verificar los tipos de áreas conectadas al enrutador con el comando
show ip protocols. Sin embargo, no te dice qué área es de qué tipo. En el ejemplo 15-9, que muestra
el resultado de los protocolos de show ip, solo hay un área (área 1); por lo tanto, puede deducir que
es el área de stub. Sin embargo, si hay un enrutador con múltiples áreas conectadas, verificará las
áreas y su tipo usando el comando show ip ospf, como se muestra en el Ejemplo 15-9. En este
ejemplo, cualquier interfaz en el área 1 está en un área de stub.
Utilizando el comando debug ip ospf hello cuando la solución de problemas de adyacencias
revelará tipos de área no coincidentes, como se muestra en el Ejemplo 15-10. En este ejemplo,
indica que el paquete recibido tiene un bit de opción de área Stub / Transit no coincidente.

Diferentes subredes
Para formar una adyacencia de vecinos OSPF, las interfaces del enrutador deben estar en la misma
subred. Puedes verificar esto de muchas maneras. Lo más simple es mirar la configuración de la
interfaz en la configuración en ejecución con el comando show run interface interface_type
interface_number. El ejemplo 15-11 muestra la configuración de Gig1 / 0 en R1 y Gig0 / 0 en R2.
¿Están en la misma subred? ¡Sí! Según la dirección IP y la máscara de subred, ambos estarían en la
subred 10.1.12.0/24.
Interfaz Pasiva

La función de interfaz pasiva es imprescindible para todas las organizaciones. Hace dos cosas: 1)
reduce el tráfico relacionado con OSPF en una red; 2) mejora la seguridad de OSPF.

La función de interfaz pasiva desactiva el envío y la recepción de paquetes OSPF en una interfaz al
tiempo que permite que la ID de red de las interfaces se inyecte en el proceso OSPF y se anuncie a
otros vecinos OSPF. Esto garantiza que los enrutadores deshonestos que se conectan a la red no
podrán formar una adyacencia con su enrutador legítimo en esa interfaz, ya que no está enviando
o recibiendo paquetes OSPF en la interfaz. Sin embargo, si configura la interfaz incorrecta como
pasiva, no se formará una relación de vecino OSPF legítima. Como se muestra en la salida show ip
protocols del Ejemplo 15-12, Gigabit Ethernet 0/0 es una interfaz pasiva. Si no hay interfaces
pasivas, esta sección no aparecerá en la salida de los show ip protocols.

Información de autenticación no coincidente (Mismatched Authentication

Information)

La autenticación se utiliza para garantizar que los enrutadores OSPF solo formen relaciones vecinas
con enrutadores legítimos y que solo acepten paquetes OSPF de enrutadores legítimos. Por lo tanto,
si se implementa la autenticación, ambos enrutadores deben acordar las configuraciones para que
se forme una relación vecina. Con la autenticación, puede usar el método de detectar la diferencia
(spot-the-difference) al resolver problemas. OSPF admite tres tipos de autenticación:
  Nulo (Null): conocido como tipo 0 y significa que no hay autenticación
 Texto sin formato (Plain text): conocido como tipo 1 y envía credenciales en texto claro
 MD5: conocido como tipo 2 y envía un hash

La autenticación OSPF puede habilitarse interfaz por interfaz o para todas las interfaces en el área
al mismo tiempo. Saber qué comandos usar para verificar estas diferentes opciones de
configuración de autenticación es importante. Para verificar si la autenticación se ha habilitado para
toda el área en el enrutador, use el comando show ip ospf, como se muestra en el Ejemplo 15-13.
Sin embargo, con la autenticación de mensaje resumen (digest) 5 (MD5), aún debe verificar la
identificación de clave (key ID) que se utiliza interfaz por interfaz utilizando el comando show ip
ospf interface interface_type interface_number, como se muestra en el ejemplo 15-14. Además,
debe verificar la cadena de clave sensible (sensitive key string) que se está utilizando con el comando
show run interface interface_type interface_number.

Si configura la autenticación interfaz por interfaz, la salida de show ip ospf indicará que: Area no
tiene autenticación. Por lo tanto, debe asegurarse de comprobar también el resultado de la interfaz
con el comando show ip ospf interface.

ACLs
Las listas de control de acceso (ACL) son extremadamente poderosas. Según cómo se implementen,
determinarán qué controlan en su red. Si se aplica una ACL a una interfaz y la ACL no permite
paquetes OSPF, no se formará una relación de vecinos. Para determinar si una ACL se aplica a una
interfaz, use el comando show ip interface interface_type interface_number, como se muestra en
el Ejemplo 15-16. Observe que ACL 100 se aplica entrante en la interfaz Gig1 / 0. Para verificar las
entradas de la ACL 100, ejecute el comando show access-list 100, como se muestra en el Ejemplo
15-17. En este caso, puede ver que la ACL 100 niega (denying) el tráfico OSPF, lo que evitaría que se
forme una relación de vecinos.

MTU no coincide (MTU Mismatch)

Para que los enrutadores OSPF se conviertan en vecinos y alcancen el estado de adyacencia
completo, la interfaz de cada enrutador que forma la adyacencia debe tener exactamente la misma
MTU. De lo contrario, los enrutadores se verán entre sí pero se quedarán atascados en los estados
de exstart/exchange. En el ejemplo 15-18, la salida de show ip ospf neighbor indica que R1 está
atascado en el estado Exchange y que R2 está atascado en el estado exstart.
En la salida de show ip ospf interface brief, verá la columna Nbrs F / C sin los valores esperados. En
el ejemplo 15-19, ve 0/1 en la columna Nbrs F / C, que indica que hay un vecino fuera de la interfaz
pero que no hay adyacencias completas.

Para verificar la MTU configurada en una interfaz, emita el comando show run interface interface_
type interface_number. Como se muestra en el Ejemplo 15-20, la MTU de Gigabit Ethernet 1/0 en
R1 es 1476, y como nada aparece en la configuración Gigabit Ethernet 0/0 de R2, está utilizando el
valor predeterminado de 1500.
Para resolver este problema, puede modificar manualmente los valores de MTU de las interfaces
para que coincidan, o puede usar el comando de configuración de la interfaz ip ospf mtu-ignore,
que impedirá que OSPF compare la MTU cuando intente formar una adyacencia.

ID de enrutador duplicados (Duplicate Router IDs)

Los RID deben ser únicos por muchas razones. Una de las razones es que no se formará una relación
de vecindad entre dos enrutadores si tienen el mismo RID. Cuando existe un RID duplicado, recibirá
un mensaje de syslog similar al siguiente:

%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 10.1.23.2 from 10.1.12.2 on interface

GigabitEthernet1/0

Para verificar el RID de un enrutador OSPF, use el comando show ip protocols como se muestra en
el Ejemplo 15-21. Sin embargo, casi todos los comandos show de OSPF muestran el RID en su salida
para que pueda verificarlo de todos modos. En este caso, el RID de R1 es 10.1.23.2, como se muestra
en la salida show ip protocols. Si cambia manualmente el RID con el comando router-id en el modo
de configuración OSPF del enrutador, debe restablecer el proceso OSPF con el comando clear ip
ospf process antes de que surta efecto.

Tipos de red no coincidentes (Mismatched Network Types)

OSPF admite múltiples tipos de red. Los diferentes tipos de red tienen diferentes valores
predeterminados. Por lo tanto, si dos enrutadores OSPF que intentan formar una adyacencia
adyacente se configuran con tipos de red no compatibles, no se formará una relación de vecino. La
Tabla 15-3 muestra una lista de los tipos de redes OSPF y sus características.
Para determinar el tipo de red asociado con una interfaz habilitada para OSPF, ejecute el comando
show ip ospf interface interface_type interface_number. En el ejemplo 15-22, la interfaz G1 / 0 de
R1 está utilizando la difusión de tipo de red OSPF. Utilice el método de solución de problemas de
spot-the-difference para determinar si los tipos de red no coinciden.
Solución de problemas de rutas OSPFv2

Como se discutió anteriormente, las relaciones de vecinos son la base para el intercambio de
información de OSPF. Si no tenemos vecinos, no aprenderemos ninguna ruta. Entonces, además de
la falta de un vecino, ¿cuáles serían las razones para perder rutas en una red OSPF?

A continuación se incluye una lista de algunas razones comunes sobre por qué faltan las rutas OSPF
en el LSDB o en la tabla de enrutamiento:

 Interfaz que no ejecuta (not running) el proceso OSPF: si la interfaz no está participando
en el proceso OSPF, la red de la que forma parte la interfaz no se inyectará en el proceso
OSPF y, por lo tanto, no se anunciará a los vecinos.
 Mejor fuente de información: si la misma red se aprende de una fuente más confiable, esta
se usara en lugar de la información aprendida OSPF.
 Filtrado de ruta: se puede configurar un filtro que impida la instalación de una ruta en la
tabla de enrutamiento.
  Configuración de área de stub: si se elige un tipo de área de stub incorrecto, es posible que
esté recibiendo una ruta predeterminada en lugar de la ruta real.
 La interfaz está apagada (shut down): la interfaz habilitada para OSPF debe estar up/up
para la red asociada a la interfaz que se anunciará.
 Se eligió un enrutador designado incorrecto: en un entorno de hub-and-spoke, si el
enrutador incorrecto es el DR, las rutas no se intercambiarán correctamente.
 RID duplicados: si hay dos o más enrutadores con el mismo RID, las rutas se perderán en la
topología.

Echemos un vistazo a cada uno de ellos individualmente e identifiquemos cómo podemos

reconocerlos durante el proceso de resolución de problemas.

 La interfaz no ejecuta el proceso OSPF

Como se discutió anteriormente, cuando utiliza el comando network area o el comando ip ospf
area, el proceso OSPF está habilitado en las interfaces. OSPF luego toma la red / subred de la que
forma parte la interfaz y la inyecta en la base de datos de estado de enlace (LSDB) para que pueda
anunciarse a otros enrutadores en el sistema autónomo. Por lo tanto, incluso las interfaces que no
formarán relaciones vecinas con otros enrutadores deben participar en el proceso OSPF para que
se anuncie la ID de red de las interfaces.

Como se discutió en una sección anterior, la salida de show ip protocols muestra las declaraciones
de área de red (network área) además de las interfaces que se configuraron explícitamente con el
comando ip ospf area interface. Enfóquese en el texto resaltado en el Ejemplo 15-23. Tenga en
cuenta que indica enrutamiento para redes (Routing for Networks). Esas no son las redes por las
que estamos enrutando. Estamos enrutando para las redes asociadas con la interfaz OSPF se
habilitará en función de la declaración de red. Entonces, 10.1.1.1 0.0.0.0 área 1 significa habilitar
OSPF en la interfaz con la dirección IP 10.1.1.1 y colocarla en el área 1. Luego direccionaremos hacia
la red asociada con esa interfaz. Además, puede ver que Gig1 / 0 se configuró explícitamente para
participar en el proceso OSPF; por lo tanto, OSPF dirigirá también la red asociada con esa interfaz.
Entonces, ¿para qué redes enrutamos en ese momento? Las redes asociadas con las interfaces que
ahora están habilitadas para OSPF. En el ejemplo 15-24, puede ver el resultado del comando show
ip interface en R1 para Gig0 / 0 y Gig1 / 0, que fue canalizado para incluir solo la dirección de
Internet. Tenga en cuenta que están en una red / 24. Como resultado, los ID de red serían
10.1.1.0/24 y 10.1.12.0/24. Esas son las redes por las que estamos enrutando.

 Mejor fuente de información

Para que una ruta aprendida OSPF se instale en la tabla de enrutamiento, tiene que ser la fuente de
enrutamiento más creíble. Recuerde que esto se basa en la distancia administrativa (AD). La AD de
OSPF es 110 para todas las rutas aprendidas: intra, inter y externa. Por lo tanto, si hay otra fuente
que está educando al mismo enrutador sobre la misma red y esa fuente tiene un AD mejor, la fuente
con la mejor AD gana y su información se instalará en la tabla de enrutamiento. El ejemplo 15-25
muestra solo las rutas instaladas por OSPF en el enrutador. Observe que no hay entrada OSPF para
la red 10.1.1.0/24 y 10.1.12.0/24.

En este caso, hay una mejor fuente para las redes 10.1.1.0/24 y 10.1.12.0/24. El ejemplo 15-26
muestra el resultado del comando show ip route 10.1.1.0 255.255.255.0. Identifica que esta red
está conectada directamente y tiene un AD de 0. Como una red conectada directamente tiene un
AD de 0 y una ruta OSPF tiene un DA de 110, la fuente directamente conectada se instala en la tabla
de enrutamiento.

Pero espere, es posible que se pregunte si 10.1.1.0/24 está en el LSDB, porque está directamente
conectado. Recuerde, cuando una interfaz está participando en el proceso de enrutamiento, su red
se inyectará en el LSDB como un LSA Tipo 1 (Enrutador). Puede verificar esto con el comando show
ip ospf database, como se muestra en el Ejemplo 15-27. Sin embargo, no hay listado para
10.1.1.0/24. Esto se debe a que solo estamos mirando un resumen de los LSA en el LSDB. Si desea
ver los detalles de la LSA, debe abrirlos. El ejemplo 15-28 muestra la salida de show ip ospf database
router 10.1.12.1. Este comando abre el enrutador tipo 1 LSA anunciado por el enrutador con el RID
10.1.12.1, que es R1. Muestra que 10.1.1.0/24 está en el LSDB y, por lo tanto, se puede publicitar
en el proceso OSPF.
Tener una mejor fuente de información de enrutamiento no puede hacer que los usuarios se quejen
o envíen un ticket de problema, porque probablemente aún puedan acceder a los recursos que
necesitan. Sin embargo, podría estar causando enrutamiento subóptimo en su red. Revise la Figura
15-1, que muestra una red que ejecuta dos protocolos de enrutamiento diferentes. En este caso,
¿qué ruta se usará para enviar tráfico desde PC1 a 10.1.1.0/24? Si dijiste el camino EIGRP más largo,
estás en lo correcto. Aunque es más rápido usar la ruta OSPF, EIGRP gana por defecto porque tiene
el AD más bajo y se produce un enrutamiento subóptimo.
Ser capaz de reconocer cuándo se debe utilizar una determinada fuente de enrutamiento y cuándo
no se debe utilizar es clave para optimizar su red y reducir el número de instancias de solución de
problemas relacionadas con "la red es lenta". En este caso, es posible que deseemos considerar
aumentando el AD de EIGRP o disminuyendo el AD de OSPF para optimizar el enrutamiento.

Filtrado de ruta