Dos fabricantes, un segmento broadcast, un área OSPF — la configuración en sí es breve, pero el tipo de red, los temporizadores hello/dead, la elección DR/BDR y el cálculo del costo asumen silenciosamente que ambos extremos siguen las mismas reglas. Aquí hay un montaje real de interoperabilidad Huawei-Cisco con el plan de datos y la CLI reales, además de los cinco puntos donde los dos fabricantes divergen sin avisar.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Si un vecino simplemente no se establece, primero lea la máquina de estados de vecinos OSPF. Esta nota trata un problema anterior a ese: lograr que un router Huawei AR y un router Cisco realmente se pongan de acuerdo en un mismo segmento broadcast.
Este no es el flujo de resolución de problemas de la máquina de estados de vecinos — para leer un vecino atascado en Init, ExStart o Loading, consulte Resolución de problemas de vecinos OSPF. Esta nota recorre en cambio una construcción real de OSPF Huawei-Cisco en red broadcast de principio a fin: la configuración de ambos fabricantes, los valores predeterminados de tipo de red y temporizadores que ya coinciden en su mayoría, y los detalles de elección DR/BDR y cálculo de costo que no llaman la atención hasta que un tercer router se une al segmento o alguien cambia el ancho de banda de referencia de un lado.
A continuación: la topología y el plan de datos reales, la CLI de los tres routers, los puntos donde el tipo de red y los temporizadores ya coinciden por defecto, el comportamiento de elección DR/BDR en un segmento de fabricantes mixtos, la trampa de costo del ancho de banda de referencia, cinco trampas de campo y una FAQ.
Un router Huawei AR (RouterA) conectado directamente a un router Cisco en un segmento, con un segundo router Huawei (RouterB) colgado de RouterA en otro segmento para confirmar que las rutas realmente se propagan de extremo a extremo.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Plan de datos
| Elemento | RouterA — Huawei | Router Cisco | RouterB — Huawei |
|---|---|---|---|
| GE0/0/0 (hacia RouterB) | 10.1.1.1/24 | — | 10.1.1.2/24 |
| GE4/0/0 / GE0/1 (hacia Cisco) | 14.1.1.1/24 | 14.1.1.10/24 | — |
| Router ID OSPF | 10.1.1.1 | 14.1.1.10 | 10.1.1.2 |
| Área OSPF | 0.0.0.0 | 0.0.0.0 | 0.0.0.0 |
En Huawei, las interfaces Ethernet usan por defecto el tipo de red broadcast, así que aquí no hace falta el comando ospf network-type.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface GigabitEthernet0/0/0
[RouterA-GigabitEthernet0/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet0/0/0] quit
[RouterA] interface GigabitEthernet4/0/0
[RouterA-GigabitEthernet4/0/0] ip address 14.1.1.1 255.255.255.0
[RouterA-GigabitEthernet4/0/0] quit
[RouterA] ospf 1 router-id 10.1.1.1
[RouterA-ospf-1] area 0.0.0.0
[RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] network 14.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
// Ethernet interfaces default to broadcast network type -- no ospf network-type neededSe aplica el mismo valor por defecto en el lado Cisco — las interfaces Ethernet son de tipo broadcast salvo que se indique lo contrario.
server> enable
server# config
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line. End with CNTL/Z.
server(config)# interface gigabitEthernet 0/1
server(config-if)# ip address 14.1.1.10 255.255.255.0
server(config-if)# exit
server(config)# router ospf 1
server(config-router)# network 14.1.1.0 0.0.0.255 area 0
server(config-router)# router-id 14.1.1.10
% OSPF: Reload or use "clear ip ospf process" command, for this to take effect
server(config-router)# exit<Huawei> system-view
[Huawei] sysname RouterB
[RouterB] interface GigabitEthernet 0/0/0
[RouterB-GigabitEthernet0/0/0] ip address 10.1.1.2 255.255.255.0
[RouterB-GigabitEthernet0/0/0] quit
[RouterB] ospf 1 router-id 10.1.1.2
[RouterB-ospf-1] area 0.0.0.0
[RouterB-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit[RouterA] display ospf peer brief
OSPF Process 1 with Router ID 10.1.1.1
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet4/0/0 14.1.1.10 Full
0.0.0.0 GigabitEthernet0/0/0 10.1.1.2 Full
----------------------------------------------------------------------------
Total Peer(s): 2
[RouterB] display ospf peer brief
OSPF Process 1 with Router ID 10.1.1.2
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/0 10.1.1.1 Full
----------------------------------------------------------------------------
Total Peer(s): 1
server> show ip route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O 10.1.1.0/24 [110/2] via 14.1.1.1, 00:00:01, GigabitEthernet0/1En este montaje, nadie tuvo que tocar un solo temporizador ni el comando network-type — y precisamente por eso vale la pena entender cuándo eso deja de ser cierto.
La configuración fuente lo indica explícitamente en los tres routers: por defecto, el tipo de red OSPF de una interfaz Ethernet es broadcast, por lo que no se requiere el comando ospf network-type. Esto es cierto tanto en la plataforma Huawei AR como en Cisco IOS — ambas asignan por defecto el tipo broadcast a las interfaces Ethernet, lo que también explica por qué los temporizadores hello/dead por defecto coinciden: 10 segundos / 40 segundos en broadcast en ambas plataformas. Nadie configuró un temporizador en este montaje porque nadie tuvo que hacerlo.
El riesgo aparece cuando la interoperabilidad no es broadcast a broadcast — cuando la interfaz de un tercero se configura con una variante no estándar que solo se comporta como un tipo estándar sobre el papel. Ese modo de falla específico, con un caso real, se trata en Resolución de problemas de vecinos OSPF; en resumen: fuerce siempre ambos extremos a uno de los cuatro tipos de red OSPF estándar, y nunca acepte la etiqueta propietaria de un par solo porque suene parecida.
El algoritmo de elección no sabe ni le importa qué fabricante construyó cada router — pero vale la pena recorrerlo con un segmento mixto para ver exactamente dónde dejan de aplicarse los hábitos de una plataforma.
Illustrative segment — this election detail isn't the two-router build shown in Section 2 above.
En un segmento broadcast compartido por tres routers — digamos un router Huawei con prioridad 1, un router Cisco también con prioridad 1, y un segundo router Huawei con prioridad 0 — el algoritmo estándar se ejecuta de forma idéntica sin importar el fabricante: la prioridad de interfaz más alta gana el DR, los empates se resuelven con el Router ID más alto, y una prioridad 0 excluye permanentemente a un router de ser DR o BDR (permanece como DR Other / DROTHER). Nada de esta lógica es específico de un fabricante; es el estándar OSPF, y ambas plataformas lo implementan de la misma manera.
Lo que realmente confunde entre fabricantes es que la elección no es preferente en ninguna de las dos plataformas: una vez elegido un DR, un router que se une después con mayor prioridad o Router ID no toma el relevo. Forzar una nueva elección requiere una acción deliberada — alternar la interfaz (shutdown / undo shutdown, o el equivalente en Cisco) o reiniciar el proceso OSPF — y el comando para hacerlo difiere según el fabricante, lo cual es en sí una pequeña trampa más abajo.
Este nunca rompe la adyacencia — el vecino permanece en Full, las rutas siguen apareciendo, y la selección de ruta simplemente es incorrecta.
El costo OSPF en ambas plataformas se deriva de la misma manera: ancho de banda de referencia dividido por el ancho de banda real de la interfaz. Tanto los routers Huawei AR como los routers Cisco fijan por defecto ese ancho de banda de referencia en 100 Mbit/s — lo que significa que, por defecto, un enlace GigabitEthernet y un enlace 10GbE obtienen exactamente el mismo costo de 1 en ambas plataformas. Esa ya es una limitación que ambos fabricantes comparten de fábrica.
El riesgo entre fabricantes aparece cuando solo se corrige un lado. Es práctica común aumentar el ancho de banda de referencia después de añadir enlaces de 10G para que el costo vuelva a reflejar la capacidad real — en Huawei es el comando bandwidth-reference dentro del proceso OSPF, en Cisco es auto-cost reference-bandwidth dentro de router ospf. Si se cambia en una plataforma sin reflejar el cambio en la otra, los dos fabricantes empiezan a puntuar los mismos enlaces físicos con costos distintos — la selección de la mejor ruta diverge silenciosamente entre ellos, sin ningún mensaje de error que lo señale.
[RouterA-ospf-1] bandwidth-reference 1000
// Huawei: reference bandwidth in Mbit/s, set inside the OSPF process view
Router(config-router)# auto-cost reference-bandwidth 1000
// Cisco: same idea, set inside router ospf -- must match on every router in the area, both vendorsLos que aparecen una vez que hardware real de ambos fabricantes está realmente en la misma área OSPF.
SÍNTOMACambió el Router ID de un lado para resolver un conflicto, el comando se aceptó sin error, y el vecino sigue sin establecerse — o el Router ID antiguo sigue apareciendo en la salida display / show.
CAUSAEn ambas plataformas, un cambio de Router ID de OSPF solo surte efecto después de reiniciar el proceso OSPF — no en el momento en que se introduce el comando. La configuración de origen muestra a Cisco devolviendo exactamente este mensaje al introducir el comando router-id: "% OSPF: Reload or use 'clear ip ospf process' command, for this to take effect." Huawei se comporta igual, solo que con un comando distinto.
SOLUCIÓNEn Cisco, ejecute clear ip ospf process (o reload) tras cambiar router-id bajo router ospf. En Huawei, ejecute reset ospf process-id process en vista de usuario tras cambiar ospf router-id. En ningún fabricante el nuevo Router ID está activo hasta hacer esto.
server(config-router)# router-id 14.1.1.10
% OSPF: Reload or use "clear ip ospf process" command, for this to take effect
server(config-router)# end
server# clear ip ospf process
[RouterA-ospf-1] router-id 10.1.1.1
<RouterA> reset ospf 1 process
// Huawei: new Router ID only takes effect after "reset ospf process-id process"SÍNTOMAEste montaje no necesitó ninguna configuración de tipo de red. En otra interoperabilidad, un router específico de un tercero simplemente nunca forma una relación de vecino, mientras que todos los demás vecinos OSPF de la misma red interoperan bien.
CAUSATanto las interfaces Ethernet de Huawei como las de Cisco usan por defecto el tipo de red broadcast estándar, y por eso exactamente el montaje anterior no necesitó ningún comando network-type. La excepción es un par que ejecuta una variante de tipo de red propia de un fabricante que parece un tipo OSPF estándar sobre el papel pero ejecuta por debajo un mecanismo distinto, no estándar — los dos lados nunca están realmente hablando el mismo dialecto OSPF.
SOLUCIÓNCompruebe el tipo de red en ambos extremos y fuerce ambos a uno de los cuatro tipos OSPF estándar (broadcast, P2P, NBMA, P2MP) con ospf network-type. Los detalles completos y un caso real están en Resolución de problemas de vecinos OSPF.
SÍNTOMASe añadió un router con mayor prioridad o Router ID a un segmento broadcast ya estable, esperando que asumiera el rol de DR — y no ocurrió.
CAUSALa elección DR/BDR tanto en Huawei como en Cisco no es preferente: una vez elegidos un DR y un BDR, un router nuevo que se une después — incluso con mayor prioridad o Router ID — no desencadena una nueva elección. Se une como DR Other. Este es un comportamiento OSPF estándar en ambas plataformas, no un error de ninguna de las dos.
SOLUCIÓNSi el router nuevo realmente necesita ser DR, fuerce deliberadamente una nueva elección — alterne la interfaz (shutdown / undo shutdown en Huawei, shutdown / no shutdown en Cisco) o reinicie el proceso OSPF en todos los routers de ese segmento. Hágalo en una ventana de mantenimiento: esto derriba todas las adyacencias del segmento, no solo la que está cambiando.
[RouterD-GigabitEthernet0/0/0] shutdown
[RouterD-GigabitEthernet0/0/0] undo shutdown
// forces re-election on that segment -- drops every adjacency on it, use in a maintenance window
Router(config-if)# shutdown
Router(config-if)# no shutdown
// Cisco equivalentSÍNTOMAEl estado del vecino es Full en ambos fabricantes, las rutas para un prefijo están presentes en ambos lados, pero el tráfico toma sistemáticamente una ruta que no es la esperada dadas las velocidades reales de los enlaces.
CAUSAAlguien aumentó el ancho de banda de referencia en una plataforma tras añadir enlaces más rápidos, para que el costo volviera a reflejar la capacidad real, pero no reflejó el cambio en los routers del otro fabricante en la misma área. Las dos plataformas ahora calculan valores de costo distintos para enlaces físicos idénticos, y la selección de la mejor ruta diverge silenciosamente — sin ningún error en ninguna parte, porque esto nunca afecta el estado de la adyacencia.
SOLUCIÓNConfigure el mismo ancho de banda de referencia en todos los routers del área, en ambos fabricantes: bandwidth-reference bajo el proceso OSPF de Huawei, auto-cost reference-bandwidth bajo router ospf de Cisco. Trátelo como un parámetro compartido para toda el área, no como un ajuste específico de cada plataforma.
[RouterA-ospf-1] bandwidth-reference 1000
// Huawei: reference bandwidth in Mbit/s, set inside the OSPF process view
Router(config-router)# auto-cost reference-bandwidth 1000
// Cisco: same idea, set inside router ospf -- must match on every router in the area, both vendorsSÍNTOMATodo parece correcto según la salida de comandos de un lado, pero una pregunta relacionada con DR/BDR en realidad no se puede responder solo con esa salida.
CAUSAEl display ospf peer brief de Huawei confirma el estado del vecino (Down/Init/2-Way/Full) por fila, pero no el rol DR/BDR — eso requiere un display ospf interface aparte. El show ip ospf neighbor de Cisco combina ambos en una sola columna State (por ejemplo FULL/DR o FULL/BDR) en un solo comando. Un ingeniero acostumbrado a los hábitos de una plataforma puede consultar el comando equivocado en el otro fabricante y simplemente no ver la información que busca.
SOLUCIÓNAl verificar un segmento de fabricantes mixtos, obtenga ambos: display ospf peer brief más display ospf interface en el lado Huawei, show ip ospf neighbor en el lado Cisco. No asuma que el formato de salida de un comando cuenta toda la historia en la otra plataforma.
<RouterA> display ospf peer brief
<RouterA> display ospf interface
// Huawei needs both commands -- state from one, DR/BDR role from the other
Router# show ip ospf neighbor
// Cisco folds state and DR/BDR role into one State column, e.g. FULL/DR, FULL/BDR, FULL/DROTHERLas preguntas que surgen cada vez que una interoperabilidad OSPF Huawei-Cisco está realmente sobre la mesa.
No. Las interfaces Ethernet de ambas plataformas usan por defecto el tipo de red broadcast, como indica explícitamente la configuración fuente en los tres routers de este montaje. Solo necesita el comando cuando el tipo de interfaz de un lado no es realmente broadcast.
Cisco necesita un comando reload o clear ip ospf process después de cambiar router-id — la CLI incluso imprime un mensaje al respecto. Huawei necesita reset ospf process-id process después de cambiar ospf router-id. En ningún fabricante el nuevo ID se aplica solo porque el comando fue aceptado.
No — nunca impide el estado Full ni aparece como error. Solo distorsiona la métrica de costo usada para la selección de ruta, que es precisamente por qué es fácil pasarlo por alto: el vecino está sano, las rutas están presentes, y el único síntoma es que el tráfico toma una ruta que no coincide con las velocidades reales de los enlaces.
No. La elección en Huawei y en Cisco no es preferente — una vez elegidos un DR y un BDR en el segmento, un router que se une después con mayor prioridad o mayor Router ID igual se une como DR Other. Forzar una nueva elección requiere un reinicio deliberado de interfaz o del proceso OSPF en ese segmento.
Esta nota asume que ya se alcanzó el estado Full y trata sobre las decisiones de configuración circundantes. Para el flujo completo de diagnóstico de la máquina de estados — de Down a Full pasando por Init, 2-Way, ExStart, Exchange, Loading, con los comandos display y las causas raíz de cada estado atascado — consulte Resolución de problemas de vecinos OSPF.
Esta nota se basa en una interoperabilidad OSPF real en red broadcast entre Huawei AR y Cisco IOS, usando la configuración y la salida de verificación reales de la guía oficial de interconexión de Huawei. No cubre los detalles de interoperabilidad NBMA o P2MP, OSPFv3/IPv6, enlaces virtuales, ni el resumen ABR en un diseño multiárea de fabricantes mixtos — cada uno merece su propio análisis.
Envíenos el tipo de red, la salida display/show de ambos extremos, y dónde está divergiendo — le ayudaremos a interpretarlo.