Dois fabricantes, um segmento broadcast, uma área OSPF — a configuração em si é curta, mas o tipo de rede, os temporizadores hello/dead, a eleição DR/BDR e o cálculo de custo assumem silenciosamente que ambas as pontas seguem as mesmas regras. Aqui está uma montagem real de interoperabilidade Huawei-Cisco com o plano de dados e a CLI reais, além dos cinco pontos em que os dois fabricantes divergem sem avisar.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Se um vizinho simplesmente não sobe, leia primeiro a máquina de estados de vizinhos OSPF. Esta nota trata de algo anterior a isso: fazer um roteador Huawei AR e um roteador Cisco realmente concordarem em um mesmo segmento broadcast.
Este não é o fluxo de solução de problemas da máquina de estados de vizinhos — para ler um vizinho travado em Init, ExStart ou Loading, veja Solução de problemas de vizinhos OSPF. Esta nota percorre, em vez disso, uma montagem real de OSPF Huawei-Cisco em rede broadcast de ponta a ponta: a configuração de ambos os fabricantes, os padrões de tipo de rede e temporizadores que já concordam na maior parte, e os detalhes de eleição DR/BDR e cálculo de custo que não chamam atenção até que um terceiro roteador entre no segmento ou alguém altere a largura de banda de referência de um dos lados.
A seguir: a topologia e o plano de dados reais, a CLI dos três roteadores, os pontos em que o tipo de rede e os temporizadores já se alinham por padrão, o comportamento de eleição DR/BDR em um segmento de fabricantes mistos, a armadilha de custo da largura de banda de referência, cinco armadilhas de campo e um FAQ.
Um roteador Huawei AR (RouterA) conectado diretamente a um roteador Cisco em um segmento, com um segundo roteador Huawei (RouterB) pendurado no RouterA em outro segmento para confirmar que as rotas realmente se propagam de ponta a ponta.
Os rótulos do diagrama são mantidos em inglês para clareza técnica.
Plano de dados
| Item | RouterA — Huawei | Roteador Cisco | RouterB — Huawei |
|---|---|---|---|
| GE0/0/0 (para o RouterB) | 10.1.1.1/24 | — | 10.1.1.2/24 |
| GE4/0/0 / GE0/1 (para a 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 |
Nas interfaces Ethernet da Huawei, o tipo de rede padrão já é broadcast, então nenhum comando ospf network-type é necessário aqui.
<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 neededO mesmo padrão vale do lado Cisco — as interfaces Ethernet são do tipo broadcast, salvo indicação contrária.
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/1Nesta montagem, ninguém precisou tocar em um único temporizador ou no comando network-type — e é exatamente por isso que vale a pena entender quando isso deixa de ser verdade.
A configuração de origem observa isso explicitamente nos três roteadores: por padrão, o tipo de rede OSPF de uma interface Ethernet é broadcast, portanto nenhum comando ospf network-type é necessário. Isso vale tanto na plataforma Huawei AR quanto no Cisco IOS — ambos definem por padrão o tipo broadcast para interfaces Ethernet, o que também explica por que os temporizadores hello/dead padrão coincidem: 10 segundos / 40 segundos em broadcast em ambas as plataformas. Ninguém configurou um temporizador nesta montagem porque ninguém precisou.
O risco aparece quando a interoperabilidade não é broadcast para broadcast — quando a interface de terceiros é configurada com uma variante não padrão que só se comporta como um tipo padrão no papel. Esse modo de falha específico, com um caso real, é abordado em Solução de problemas de vizinhos OSPF; resumindo: force sempre as duas pontas para um dos quatro tipos de rede OSPF padrão, e nunca aceite o rótulo proprietário de um par só porque soa parecido.
O algoritmo de eleição não sabe nem se importa com qual fabricante construiu qual roteador — mas vale a pena percorrê-lo com um segmento misto para ver exatamente onde os hábitos de uma plataforma deixam de se aplicar.
Illustrative segment — this election detail isn't the two-router build shown in Section 2 above.
Em um segmento broadcast compartilhado por três roteadores — digamos um roteador Huawei com prioridade 1, um roteador Cisco também com prioridade 1, e um segundo roteador Huawei com prioridade 0 — o algoritmo padrão é executado de forma idêntica independentemente do fabricante: a maior prioridade de interface vence o DR, empates são resolvidos pelo maior Router ID, e prioridade 0 exclui permanentemente um roteador de se tornar DR ou BDR (permanece como DR Other / DROTHER). Nada dessa lógica é específico de fabricante; é o padrão OSPF, e ambas as plataformas o implementam da mesma forma.
O que realmente confunde entre fabricantes é que a eleição não é preemptiva em nenhuma das plataformas: uma vez eleito um DR, um roteador que entra depois com prioridade ou Router ID mais alto não assume o lugar. Forçar uma nova eleição exige uma ação deliberada — alternar a interface (shutdown / undo shutdown, ou o equivalente Cisco) ou reiniciar o processo OSPF — e o comando para isso difere por fabricante, o que é em si uma pequena armadilha abaixo.
Este nunca quebra a adjacência — o vizinho permanece Full, as rotas continuam aparecendo, e a seleção de caminho simplesmente fica errada.
O custo OSPF em ambas as plataformas é derivado da mesma forma: largura de banda de referência dividida pela largura de banda real da interface. Tanto os roteadores Huawei AR quanto os roteadores Cisco definem por padrão essa largura de banda de referência em 100 Mbit/s — o que significa que, por padrão, um link GigabitEthernet e um link 10GbE recebem exatamente o mesmo custo de 1 em ambas as plataformas. Essa já é uma limitação que os dois fabricantes compartilham de fábrica.
O risco entre fabricantes aparece quando apenas um lado é corrigido. É prática comum aumentar a largura de banda de referência após adicionar links de 10G para que o custo volte a refletir a capacidade real — na Huawei é o comando bandwidth-reference dentro do processo OSPF, na Cisco é auto-cost reference-bandwidth dentro de router ospf. Altere isso em uma plataforma sem espelhar a mudança na outra, e os dois fabricantes passam a pontuar os mesmos links físicos com custos diferentes — a seleção do melhor caminho diverge silenciosamente entre eles, sem nenhuma mensagem de erro para apontar.
[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 vendorsOs que aparecem quando hardware real dos dois fabricantes está de fato na mesma área OSPF.
SINTOMAVocê alterou o Router ID de um lado para resolver um conflito, o comando foi aceito sem erro, e o vizinho ainda não sobe — ou o Router ID antigo ainda aparece na saída display / show.
CAUSAEm ambas as plataformas, uma alteração de Router ID do OSPF só tem efeito após o reinício do processo OSPF — não no momento em que o comando é digitado. A configuração de origem mostra a Cisco retornando exatamente esta mensagem ao digitar o comando router-id: "% OSPF: Reload or use 'clear ip ospf process' command, for this to take effect." A Huawei se comporta da mesma forma, só que com um comando diferente.
SOLUÇÃONa Cisco, execute clear ip ospf process (ou reload) depois de alterar o router-id em router ospf. Na Huawei, execute reset ospf process-id process na visão de usuário depois de alterar o ospf router-id. Em nenhum dos fabricantes o novo Router ID entra em vigor sem isso.
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"SINTOMAEsta montagem não precisou de nenhuma configuração de tipo de rede. Em outra interoperabilidade, um roteador específico de terceiros simplesmente nunca forma uma relação de vizinho, enquanto todos os outros vizinhos OSPF na mesma rede interoperam bem.
CAUSATanto as interfaces Ethernet da Huawei quanto da Cisco usam por padrão o tipo de rede broadcast padrão, e é exatamente por isso que a montagem acima não precisou de nenhum comando network-type. A exceção é um par executando uma variante de tipo de rede específica de fabricante que parece um tipo OSPF padrão no papel, mas roda por baixo um mecanismo diferente e não padrão — os dois lados nunca estão de fato falando o mesmo dialeto OSPF.
SOLUÇÃOVerifique o tipo de rede em ambas as pontas e force as duas para um dos quatro tipos OSPF padrão (broadcast, P2P, NBMA, P2MP) com ospf network-type. Detalhes completos e um caso real estão em Solução de problemas de vizinhos OSPF.
SINTOMAUm roteador com prioridade ou Router ID mais alto foi adicionado a um segmento broadcast já estável, esperando que assumisse o papel de DR — e isso não aconteceu.
CAUSAA eleição DR/BDR tanto na Huawei quanto na Cisco não é preemptiva: uma vez eleitos um DR e um BDR, um novo roteador que entra depois — mesmo com prioridade ou Router ID mais alto — não desencadeia uma nova eleição. Ele entra como DR Other. Esse é o comportamento OSPF padrão em ambas as plataformas, não um bug de nenhum dos lados.
SOLUÇÃOSe o novo roteador realmente precisa ser DR, force deliberadamente uma nova eleição — alterne a interface (shutdown / undo shutdown na Huawei, shutdown / no shutdown na Cisco) ou reinicie o processo OSPF em todos os roteadores desse segmento. Faça isso em uma janela de manutenção: isso derruba todas as adjacências do segmento, não apenas a que você está alterando.
[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 equivalentSINTOMAO estado do vizinho é Full em ambos os fabricantes, as rotas para um prefixo estão presentes nos dois lados, mas o tráfego consistentemente segue um caminho diferente do esperado dadas as velocidades reais dos links.
CAUSAAlguém aumentou a largura de banda de referência em uma plataforma depois de adicionar links mais rápidos, para que o custo voltasse a refletir a capacidade real, mas não espelhou a mudança nos roteadores do outro fabricante na mesma área. As duas plataformas agora calculam valores de custo diferentes para os links físicos idênticos, e a seleção do melhor caminho diverge silenciosamente — sem nenhum erro em lugar nenhum, porque isso nunca afeta o estado da adjacência.
SOLUÇÃODefina a mesma largura de banda de referência em todos os roteadores da área, em ambos os fabricantes: bandwidth-reference no processo OSPF da Huawei, auto-cost reference-bandwidth em router ospf na Cisco. Trate isso como um parâmetro compartilhado para toda a área, não um ajuste individual por 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 vendorsSINTOMATudo parece correto na saída de comando de um lado, mas uma pergunta relacionada a DR/BDR não pode realmente ser respondida apenas com essa saída.
CAUSAO display ospf peer brief da Huawei confirma o estado do vizinho (Down/Init/2-Way/Full) por linha, mas não o papel DR/BDR — isso exige um display ospf interface separado. O show ip ospf neighbor da Cisco junta os dois em uma única coluna State (por exemplo FULL/DR ou FULL/BDR) em um único comando. Um engenheiro acostumado aos hábitos de uma plataforma pode consultar o comando errado no outro fabricante e simplesmente não ver a informação que procura.
SOLUÇÃOAo verificar um segmento de fabricantes mistos, obtenha ambos: display ospf peer brief mais display ospf interface do lado Huawei, show ip ospf neighbor do lado Cisco. Não presuma que o formato de saída de um comando conta toda a história na outra 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/DROTHERAs perguntas que surgem sempre que uma interoperabilidade OSPF Huawei-Cisco está de fato em pauta.
Não. As interfaces Ethernet de ambas as plataformas usam por padrão o tipo de rede broadcast, como a configuração de origem observa explicitamente nos três roteadores desta montagem. Você só precisa do comando quando o tipo de interface de um lado não é realmente broadcast.
A Cisco precisa de um comando reload ou clear ip ospf process depois de alterar o router-id — a CLI até imprime uma mensagem sobre isso. A Huawei precisa de reset ospf process-id process depois de alterar o ospf router-id. Em nenhum dos fabricantes o novo ID é aplicado só porque o comando foi aceito.
Não — nunca impede o estado Full e nunca aparece como erro. Apenas distorce a métrica de custo usada na seleção de caminho, e é exatamente por isso que é fácil de passar despercebido: o vizinho está saudável, as rotas estão presentes, e o único sintoma é o tráfego seguir um caminho que não corresponde às velocidades reais dos links.
Não. A eleição na Huawei e na Cisco não é preemptiva — uma vez eleitos um DR e um BDR no segmento, um roteador que entra depois com prioridade ou Router ID mais alto ainda entra como DR Other. Forçar uma nova eleição exige um reset deliberado de interface ou reinício do processo OSPF nesse segmento.
Esta nota assume que o estado Full já foi alcançado e trata das decisões de configuração ao redor disso. Para o fluxo completo de diagnóstico da máquina de estados — de Down a Full passando por Init, 2-Way, ExStart, Exchange, Loading, com os comandos display e as causas raiz de cada estado travado — veja Solução de problemas de vizinhos OSPF.
Esta nota é construída em torno de uma interoperabilidade OSPF real em rede broadcast entre Huawei AR e Cisco IOS, usando a configuração e a saída de verificação reais do próprio guia de interconexão da Huawei. Não cobre detalhes de interoperabilidade NBMA ou P2MP, OSPFv3/IPv6, links virtuais, nem sumarização ABR em um design multi-área de fabricantes mistos — cada um merece seu próprio artigo.
Envie-nos o tipo de rede, a saída display/show de ambas as pontas, e onde está divergindo — vamos ajudar a interpretar.