Two vendors, one broadcast segment, one OSPF area — the configuration itself is short, but network type, hello/dead timers, DR/BDR election and cost calculation all quietly assume both ends agree on the same rules. Here's a real Huawei-to-Cisco interop build with the actual data plan and CLI, plus the five places the two vendors don't call attention to their own differences.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
If a neighbor won't come up at all, read the OSPF neighbor state machine first. This note is about something upstream of that: getting a Huawei AR router and a Cisco router to actually agree on a shared broadcast segment in the first place.
This is not the neighbor-state-machine troubleshooting flow — for reading a neighbor stuck at Init, ExStart or Loading, see OSPF Neighbor Troubleshooting. This note instead walks a real Huawei-to-Cisco broadcast-network OSPF build end to end: the configuration on both vendors, the network-type and timer defaults that mostly already agree, and the DR/BDR election and cost-calculation details that don't call attention to themselves until a third router joins the segment or someone changes one side's reference bandwidth.
What follows: the actual topology and data plan, the CLI for all three routers, where network type and timers already line up by default, DR/BDR election behavior on a mixed-vendor segment, the reference-bandwidth cost trap, five field gotchas, and an FAQ.
One Huawei AR router (RouterA) directly connected to a Cisco router on one segment, with a second Huawei router (RouterB) hanging off RouterA on another segment to confirm routes actually propagate end to end.
Diagram labels are kept in English for engineering clarity.
Data Plan
| Item | RouterA — Huawei | Cisco Router | RouterB — Huawei |
|---|---|---|---|
| GE0/0/0 (to RouterB) | 10.1.1.1/24 | — | 10.1.1.2/24 |
| GE4/0/0 / GE0/1 (to Cisco) | 14.1.1.1/24 | 14.1.1.10/24 | — |
| OSPF Router ID | 10.1.1.1 | 14.1.1.10 | 10.1.1.2 |
| OSPF area | 0.0.0.0 | 0.0.0.0 | 0.0.0.0 |
Ethernet interfaces default to broadcast network type on Huawei, so no ospf network-type command is needed here.
<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 neededSame default applies on the Cisco side — Ethernet interfaces are broadcast network type unless told otherwise.
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/1In this build, nobody had to touch a single timer or network-type command — and that's exactly why it's worth understanding when that stops being true.
The source configuration notes it explicitly on all three routers: by default, an Ethernet interface's OSPF network type is broadcast, so no ospf network-type command is required. That's true on the Huawei AR platform and on Cisco IOS alike — both default Ethernet to broadcast network type, which is also why the hello/dead timer defaults line up: 10 seconds / 40 seconds for broadcast on both platforms. Nobody configured a timer in this build because nobody had to.
The risk shows up when the interop isn't broadcast-to-broadcast — when a third-party interface is set to a non-standard variant that only behaves like a standard type on paper. That specific failure mode, with a real case, is covered in OSPF Neighbor Troubleshooting; the short version is: always force both ends to one of the four standard OSPF network types, and never accept a peer's proprietary label just because it sounds similar.
The election algorithm doesn't know or care which vendor built which router — but it's worth walking through with a mixed segment to see exactly where habits from one platform stop applying.
Illustrative segment — this election detail isn't the two-router build shown in Section 2 above.
On a shared broadcast segment with three routers — say a Huawei router at priority 1, a Cisco router also at priority 1, and a second Huawei router at priority 0 — the standard algorithm runs identically regardless of vendor: highest interface priority wins DR, ties are broken by the highest Router ID, and priority 0 permanently excludes a router from becoming DR or BDR (it stays DR Other / DROTHER). None of that logic is vendor-specific; it's the OSPF standard, and both platforms implement it the same way.
What does trip people up across vendors is that election is not preemptive on either platform: once a DR is elected, a router joining later with a higher priority or higher Router ID does not take over. Forcing re-election needs a deliberate action — toggling the interface (shutdown / undo shutdown, or Cisco's equivalent) or restarting the OSPF process — and the command to do that differs by vendor, which is its own small gotcha below.
This one never breaks the adjacency — the neighbor stays Full, routes still show up, and the path selection is simply wrong.
OSPF cost on both platforms is derived the same way: reference bandwidth divided by the interface's actual bandwidth. Both Huawei AR routers and Cisco routers default that reference bandwidth to 100 Mbit/s — which means, by default, a GigabitEthernet link and a 10GbE link score the exact same cost of 1 on both platforms alike. That's already a limitation both vendors share out of the box.
The cross-vendor risk shows up when only one side gets fixed. It's common practice to raise the reference bandwidth after adding 10G links so cost reflects real capacity again — on Huawei that's the bandwidth-reference command inside the OSPF process, on Cisco it's auto-cost reference-bandwidth inside router ospf. Change it on one platform without mirroring the change on the other, and the two vendors start scoring the identical physical links with different costs — best-path selection quietly diverges between them, with no error message anywhere to point at.
[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 vendorsThe ones that show up once real hardware from both vendors is actually in the same OSPF area.
SYMPTOMYou changed the Router ID on one side to fix a conflict, the command was accepted with no error, and the neighbor still won't come up — or the old Router ID still shows in display / show output.
CAUSEOn both platforms, an OSPF Router ID change only takes effect after the OSPF process restarts — not the moment the command is entered. The source configuration shows Cisco returning this exact message when the router-id command is entered: "% OSPF: Reload or use 'clear ip ospf process' command, for this to take effect." Huawei behaves the same way, just with a different command.
FIXOn Cisco, run clear ip ospf process (or reload) after changing router-id under router ospf. On Huawei, run reset ospf process-id process in user view after changing ospf router-id. Neither vendor's new Router ID is live until you do this.
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"SYMPTOMThis build needed zero network-type configuration. In a different interop, one specific third-party router simply never forms a neighbor relationship, while every other OSPF neighbor on the same network interoperates fine.
CAUSEBoth Huawei and Cisco Ethernet interfaces default to standard broadcast network type, which is exactly why the build above needed no network-type command at all. The exception is a peer running a vendor-specific network-type variant that looks like a standard OSPF type on paper but runs a different, non-standard mechanism underneath — the two sides are then never actually speaking the same OSPF dialect.
FIXCheck the network type on both ends and force both to one of the four standard OSPF types (broadcast, P2P, NBMA, P2MP) with ospf network-type. Full field details and a real case are in OSPF Neighbor Troubleshooting.
SYMPTOMA higher-priority or higher-Router-ID router was added to an already-stable broadcast segment, expecting it to take over as DR — and it didn't.
CAUSEDR/BDR election on both Huawei and Cisco is non-preemptive: once a DR and BDR are elected, a new router joining later — even with a higher priority or higher Router ID — does not trigger re-election. It joins as DR Other. This is standard OSPF behavior on both platforms, not a bug on either side.
FIXIf the new router genuinely needs to be DR, force re-election deliberately — toggle the interface down/up (shutdown / undo shutdown on Huawei, shutdown / no shutdown on Cisco) or restart the OSPF process on all routers on that segment. Do this in a maintenance window: it drops every adjacency on the segment, not just the one you're changing.
[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 equivalentSYMPTOMNeighbor state is Full on both vendors, routes for a prefix are present on both sides, but traffic consistently takes a path that isn't the one you'd expect given the actual link speeds.
CAUSESomeone raised the reference bandwidth on one platform after adding faster links, so cost would actually reflect capacity again, but didn't mirror the change on the other vendor's routers in the same area. The two platforms now compute different cost values for the identical physical links, and best-path selection silently diverges — with no error anywhere, because this never affects adjacency state.
FIXSet the same reference bandwidth on every router in the area, on both vendors: bandwidth-reference under the Huawei OSPF process, auto-cost reference-bandwidth under Cisco's router ospf. Treat it as one shared parameter for the whole area, not a per-platform tuning knob.
[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 vendorsSYMPTOMEverything looks fine from one side's command output, but a DR/BDR-related question can't actually be answered from that output alone.
CAUSEHuawei's display ospf peer brief confirms neighbor state (Down/Init/2-Way/Full) per row, but not DR/BDR role — that needs display ospf interface separately. Cisco's show ip ospf neighbor folds both into one State column (for example FULL/DR or FULL/BDR) in a single command. An engineer used to one platform's habits can check the wrong command on the other vendor and simply not see the information they're looking for.
FIXWhen checking a mixed-vendor segment, pull both: display ospf peer brief plus display ospf interface on the Huawei side, show ip ospf neighbor on the Cisco side. Don't assume one command's output format tells the whole story on the other platform.
<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/DROTHERThe questions that come up whenever a Huawei-Cisco OSPF interop is actually on the table.
No. Ethernet interfaces on both platforms default to broadcast network type, as the source configuration notes explicitly on all three routers in this build. You only need the command when one side's interface type isn't actually broadcast.
Cisco needs a reload or clear ip ospf process command after changing router-id — the CLI even prints a message saying so. Huawei needs reset ospf process-id process after changing ospf router-id. Neither vendor applies the new ID just because the command was accepted.
No — it never prevents Full state and never shows up as an error. It only skews the cost metric used for path selection, which is exactly why it's easy to miss: the neighbor is healthy, routes are present, and the only symptom is traffic taking a path that doesn't match the actual link speeds.
No. Election on both Huawei and Cisco is non-preemptive — once a DR and BDR are elected on the segment, a later-joining router with higher priority or a higher Router ID still joins as DR Other. Forcing a re-election needs a deliberate interface reset or OSPF process restart on that segment.
This note assumes Full has already been reached and is about the surrounding configuration decisions. For the full state-machine diagnostic flow — Down through Init, 2-Way, ExStart, Exchange, Loading to Full, with the display commands and root causes for each stuck state — see OSPF Neighbor Troubleshooting.
This note is built around one real Huawei-AR-to-Cisco-IOS broadcast-network OSPF interop, using the actual configuration and verification output from Huawei's own interconnection guide. It doesn't cover NBMA or P2MP interop specifics, OSPFv3/IPv6, virtual links, or ABR summarization across a mixed-vendor multi-area design — those each deserve their own look.
Send us the network type, the display/show output from both ends, and where it's diverging — we'll help you read it.