Um Spoke que nunca aparece na tabela de pares NHRP do Hub parece um único problema, mas o manual de manutenção da Huawei o trata como cinco ou seis candidatos escondidos atrás do mesmo sintoma. Aqui está o próprio fluxo de registro, os comandos display e debug para cada ponto de verificação, e os nomes exatos dos campos nos contadores que indicam qual é de fato.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O DSVPN tem quatro categorias amplas de falha no próprio manual de manutenção da Huawei — esta nota trata em profundidade a primeira, o registro de spoke para hub.
O manual de manutenção da série AR da Huawei agrupa as falhas de DSVPN em quatro sintomas amplos: falha de registro do Spoke junto ao Hub, inacessibilidade Spoke a Spoke em modo não-shortcut, inacessibilidade Spoke a Spoke em modo shortcut, e NHRP caindo depois de já ter sido estabelecido. Esta nota trata inteiramente da primeira categoria — falha de registro — porque é tanto o ponto de entrada mais comum quanto aquele que todas as outras categorias assumem já resolvido.
A seguir: o fluxo de registro pacote a pacote com saída debug real, a ordem de diagnóstico que o próprio fluxograma da Huawei segue, seis armadilhas de campo, e um FAQ extraído da própria seção de FAQ do DSVPN da Huawei.
Quatro pacotes, em ordem: a solicitação de registro do Spoke, o recebimento pelo Hub, a resposta do Hub, e o recebimento dessa resposta pelo Spoke. A saída debug abaixo é real, da própria referência de depuração de campo da Huawei.
Os rótulos do diagrama e os nomes dos campos debug são mantidos em inglês para clareza técnica.
PacketType 3 é uma solicitação de registro, PacketType 4 é uma resposta de registro. SrcNbmaAddr e SrcProtAddr identificam os endereços público e de túnel do Spoke; DstProtAddr é o endereço de túnel do Hub; Request ID vincula a solicitação à sua resposta correspondente. Se o próprio debug do Spoke mostrar que ele enviou a solicitação e depois recebeu uma resposta correspondente, mas nenhuma entrada de par NHRP jamais aparece — esse é o único caso em que o próprio guia da Huawei recomenda escalar diretamente para o desenvolvimento do NHRP, pois todas as causas de configuração documentadas já foram descartadas.
<Huawei>terminal monitor
<Huawei>terminal debugging
<Huawei>debugging timeout 0
<Huawei>debugging nhrp all
// turn off when done:
<Huawei>undo debugging all
<Huawei>undo terminal monitor
<Huawei>undo terminal debuggingSpoke sends the registration packet:
[NhrpPeerMng-Register] Send Nhrp packet info: PacketSize = 92, PacketType = 3,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3695974589.
Hub receives the registration packet:
[NhrpPeerMng-Register] Recv Nhrp packet info: PacketSize = 92, PacketType = 3,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3630044566.
Hub replies to the registration:
[NhrpPeerMng-Register] Send Nhrp packet info: PacketSize = 112, PacketType = 4,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3630044566.
Spoke receives the Hub's reply:
[NhrpPeerMng-Register] Recv Nhrp packet info: PacketSize = 112, PacketType = 4,
SrcNbmaAddr = 173.16.1.6, SrcProtAddr = 192.168.3.3, DstProtAddr = 192.168.3.1,
Request ID = 3695974589.
// if the Spoke received the reply but the NHRP peer entry still never forms,
// escalate to NHRP development -- every configuration-level cause is ruled outEste é o próprio fluxograma da Huawei para a falha de registro de spoke para hub, em ordem — cada etapa descarta uma camada antes de passar para a próxima.
<Spoke> interface Tunnel0/0/0
[Spoke-Tunnel0/0/0] undo ipsec profile
[Spoke-Tunnel0/0/0] quit
<Spoke> display ip routing-table
<Hub> display ip routing-table
// confirm each side has a route to the other's NBMA address
<Hub> display interface Tunnel0/0/0
<Spoke> display interface Tunnel0/0/0
// if state is down: undo shutdown
<Hub> display this
<Spoke> display this
// compare nhrp authentication and gre key line by line
<Hub> display nhrp peer
<Hub> reset nhrp statistics interface Tunnel 0/0/0
<Spoke> reset nhrp statistics interface Tunnel 0/0/0
// trigger a fresh registration from the Spoke, then:
<Spoke> display nhrp statistics interface Tunnel 0/0/0
// check RegisterRequestSendSuccess and RegisterReplyCorrectRecv
[Spoke-Tunnel0/0/0] ipsec profile ipsec1
<Spoke> display ipsec saCada uma delas vem diretamente das seções de tratamento de falhas de DSVPN e FAQ da própria Huawei — nada aqui é inventado.
SINTOMAA alcançabilidade NBMA é confirmada como boa, a interface Tunnel está up em ambas as pontas, e o Spoke ainda assim nunca registra — sem nenhuma mensagem de erro apontando o motivo.
CAUSAEsta é uma das causas raiz comuns que o próprio manual da Huawei lista para a falha de registro: a chave GRE configurada na interface de túnel do Spoke não corresponde à do Hub. Como a verificação da chave GRE acontece silenciosamente na camada de encapsulamento do túnel, nada nos logs em nível de NHRP a aponta diretamente.
SOLUÇÃOCompare o valor de gre key nas interfaces de túnel do Hub e do Spoke com display this, e alinhe-os com o comando gre key. Faça isso antes de gastar tempo com contadores específicos do NHRP — é uma verificação de uma linha que descarta uma categoria inteira de falhas.
SINTOMAO mesmo cenário do caso da chave GRE — o roteamento está bom, o túnel está up, o registro simplesmente nunca se completa.
CAUSAO manual da Huawei lista isso como uma causa distinta própria: o Hub tem uma string de autenticação NHRP configurada, mas o Spoke não, ou os dois lados configuraram strings diferentes. De qualquer forma, o efeito é idêntico a uma incompatibilidade de chave GRE visto de fora — falha de registro silenciosa sem erro óbvio.
SOLUÇÃOCompare nhrp authentication em ambas as pontas via display this sob a interface tunnel/MGRE, e alinhe-os com o comando nhrp authentication. Verifique isso junto com a chave GRE na mesma passagem — ambas são verificações de consistência de configuração na mesma etapa.
SINTOMAO Spoke envia sua solicitação de resolução/registro com sucesso e o Hub até gera um candidato de entrada de par, mas a tabela de pares NHRP no Hub nunca chega a se completar de fato para aquele Spoke.
CAUSAEsta é uma falha real que o próprio manual da Huawei documenta diretamente: quando o protocolo de segurança IPSec usa SHA-2, e as duas pontas do túnel têm ipsec authentication sha2 compatible configurado em apenas um lado, o registro falha. Isso importa principalmente entre fabricantes diferentes ou versões de produto diferentes, onde os detalhes de implementação do SHA-2 podem diferir o suficiente para exigir o sinalizador de compatibilidade em ambas as pontas.
SOLUÇÃOVerifique se ipsec authentication sha2 compatible enable está configurado em ambas as pontas sempre que a proposta IPSec usar SHA-2 — não apenas em uma. Execute display ipsec sa para confirmar que a SA realmente se forma quando ambos os lados coincidem.
<Hub> ipsec authentication sha2 compatible enable
<Spoke> ipsec authentication sha2 compatible enable
// must be configured on BOTH ends when the IPSec proposal uses SHA-2
<Hub> display ipsec saSINTOMAUm caso real documentado: DSVPN sobre IPSec, o Hub usa interfaces Tunnel separadas por Spoke, e a negociação IKE falha completamente — display ike sa no Hub mostra a SA travada no estado NEG (negociando) sem nunca chegar a RD (pronta).
CAUSAO debug no Hub (debugging ipsec all / debugging ikev1 all) mostrou diretamente a causa real: "IKE check ike peer same, the binding ike peer is different" — as duas interfaces Tunnel do Hub usavam o mesmo endereço IP de origem (1.1.1.1) mas apontavam para perfis IPSec diferentes, então o IKE não conseguia resolver qual identidade de par se aplicava à negociação de qual Spoke.
SOLUÇÃOConfigure uma ike identity por Spoke (baseada em fqdn funciona bem), referencie-a no ipsec profile de cada Tunnel com match ike-identity, e configure uma gre key distinta por interface Tunnel para manter o tráfego NHRP isolado entre elas. O ike peer de cada Spoke então usa local-id-type fqdn com um local-id correspondente.
<Hub> terminal debugging
<Hub> terminal monitor
<Hub> debugging ipsec all
<Hub> debugging ikev1 all
IKE/7/IKE_Debug Info:5:2607 IKE check ike peer same, get ike peer name (peer-name = ipsec1, ifindex = 18).
IKE/3/IKE_Debug Error:5:2628 IKE check ike peer same, the binding ike peer is different(ifindex = 27, peer name = ipsec3).
[Hub] interface Tunnel0/0/0
[Hub-Tunnel0/0/0] ip address 10.17.1.1 255.255.255.0
[Hub-Tunnel0/0/0] tunnel-protocol gre p2mp
[Hub-Tunnel0/0/0] source vpn-instance test 1.1.1.1
[Hub-Tunnel0/0/0] ipsec profile ipsec1
[Hub-Tunnel0/0/0] gre key cipher AAA
[Hub-Tunnel0/0/0] quit
[Hub] interface Tunnel0/0/100
[Hub-Tunnel0/0/100] ip address 100.17.1.1 255.255.255.0
[Hub-Tunnel0/0/100] tunnel-protocol gre p2mp
[Hub-Tunnel0/0/100] source vpn-instance test 1.1.1.1
[Hub-Tunnel0/0/100] ipsec profile ipsec2
[Hub-Tunnel0/0/100] gre key cipher BBB
[Hub-Tunnel0/0/100] quit
[Hub] ike identity i1
[Hub-ike-identity-i1] fqdn spoke1
[Hub] ipsec profile ipsec1
[Hub-ipsec-profile-ipsec1] ike-peer ipsec1
[Hub-ipsec-profile-ipsec1] match ike-identity i1
<Spoke1> ike peer ipsec1
[Spoke1-ike-peer-ipsec1] local-id-type fqdn
[Spoke1-ike-peer-ipsec1] local-id spoke1SINTOMATodos os parâmetros de configuração conferem — chave GRE, autenticação NHRP, perfil IPSec — e o Spoke ainda assim não registra.
CAUSAA própria interface Tunnel está administrativamente desligada em uma ponta — um passo fácil de pular porque os engenheiros presumem que, se o túnel estivesse down, outra coisa também estaria obviamente errada. É exatamente por isso que ela aparece como o passo 3 no próprio fluxo de diagnóstico da Huawei.
SOLUÇÃOExecute display interface interface-type interface-number tanto no Hub quanto no Spoke e verifique o estado real, não apenas suposições baseadas em sintomas de camadas superiores. undo shutdown se estiver down. Faça isso cedo — é o passo 3 na ordem de diagnóstico acima, antes das verificações de consistência de configuração.
<Hub> display interface Tunnel0/0/0
<Spoke> display interface Tunnel0/0/0
[Spoke-Tunnel0/0/0] undo shutdownSINTOMANão é exatamente uma falha de registro — o registro eventualmente tem sucesso, mas de forma perceptivelmente lenta após uma mudança de endereço de origem do Spoke, ou após uma oscilação da interface Tunnel.
CAUSAPor padrão, um Spoke se registra novamente no Hub a cada 1800 segundos, e o holdtime de uma entrada de par NHRP também é de 1800 segundos por padrão. Ambos são deliberadamente conservadores, mas isso significa que, após um evento desencadeador — como um shutdown/undo shutdown do Tunnel, ou uma mudança no endereço público do Spoke — a entrada obsoleta não é limpa e a nova não é estabelecida até que esses padrões se esgotem, a menos que algo force isso antes.
SOLUÇÃOConfigure nhrp registration no-unique no Spoke para que ele diga explicitamente ao Hub para sobrescrever uma entrada de par NHRP conflitante em vez de esperar que ela expire. Ajuste para baixo o nhrp entry holdtime seconds e o intervalo de re-registro se seu ambiente muda endereços de origem com frequência suficiente para que os padrões causem atraso perceptível.
<Spoke> nhrp registration no-unique
<Spoke> nhrp entry holdtime 7200
// defaults: 1800s re-registration interval, 1800s NHRP peer holdtimeExtraído diretamente da própria seção de FAQ do DSVPN da Huawei.
A ativação da licença. Execute display license accept agreement e display license state — alguns modelos de roteador AR exigem uma licença DSVPN comprada, e se ela não estiver ativa, display nhrp peer all informará a licença como desativada em vez de mostrar entradas de par, não importa quão correto esteja o restante da configuração.
<Huawei> display license accept agreement
Active license Accept Agreement: yes
Item name : LAR0DSVPN04
Item type : Function
Item state : Disable, -
Item left time :-
Item used time :-
Description : DSVPN Function Controller
<Huawei> display license state
Info: No license actived on master board.
<Huawei> display nhrp peer all
Info: DSVPN or SECE License is disable, please check availability of the license
and load new license.
Number of nhrp peers: 0Em ordem: status da licença, alcançabilidade de rota da interface de origem, se a ponta remota realmente recebeu o pacote, consistência da chave GRE e da autenticação NHRP, compatibilidade IPSec/SHA-2 se o IPSec estiver em camada sobreposta, se outra interface Tunnel na mesma caixa referencia a mesma origem (precisa de isolamento com gre key), e NAT no Hub se houver um (o Spoke deve se registrar no endereço pós-NAT do Hub).
Zere os contadores e verifique display nhrp statistics interface depois de disparar um novo registro. Se RegisterRequestSendSuccess não mostrar contagem, o Spoke nem está conseguindo enviar a solicitação — verifique primeiro a interface local e a rota. Se RegisterRequestSendSuccess tiver contagem mas RegisterReplyCorrectRecv não, a solicitação saiu bem mas nenhuma resposta válida voltou — verifique a configuração do Hub e o caminho de retorno.
Porque a antiga entrada de par NHRP do Hub para aquele Spoke não é sobrescrita imediatamente por padrão — ela expira pelo seu próprio temporizador holdtime, que é de 1800 segundos a menos que ajustado. Configure nhrp registration no-unique no Spoke para que ele diga explicitamente ao Hub para sobrescrever a entrada conflitante em vez de esperar.
Não — essa é uma categoria de falha diferente no próprio manual da Huawei (inacessibilidade Spoke a Spoke não-shortcut ou shortcut, dependendo do seu modo DSVPN), e ela assume que o registro já teve sucesso, que é exatamente o que esta nota cobre. Merece seu próprio artigo separado.
Esta nota é construída inteiramente em torno da falha de registro de spoke para hub, usando o fluxo de diagnóstico real, a saída debug real e casos de falha reais do próprio manual de manutenção da série AR da Huawei. Não cobre a inacessibilidade Spoke a Spoke não-shortcut ou shortcut, nem o NHRP caindo depois de já ter sido estabelecido — essas são categorias de falha separadas no mesmo manual, cada uma merecendo sua própria nota.
Envie-nos os contadores RegisterRequestSendSuccess / RegisterReplyCorrectRecv e a saída de display nhrp peer de ambas as pontas — vamos ajudar a interpretar.