Deux constructeurs, un segment broadcast, une zone OSPF — la configuration elle-même est courte, mais le type de réseau, les temporisateurs hello/dead, l'élection DR/BDR et le calcul du coût supposent tous silencieusement que les deux extrémités respectent les mêmes règles. Voici un vrai montage d'interopérabilité Huawei-Cisco avec le plan de données et la CLI réels, plus les cinq endroits où les deux constructeurs divergent sans le signaler.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Si un voisin ne monte pas du tout, commencez par lire la machine à états des voisins OSPF. Cette note traite d'un problème en amont : faire en sorte qu'un routeur Huawei AR et un routeur Cisco s'accordent réellement sur un même segment broadcast.
Ceci n'est pas le déroulé de dépannage de la machine à états des voisins — pour lire un voisin bloqué à Init, ExStart ou Loading, voir Dépannage des voisins OSPF. Cette note parcourt plutôt un vrai montage OSPF Huawei-Cisco sur réseau broadcast de bout en bout : la configuration des deux constructeurs, les valeurs par défaut de type de réseau et de temporisateurs qui concordent déjà globalement, et les détails d'élection DR/BDR et de calcul de coût qui ne se signalent pas d'eux-mêmes tant qu'un troisième routeur ne rejoint pas le segment ou que quelqu'un ne change pas la bande passante de référence d'un côté.
Voici ce qui suit : la topologie et le plan de données réels, la CLI des trois routeurs, les points où le type de réseau et les temporisateurs s'alignent déjà par défaut, le comportement d'élection DR/BDR sur un segment multi-constructeur, le piège du coût lié à la bande passante de référence, cinq pièges de terrain et une FAQ.
Un routeur Huawei AR (RouterA) directement connecté à un routeur Cisco sur un segment, avec un second routeur Huawei (RouterB) raccroché à RouterA sur un autre segment pour confirmer que les routes se propagent réellement de bout en bout.
Les libellés du schéma restent en anglais pour la clarté technique.
Plan de données
| Élément | RouterA — Huawei | Routeur Cisco | RouterB — Huawei |
|---|---|---|---|
| GE0/0/0 (vers RouterB) | 10.1.1.1/24 | — | 10.1.1.2/24 |
| GE4/0/0 / GE0/1 (vers 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 |
| Zone OSPF | 0.0.0.0 | 0.0.0.0 | 0.0.0.0 |
Sur Huawei, les interfaces Ethernet ont par défaut le type de réseau broadcast, aucune commande ospf network-type n'est donc nécessaire ici.
<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 neededLe même défaut s'applique côté Cisco — les interfaces Ethernet sont de type broadcast sauf indication contraire.
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/1Dans ce montage, personne n'a dû toucher à un seul temporisateur ni à la commande network-type — et c'est justement pour cela qu'il faut comprendre quand cela cesse d'être vrai.
La configuration source le note explicitement sur les trois routeurs : par défaut, le type de réseau OSPF d'une interface Ethernet est broadcast, donc aucune commande ospf network-type n'est requise. C'est vrai aussi bien sur la plateforme Huawei AR que sur Cisco IOS — les deux donnent par défaut le type broadcast aux interfaces Ethernet, ce qui explique aussi pourquoi les temporisateurs hello/dead par défaut s'alignent : 10 secondes / 40 secondes en broadcast sur les deux plateformes. Personne n'a configuré de temporisateur dans ce montage, car personne n'en avait besoin.
Le risque apparaît quand l'interopérabilité n'est pas broadcast-à-broadcast — quand l'interface d'un tiers est réglée sur une variante non standard qui ne se comporte comme un type standard que sur le papier. Ce mode de défaillance précis, avec un cas réel, est traité dans Dépannage des voisins OSPF ; en résumé : forcez toujours les deux extrémités sur l'un des quatre types de réseau OSPF standards, et n'acceptez jamais l'étiquette propriétaire d'un pair simplement parce qu'elle y ressemble.
L'algorithme d'élection ne sait ni ne se soucie de quel constructeur a fabriqué quel routeur — mais il vaut la peine de le parcourir avec un segment mixte pour voir précisément où les habitudes d'une plateforme cessent de s'appliquer.
Illustrative segment — this election detail isn't the two-router build shown in Section 2 above.
Sur un segment broadcast partagé par trois routeurs — disons un routeur Huawei à priorité 1, un routeur Cisco également à priorité 1, et un second routeur Huawei à priorité 0 — l'algorithme standard s'exécute de façon identique quel que soit le constructeur : la priorité d'interface la plus élevée l'emporte pour le DR, les égalités sont départagées par le Router ID le plus élevé, et une priorité de 0 exclut définitivement un routeur de devenir DR ou BDR (il reste DR Other / DROTHER). Rien de cette logique n'est propre à un constructeur ; c'est le standard OSPF, et les deux plateformes l'implémentent de la même façon.
Ce qui piège vraiment les gens d'un constructeur à l'autre, c'est que l'élection n'est préemptive sur aucune des deux plateformes : une fois un DR élu, un routeur qui rejoint plus tard avec une priorité ou un Router ID plus élevé ne prend pas le relais. Forcer une réélection nécessite une action délibérée — basculer l'interface (shutdown / undo shutdown, ou l'équivalent Cisco) ou redémarrer le processus OSPF — et la commande pour le faire diffère selon le constructeur, ce qui constitue en soi un petit piège ci-dessous.
Celui-ci ne casse jamais l'adjacence — le voisin reste Full, les routes apparaissent toujours, et le choix du chemin est tout simplement erroné.
Le coût OSPF sur les deux plateformes est calculé de la même façon : bande passante de référence divisée par la bande passante réelle de l'interface. Les routeurs Huawei AR et les routeurs Cisco fixent tous deux par défaut cette bande passante de référence à 100 Mbit/s — ce qui signifie que, par défaut, un lien GigabitEthernet et un lien 10 GbE obtiennent exactement le même coût de 1 sur les deux plateformes. C'est déjà une limite que les deux constructeurs partagent d'origine.
Le risque multi-constructeur apparaît quand un seul côté est corrigé. Il est courant d'augmenter la bande passante de référence après l'ajout de liens 10G pour que le coût reflète à nouveau la capacité réelle — chez Huawei c'est la commande bandwidth-reference dans le processus OSPF, chez Cisco c'est auto-cost reference-bandwidth dans router ospf. Changez-la sur une plateforme sans répercuter le changement sur l'autre, et les deux constructeurs se mettent à noter les mêmes liens physiques avec des coûts différents — le choix du meilleur chemin diverge silencieusement entre eux, sans le moindre message d'erreur à incriminer.
[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 vendorsCeux qui apparaissent une fois que du vrai matériel des deux constructeurs se trouve réellement dans la même zone OSPF.
SYMPTÔMEVous avez changé le Router ID d'un côté pour résoudre un conflit, la commande a été acceptée sans erreur, et le voisin ne monte toujours pas — ou l'ancien Router ID s'affiche toujours dans la sortie display / show.
CAUSESur les deux plateformes, un changement de Router ID OSPF ne prend effet qu'après le redémarrage du processus OSPF — pas au moment où la commande est saisie. La configuration source montre Cisco renvoyant exactement ce message lors de la saisie de la commande router-id : « % OSPF: Reload or use 'clear ip ospf process' command, for this to take effect. » Huawei se comporte de la même façon, avec une commande différente.
CORRECTIONSur Cisco, exécutez clear ip ospf process (ou reload) après avoir changé router-id sous router ospf. Sur Huawei, exécutez reset ospf process-id process en vue utilisateur après avoir changé ospf router-id. Chez aucun des deux constructeurs le nouveau Router ID n'est actif tant que cela n'est pas fait.
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"SYMPTÔMECe montage n'a nécessité aucune configuration de type de réseau. Dans une autre interopérabilité, un routeur tiers précis ne forme tout simplement jamais de relation de voisinage, alors que tous les autres voisins OSPF du même réseau s'interconnectent sans problème.
CAUSELes interfaces Ethernet Huawei et Cisco ont toutes deux par défaut le type de réseau broadcast standard, ce qui explique exactement pourquoi le montage ci-dessus n'a nécessité aucune commande network-type. L'exception est un pair exécutant une variante de type de réseau propre à un constructeur qui ressemble à un type OSPF standard sur le papier mais fait tourner en dessous un mécanisme différent, non standard — les deux côtés ne parlent alors jamais vraiment le même dialecte OSPF.
CORRECTIONVérifiez le type de réseau des deux côtés et forcez les deux sur l'un des quatre types OSPF standards (broadcast, P2P, NBMA, P2MP) avec ospf network-type. Les détails complets et un cas réel figurent dans Dépannage des voisins OSPF.
SYMPTÔMEUn routeur à priorité ou Router ID plus élevé a été ajouté à un segment broadcast déjà stable, en s'attendant à ce qu'il devienne DR — et ce n'est pas arrivé.
CAUSEL'élection DR/BDR chez Huawei comme chez Cisco n'est pas préemptive : une fois un DR et un BDR élus, un nouveau routeur qui rejoint plus tard — même avec une priorité ou un Router ID plus élevé — ne déclenche pas de réélection. Il rejoint en tant que DR Other. C'est un comportement OSPF standard sur les deux plateformes, pas un bug de l'une ou l'autre.
CORRECTIONSi le nouveau routeur doit vraiment être DR, forcez délibérément une réélection — basculez l'interface (shutdown / undo shutdown chez Huawei, shutdown / no shutdown chez Cisco) ou redémarrez le processus OSPF sur tous les routeurs de ce segment. Faites-le pendant une fenêtre de maintenance : cela coupe toutes les adjacences du segment, pas seulement celle que vous modifiez.
[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 equivalentSYMPTÔMEL'état du voisin est Full chez les deux constructeurs, les routes pour un préfixe sont présentes des deux côtés, mais le trafic emprunte systématiquement un chemin différent de celui attendu compte tenu des débits réels des liens.
CAUSEQuelqu'un a augmenté la bande passante de référence sur une plateforme après l'ajout de liens plus rapides, pour que le coût reflète à nouveau la capacité réelle, mais sans répercuter le changement sur les routeurs de l'autre constructeur dans la même zone. Les deux plateformes calculent désormais des coûts différents pour des liens physiques identiques, et le choix du meilleur chemin diverge silencieusement — sans aucune erreur, car cela n'affecte jamais l'état de l'adjacence.
CORRECTIONFixez la même bande passante de référence sur tous les routeurs de la zone, chez les deux constructeurs : bandwidth-reference sous le processus OSPF Huawei, auto-cost reference-bandwidth sous router ospf chez Cisco. Traitez-la comme un paramètre partagé pour toute la zone, pas un réglage propre à chaque plateforme.
[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 vendorsSYMPTÔMETout semble correct d'après la sortie de commande d'un côté, mais une question liée au DR/BDR ne peut en réalité pas être tranchée à partir de cette seule sortie.
CAUSELe display ospf peer brief de Huawei confirme l'état du voisin (Down/Init/2-Way/Full) par ligne, mais pas le rôle DR/BDR — cela nécessite un display ospf interface séparé. Le show ip ospf neighbor de Cisco regroupe les deux dans une seule colonne State (par exemple FULL/DR ou FULL/BDR) en une seule commande. Un ingénieur habitué aux habitudes d'une plateforme peut consulter la mauvaise commande chez l'autre constructeur et simplement ne pas voir l'information recherchée.
CORRECTIONLors de la vérification d'un segment multi-constructeur, récupérez les deux : display ospf peer brief plus display ospf interface côté Huawei, show ip ospf neighbor côté Cisco. Ne supposez pas que le format de sortie d'une commande raconte toute l'histoire sur l'autre plateforme.
<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/DROTHERLes questions qui reviennent chaque fois qu'une interopérabilité OSPF Huawei-Cisco est réellement à l'ordre du jour.
Non. Les interfaces Ethernet des deux plateformes ont par défaut le type de réseau broadcast, comme le note explicitement la configuration source sur les trois routeurs de ce montage. Vous n'avez besoin de la commande que lorsque le type d'interface d'un côté n'est pas réellement broadcast.
Cisco a besoin d'une commande reload ou clear ip ospf process après avoir changé router-id — la CLI affiche même un message à ce sujet. Huawei a besoin de reset ospf process-id process après avoir changé ospf router-id. Chez aucun des deux constructeurs le nouvel ID n'est appliqué simplement parce que la commande a été acceptée.
Non — cela n'empêche jamais l'état Full et ne se manifeste jamais par une erreur. Cela ne fait que fausser la métrique de coût utilisée pour le choix du chemin, ce qui explique justement pourquoi c'est facile à manquer : le voisin est sain, les routes sont présentes, et le seul symptôme est que le trafic emprunte un chemin qui ne correspond pas aux débits réels des liens.
Non. L'élection chez Huawei comme chez Cisco n'est pas préemptive — une fois un DR et un BDR élus sur le segment, un routeur qui rejoint plus tard avec une priorité ou un Router ID plus élevé rejoint quand même en tant que DR Other. Forcer une réélection nécessite une réinitialisation d'interface délibérée ou un redémarrage du processus OSPF sur ce segment.
Cette note suppose que l'état Full a déjà été atteint et porte sur les décisions de configuration environnantes. Pour le déroulé complet de diagnostic de la machine à états — de Down à Full en passant par Init, 2-Way, ExStart, Exchange, Loading, avec les commandes display et les causes racines de chaque état bloqué — voir Dépannage des voisins OSPF.
Cette note s'appuie sur une véritable interopérabilité OSPF sur réseau broadcast entre Huawei AR et Cisco IOS, en utilisant la configuration et la sortie de vérification réelles du guide d'interconnexion officiel de Huawei. Elle ne couvre pas les spécificités d'interopérabilité NBMA ou P2MP, OSPFv3/IPv6, les liens virtuels, ni le résumé ABR dans une conception multi-zones à constructeurs mixtes — chacun mériterait son propre article.
Envoyez-nous le type de réseau, la sortie display/show des deux extrémités, et où cela diverge — nous vous aiderons à l'interpréter.