Dos routers, el mismo enlace roto, la misma área OSPF — y a solo un ajuste de tipo de red de una diferencia de cuarenta segundos en cuánto tarda el resto de la red en notarlo. Esto es lo que realmente ocurre dentro de la base de datos de estado de enlace según el tipo de red, un failover real de cuatro routers con la salida LSA real, y los comandos para verificar cuál está realmente en uso.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
El tipo de red normalmente se elige por razones de adyacencia — coincidencia de subred, elegibilidad de DR — pero decide en silencio de antemano qué tan rápido la red nota un enlace caído.
Dos interfaces OSPF pueden alcanzar Full usando el tipo de red Broadcast o Punto a Punto — a la adyacencia en sí no le importa cuál eligió. Lo que sí importa es el momento en que ese enlace realmente falla. En un segmento Broadcast, la falla tiene que abrirse paso a través de un Router Designado y un network-LSA que solo el DR controla. En un enlace punto a punto, no hay DR, no hay network-LSA, y nada esperando el temporizador de otro. Misma falla, mismo protocolo, dos caminos de recuperación distintos.
Esta nota trata estrictamente sobre esa brecha: qué ocurre realmente en la base de datos de estado de enlace de cada router cuando el enlace cae, un caso real de cuatro routers con la salida LSA de ambos lados de la misma falla, la sobrecarga de DR/BDR que solo cargan los segmentos broadcast, y los comandos para verificar qué tipo de red está realmente usando un segmento antes de que se convierta en la razón de que un failover tardara más de lo debido. Para el flujo de la máquina de estados de vecinos cuando una adyacencia no se forma en absoluto, vea OSPF Neighbor Troubleshooting; para dónde difieren los valores predeterminados de tipo de red y el comportamiento DR/BDR entre fabricantes, vea la nota Huawei-Cisco OSPF Interop.
Mismo evento físico, misma área OSPF — el diagrama de abajo muestra lo que cada router realmente tiene que hacer, y cuánto tiempo tarda.
Broadcast arriba, Punto a Punto abajo. La estructura DR/BDR que introduce broadcast es exactamente la parte de la línea de tiempo que el punto a punto omite por completo.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
La diferencia no está en si un router nota una falla — está en qué estructuras deben cambiar antes de que el resto de la red pueda actuar en consecuencia.
En un enlace punto a punto, los dos routers conectados solo intercambian router-LSA, y cada uno lleva una entrada de enlace que describe al vecino directamente — más una entrada stub-network separada para la interfaz misma. Esa entrada que describe al vecino solo existe mientras la adyacencia esté realmente en Full. En el momento en que la interfaz cae, el router que la posee deja de llevar esa entrada en su siguiente router-LSA. No hace falta que nada más cambie antes.
En un segmento broadcast, la misma falla física debe reflejarse en dos estructuras separadas: el propio router-LSA de cada router (una entrada Transit Network que apunta al DR del segmento), y un network-LSA separado que solo origina el DR, listando cada router adjunto que aún se considera Full. Un router no-DR que pierde su enlace puede actualizar su propio router-LSA de inmediato y recalcular sus propias rutas rápido. Pero el network-LSA — y la propia entrada del router-LSA del DR para ese segmento — no cambian hasta que el DR mismo note que el vecino desapareció, lo que en un segmento compartido significa esperar a que expire su propio temporizador dead para ese vecino, no a que caiga la interfaz.
<Huawei> display ospf lsdb router
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 2.2.2.2 2.2.2.2 12 48 8000001C 0
// P2P: this router-LSA carries the neighbor link only while the adjacency is Full
<Huawei> display ospf lsdb network
Type LinkState ID AdvRouter Age Len Sequence Metric
Network 1.1.24.4 4.4.4.4 23 32 80000001 0
// Broadcast only: originated solely by the DR -- absent entirely on a P2P segmentLa elección de DR/BDR existe para impedir que cada router de un segmento de acceso múltiple forme una malla completa de adyacencias con cada otro router presente — en su lugar, todos forman adyacencia solo con el DR y el BDR. Eso es una ganancia real de eficiencia cuando un segmento realmente tiene varios routers. Pero también significa que la propia existencia del segmento en la base de datos de estado de enlace ahora depende del punto de vista de un router específico: mientras el DR mismo no haya declarado muerto a un vecino, el resto de la red debe asumir que la topología del segmento no ha cambiado, aunque el enlace de un router adjunto hacia él claramente sí lo haya hecho. Un enlace punto a punto se salta esto por completo — no hay DR, nada que elegir, y nada que deba esperar el temporizador de un tercero antes de que el resto de la red pueda confiar en la actualización.
<Huawei> display ospf interface GigabitEthernet1/0/0
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
1.1.24.4 Broadcast DR 1 1 1.1.24.4 1.1.24.2
// forcing point-to-point removes DR/BDR from the picture entirely
[Huawei-GigabitEthernet1/0/0] ospf network-type p2pSÍNTOMAUn enlace que en realidad es solo dos routers en un segmento dedicado igual tarda el camino largo en reconverger tras una falla, como si fuera una gran LAN de acceso múltiple.
CAUSAEl tipo de red por defecto en las interfaces Ethernet es Broadcast, sin importar cuántos routers realmente compartan el segmento. Un segmento con exactamente dos routers igual elige un DR y un BDR, igual construye un network-LSA, y la eliminación de ese network-LSA igual queda condicionada al propio temporizador dead del DR — aunque nunca hubo un tercer router que necesitara el mecanismo DR/BDR en primer lugar.
SOLUCIÓNSi un segmento está dedicado exactamente a dos routers y siempre lo estará, configure deliberadamente ambos extremos en punto a punto con ospf network-type p2p, en lugar de aceptar el broadcast por defecto por omisión.
SÍNTOMALa convergencia se ve asimétrica — el router que realmente perdió el enlace recalcula rutas casi de inmediato, pero el resto de la red no reconverge por completo hasta aproximadamente un intervalo de temporizador dead después.
CAUSACuando el enlace que falla pertenece a un router no-DR, ese router actualiza su propio router-LSA de inmediato. Pero el network-LSA del segmento solo lo origina el DR, y el DR no sabe que el vecino desapareció hasta que expira su propio temporizador dead para ese vecino — no está vigilando la interfaz que falló, está vigilando la adyacencia que mantiene con ese vecino.
SOLUCIÓNAntes de tratar una reconvergencia que parece atascada como una falla, verifique cuál router es el DR del segmento afectado con display ospf interface — si es el propio temporizador dead del DR agotándose, eso es comportamiento esperado de un segmento broadcast, no un error.
SÍNTOMATras cambiar un enlace al tipo de red punto a punto, alguien revisa la LSDB esperando los mismos tipos de LSA que antes, y asume que algo está roto porque el network-LSA de ese segmento simplemente desapareció.
CAUSAUn router-LSA P2P igual lleva una entrada de enlace que describe al vecino — solo que lo hace directamente, como parte del propio router-LSA de cada router, en lugar de a través de un network-LSA compartido. Nunca hubo un network-LSA separado que buscar una vez que el enlace es P2P.
SOLUCIÓNVerifique display ospf lsdb en ambos extremos — espere dos entradas de tipo Router con enlaces de estilo punto a punto, y confirme que no haya entrada de tipo Network para ese segmento; esa ausencia es correcta para P2P, no un síntoma de problema.
SÍNTOMAEn el momento en que se aplica ospf network-type p2p en un extremo, la relación de vecino cae de inmediato, aunque nada haya cambiado físicamente en el enlace en sí.
CAUSAEl tipo de red es uno de los parámetros que deben coincidir entre dos vecinos OSPF para que la adyacencia se mantenga en absoluto. Cambiarlo en un lado sin el otro crea una discrepancia inmediata, y aunque se cambien ambos lados juntos, se fuerza a la máquina de estados a reiniciar, ya que el estatus DR/BDR y los tipos de LSA involucrados cambian al mismo tiempo.
SOLUCIÓNAplique el cambio en ambos extremos dentro de la misma ventana de mantenimiento, y reverifique con display ospf interface y display ospf peer verbose inmediatamente después.
SÍNTOMATras un failover, una actualización de LSA esperada nunca aparece en la propia LSDB de un vecino, y parece que el propio mecanismo de convergencia falló.
CAUSAEl comando ospf filter-lsa-out (all / summary / ase / nssa) es una optimización legítima para reducir inundaciones de LSA innecesarias en una interfaz de salida específica — a menudo desplegada deliberadamente para reducir el tamaño de la LSDB y mejorar la velocidad de convergencia cuando existen varios enlaces paralelos entre dos routers. Si alguien lo configuró antes y se olvidó, un tipo de LSA filtrado que simplemente nunca llega se ve exactamente igual a una convergencia atascada.
SOLUCIÓNAntes de tratar una actualización de LSA faltante como una falla, verifique display current-configuration interface en busca de una instrucción ospf filter-lsa-out en la interfaz en cuestión.
La misma prueba física, realizada dos veces — una con el tipo de red por defecto, otra forzada a punto a punto — hace que la diferencia sea concreta en lugar de teórica.
La red: cuatro routers ejecutando OSPF area 0. SW2 y SW4 comparten un segmento, con SW4 actuando como DR. El tráfico normal entre SW2 y una loopback en SW4 (4.4.4.4) transita por un tercer router, SW3. La prueba: mantener un ping continuo de SW2 a 4.4.4.4, luego desconectar físicamente el enlace de SW2 a SW4, y observar qué hacen realmente las LSA propias de cada router según el tipo de red.
Con el enlace SW2–SW4 dejado en su tipo de red broadcast por defecto, desconectarlo no libera la adyacencia de inmediato. SW2 se da cuenta enseguida y vuelve a emitir su propio router-LSA sin la red compartida, luego recalcula sus propias rutas rápido. El router-LSA de SW4 y su network-LSA para ese segmento aún no cambian — SW4 sigue contando hacia atrás su propio temporizador dead para el vecino que perdió. La siguiente salida de show ip ospf nei se capturó a mitad de la cuenta regresiva, antes de que el temporizador se agotara:
SW4#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:37 1.1.24.2 GigabitEthernet0/24
1.1.1.1 1 FULL/DR 00:00:39 1.1.14.1 GigabitEthernet0/1
// remaining dead-time counting down out of a 40-second interval -- the wait is real, not a display artifact
SW4#show ip ospf database network self-originate
OSPF Router with ID (4.4.4.4) (Process ID 100)
Net Link States (Area 0)
Link State ID: 1.1.24.4 (address of Designated Router)
Attached Router: 4.4.4.4
Attached Router: 2.2.2.2
// still lists SW2 as attached -- SW4 hasn't yet noticed the neighbor is gone
// once SW4's dead timer actually expires:
*Mar 1 01:18:54.681: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on GigabitEthernet0/24
from FULL to DOWN, Neighbor Down: Dead timer expired
SW4#show ip ospf database router self-originate
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.24.0
// the segment only flips from Transit to Stub -- and the network-lsa is only withdrawn -- once the dead timer runs outCambiar ese mismo enlace SW2–SW4 al tipo de red punto a punto cambia el resultado, no solo el tiempo. En un enlace P2P no hay relación DR/BDR ni ninguna capa de network-LSA que esperar en absoluto. SW2 deja de anunciar el enlace en el instante en que su propia interfaz cae; SW4 hace lo mismo en el momento en que se rompe su relación de vecino, porque un router-LSA P2P solo lleva la entrada de enlace que describe al vecino mientras la adyacencia está realmente en Full. Ningún lado se queda esperando el temporizador dead del otro para que la red reconverja por completo — toda la espera visible en la traza broadcast anterior simplemente no existe en punto a punto.
La lección práctica no es «P2P siempre es mejor» — un enlace P2P de todos modos no puede servir a un segmento con tres o más routers. Es que el tipo de red no es solo un detalle de configuración decidido al momento de formar la adyacencia: decide de antemano cómo se propaga realmente una falla por la base de datos de estado de enlace, y vale la pena configurarlo deliberadamente — con display ospf interface confirmado en ambos extremos — en lugar de descubrirlo por accidente durante una interrupción cuando la velocidad de convergencia realmente importa.
Esta nota se basa en un caso real de convergencia OSPF de cuatro routers, usando la salida show original del material fuente, más la mecánica estándar de LSA Broadcast/P2P descrita en la propia referencia de filtrado de LSA OSPF de Huawei. No cubre los tipos de red NBMA o P2MP, OSPFv3, detección de fallas acelerada por BFD, ni cómo estos números cambian en un segmento asegurado con autenticación — cada uno merece una mirada aparte.
Las preguntas que surgen cada vez que esta brecha de convergencia está realmente sobre la mesa.
No a la selección de ruta en condiciones normales — el costo se fija independientemente del tipo de red. Lo que cambia es enteramente sobre la ruta de falla: qué estructuras LSA deben reconstruirse, y el temporizador de quién espera el resto de la red cuando el enlace realmente falla.
La espera está ligada al router que actúa como DR de ese segmento, porque solo el DR origina el network-LSA. Si el lado que falla es DR-Other en ambos extremos, el DR del segmento es un tercer router que tiene que notar la pérdida del vecino a través de su propio temporizador dead — el mecanismo es el mismo, solo que condicionado por el temporizador de otro router, no necesariamente el que físicamente falló.
Solo si el router que se va es el propio DR o BDR. Si falla el enlace de un router que no es DR ni BDR, no hay reelección en absoluto — el DR y el BDR existentes simplemente actualizan el network-LSA para eliminar a ese router una vez que expira su propio temporizador dead. La reelección solo ocurre cuando el propio DR o BDR es el que cae.
No — punto a punto es específicamente para un enlace que conecta exactamente dos routers sin ningún otro vecino compartiendo ese segmento. Una LAN de acceso múltiple con tres o más routers OSPF debe usar Broadcast (o NBMA), porque punto a punto no tiene ningún mecanismo para más de un vecino por interfaz.
Esta nota asume que la adyacencia ya funciona y trata sobre qué le pasa a una adyacencia funcional cuando su enlace falla. Para el flujo completo de diagnóstico de la máquina de estados — de Down a Init, 2-Way, ExStart, Exchange, Loading hasta Full — vea OSPF Neighbor Troubleshooting.
Envíenos la salida de display ospf interface de ambos extremos — le diremos qué le pasa a ese segmento en cuanto el enlace cae.