Una red construida desde cero, no una red ya averiada — ID de router y direccionamiento de interfaces, activar OSPF en una única Area 0, y luego crecer hacia un backbone más un área stub con un ABR a medida que la red se expande, prioridad DR en segmentos compartidos, y los comandos de verificación que confirman cada etapa antes de añadir la siguiente.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
La mayoría de los contenidos sobre OSPF suponen que OSPF ya está funcionando y que algo falla. Esta nota no supone ninguna de las dos cosas — un núcleo enrutado que aún no existe, planificado y construido área por área.
Un despliegue de OSPF tampoco suele empezar su vida como una única área plana. Empieza siendo un router, luego dos, luego una ruta redundante entre dos edificios, luego una sucursal que no debería ver todas las rutas de la sede. Configurar OSPF correctamente en cada una de estas etapas — no solo lograr que una relación de vecindad se establezca una vez y esperar que se mantenga — es un problema distinto a resolver uno que ya existe.
Esta nota comienza con la red OSPF funcional más pequeña: dos routers, un área, compartiendo rutas. Luego amplía el mismo diseño a dos áreas — una Area 0 de backbone y una Area 1 stub en el borde de la red, el punto al que realmente deben llegar la mayoría de los diseños OSPF empresariales. Si una relación de vecindad se niega a establecerse en su propia red, nuestra nota de resolución de problemas de la máquina de estados de vecinos OSPF trata eso por separado; si los dos extremos son de proveedores distintos, consulte nuestra nota de interoperabilidad OSPF Huawei-Cisco para los problemas de DR/BDR y temporizadores propios de esa combinación.
Primero consolide una única Area 0 por sí sola — luego extienda un área stub desde el único router que toca ambas.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Direccionamiento etapa 1 — Área 0 única
| Router / Interfaz | Dirección IP | Área OSPF |
|---|---|---|
| RouterA — Vlanif10 | 192.168.1.1/24 | Área 0.0.0.0 |
| RouterA — GigabitEthernet3/0/0 | 192.168.0.1/24 | Área 0.0.0.0 |
| RouterA — LoopBack0 (Router ID) | 1.1.1.1/32 | Solo ID de router |
| RouterB — Vlanif20 | 192.168.2.1/24 | Área 0.0.0.0 |
| RouterB — GigabitEthernet3/0/0 | 192.168.0.2/24 | Área 0.0.0.0 |
| RouterB — LoopBack0 (Router ID) | 2.2.2.2/32 | Solo ID de router |
Direccionamiento etapa 2 — Añadiendo el Área 1 como área stub
| Router / Interfaz | Dirección IP | Área OSPF |
|---|---|---|
| RouterA — GigabitEthernet1/0/0 | 192.168.2.1/24 | Fuera de OSPF — importada mediante import-route direct |
| RouterA — GigabitEthernet2/0/0 | 192.168.0.1/24 | Área 0.0.0.0 |
| RouterB (ABR) — GigabitEthernet2/0/0 | 192.168.0.2/24 | Área 0.0.0.0 |
| RouterB (ABR) — GigabitEthernet1/0/0 | 192.168.1.2/24 | Área 0.0.0.1 — stub |
| RouterC — GigabitEthernet1/0/0 | 192.168.1.1/24 | Área 0.0.0.1 — stub |
Seis pasos: ID de router y direccionamiento, un área única funcionando, decidir el ABR, añadir el área stub, igualar el atributo stub en todos los routers que lo necesitan, y prioridad DR en segmentos compartidos.
#
sysname RouterA
#
router id 1.1.1.1
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Ethernet2/0/0
port link-type trunk
port trunk allow-pass vlan 10
#
interface GigabitEthernet3/0/0
ip address 192.168.0.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
##
sysname RouterB
#
router id 2.2.2.2
#
vlan batch 20
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Ethernet2/0/0
port link-type trunk
port trunk allow-pass vlan 20
#
interface GigabitEthernet3/0/0
ip address 192.168.0.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#Una red distinta y más grande ilustra la siguiente etapa: RouterB se convierte en el ABR entre el Área 0 y una nueva Área 1, y el Área 1 se marca como stub para que RouterC solo necesite una ruta predeterminada para llegar a todo lo que hay detrás del backbone.
#
sysname RouterA
#
router id 1.1.1.1
#
interface GigabitEthernet1/0/0
ip address 192.168.2.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 192.168.0.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 2
import-route direct
area 0.0.0.0
network 192.168.0.0 0.0.0.255
##
sysname RouterB
#
router id 2.2.2.2
#
interface GigabitEthernet1/0/0
ip address 192.168.1.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 192.168.0.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
##
sysname RouterC
#
router id 3.3.3.3
#
interface GigabitEthernet1/0/0
ip address 192.168.1.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 2
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
#La LAN de RouterA en GigabitEthernet1/0/0 se deja deliberadamente fuera de la sentencia network de OSPF y se importa en su lugar con import-route direct — un patrón común para un segmento conectado localmente que no necesita su propia adyacencia OSPF.
Primero estado Full en el par de área única, luego estado Full en ambos lados del ABR, y luego una tabla de enrutamiento en el router del área stub notablemente más corta que la del backbone.
<RouterA> display ospf peer brief
OSPF Process 2 with Router ID 1.1.1.1
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet3/0/0 2.2.2.2 Full
----------------------------------------------------------------------------
Total Peer(s): 1<RouterB> display ospf peer brief
OSPF Process 2 with Router ID 2.2.2.2
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet2/0/0 1.1.1.1 Full
0.0.0.1 GigabitEthernet1/0/0 3.3.3.3 Full
----------------------------------------------------------------------------
Total Peer(s): 2<RouterC> display ip routing-table
Destinations : 2 Routes : 2
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 O_ASE 150 1 192.168.1.2 GigabitEthernet1/0/0
192.168.1.0/24 Direct 0 0 192.168.1.1 GigabitEthernet1/0/0La tabla de enrutamiento de RouterC se mantiene corta a propósito — ese es todo el sentido de marcar el Área 1 como stub; nunca recibe las rutas externas o interárea individuales que llevaría un área ordinaria.
Las que convierten un área única funcional en un diseño multiárea que solo funciona a medias.
SÍNTOMAEn un segmento Ethernet o VLANIF compartido con tres o más routers OSPF, el DR resulta ser el router que menos quería — a menudo simplemente el que activó su interfaz primero.
CAUSACada interfaz con OSPF habilitado empieza con una prioridad DR de 1 por defecto. Cuando las prioridades empatan, gana el router con el ID de router más alto — lo cual no tiene nada que ver con qué router tiene en realidad el mejor hardware o la mejor ubicación para ser DR.
SOLUCIÓNEstablezca explícitamente ospf dr-priority en cada interfaz del segmento — un valor más alto en el router que desea como DR, prioridad 0 en cualquier router que nunca deba convertirse en DR ni BDR.
SÍNTOMAUn router en el borde de lo que se supone es un área stub o no forma ninguna adyacencia, o el área no se comporta como stub — siguen apareciendo rutas externas completas en algún punto dentro de ella.
CAUSAEl atributo stub se negocia en los indicadores de opciones del paquete Hello. Si el ABR está configurado como stub pero un router dentro de esa área no lo está (o viceversa), esa sola discrepancia basta para bloquear la adyacencia — no es un ajuste que un solo router pueda sostener para toda el área.
SOLUCIÓNConfigure la palabra clave stub bajo esa área en todos y cada uno de los routers que la componen, incluido el ABR. La misma regla se aplica a NSSA — es un requisito de coincidencia, no opcional, para cada router que comparte esa área.
SÍNTOMAUna interfaz que claramente debería pertenecer a un área OSPF nunca establece un vecino, o una interfaz que no debería ejecutar OSPF en absoluto termina de alguna manera anunciada.
CAUSAEl comando network bajo un área OSPF usa una máscara wildcard, no una máscara de subred — network 192.168.0.0 0.0.0.255 coincide con el rango 192.168.0.0/24, pero un error tipográfico aquí (un bit de más o de menos) cambia silenciosamente qué interfaces se incorporan al área.
SOLUCIÓNVerifique dos veces el cálculo de la máscara wildcard contra la dirección real de la interfaz, y confirme con display ospf interface qué interfaces recogió realmente el proceso — no confíe solo en la configuración tal como está escrita.
SÍNTOMAUn router recién añadido no forma adyacencia con nadie en una red OSPF existente, a pesar de que las interfaces son alcanzables y la configuración parece correcta en ambos lados.
CAUSASi el ID de router del nuevo router coincide con uno ya activo en otro punto del dominio OSPF — algo fácil de que ocurra con IDs de router autoseleccionados o configuraciones copiadas y pegadas — el dominio ve un conflicto en lugar de un segundo router utilizable.
SOLUCIÓNAsigne el ID de router explícitamente con router id bajo el proceso OSPF, vinculado a una dirección LoopBack0 estable — nunca lo deje a la selección automática de una dirección de interfaz física que podría cambiar o ya estar en uso en otro lugar.
Esta nota se basa en dos configuraciones concretas: una red de dos routers con una única Área 0, y un diseño de tres routers con un ABR y un Área 1 stub. No explica NSSA en detalle (una variante cercana, descrita brevemente arriba), los enlaces virtuales de OSPF a través de un área de tránsito, la agregación de rutas en el ABR, ni la autenticación OSPF — todos pasos siguientes razonables una vez que el diseño multiárea básico esté en marcha. Tampoco cubre qué ocurre cuando los routers adyacentes son de proveedores distintos — vea nuestra nota de interoperabilidad OSPF Huawei-Cisco para eso, o nuestra nota de resolución de problemas de vecinos OSPF si una adyacencia en su propia red se niega a establecerse.
Extraídas de los mismos casos de configuración en los que se basa esta nota.
Empiece plano. Una única Área 0 es el diseño correcto hasta que la red realmente crezca más allá de lo que un área maneja cómodamente — las áreas adicionales añaden planificación de ABR y decisiones stub/NSSA que todavía no necesita. Añada el Área 1 (o más) cuando exista un límite genuino que trazar: una sucursal, un bloque de centro de datos, o un enlace donde quiera ocultar información de enrutamiento detallada en lugar de dejarla pasar toda.
El ABR es simplemente el router que toca físicamente tanto el Área 0 como la nueva área — es un hecho de topología más que una elección. Lo que sí es una elección es lo que configura en él: si el área detrás de él sigue siendo un área normal, se convierte en área stub, o se convierte en NSSA, según si esa área necesita originar sus propias rutas externas.
Ese es todo el propósito de un área stub — el ABR reemplaza cada LSA externa (Tipo 5) que de otro modo inundaría en esa área por una única ruta predeterminada, reduciendo la tabla de enrutamiento y la inundación de LSA que un router de borde pequeño debe soportar. Si ese router de borde también necesita originar sus propias rutas externas hacia el área, NSSA es la variante construida para eso.
Esa nota supone que ya existe una red OSPF y que una relación de vecindad está atascada o inestable — lee la máquina de estados de vecinos para averiguar por qué. Esta nota no supone que nada exista todavía: es la configuración que le lleva a tener una relación de vecindad funcional y un diseño multiárea funcional desde el principio.
No — la elección de DR/BDR es un concepto de red broadcast (multiacceso). Las interfaces de tipo punto a punto no tienen ningún DR que elegir, por lo que dr-priority no tiene nada sobre lo que actuar ahí; solo importa en segmentos broadcast de tipo Ethernet/VLANIF con más de un router OSPF conectado.
La lógica de áreas, network y stub aquí es un comportamiento de OSPF neutral respecto al proveedor, pero los temporizadores predeterminados, la elegibilidad de DR en ciertos tipos de interfaz y el cálculo del costo pueden diferir lo suficiente entre proveedores como para impedir que un diseño que funciona dentro de un proveedor funcione entre proveedores. Vea nuestra nota de interoperabilidad OSPF Huawei-Cisco para los valores predeterminados específicos que no coinciden de fábrica.
Cuéntenos cuántos sitios, cuántos routers, y dónde espera que caigan los límites de las áreas, y le ayudaremos a planificar el diseño de áreas y la ubicación del ABR.