Un Spoke que nunca aparece en la tabla de pares NHRP del Hub parece un solo problema, pero el manual de mantenimiento de Huawei lo trata como cinco o seis candidatos escondidos detrás del mismo síntoma. Aquí está el flujo de registro en sí, los comandos display y debug para cada punto de control, y los nombres exactos de los campos en los contadores que indican cuál es realmente.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
DSVPN tiene cuatro categorías amplias de fallos en el propio manual de mantenimiento de Huawei — esta nota trata en profundidad la primera, el registro de spoke a hub.
El manual de mantenimiento de la serie AR de Huawei agrupa los fallos de DSVPN en cuatro síntomas amplios: el fallo de registro del Spoke ante el Hub, la inalcanzabilidad Spoke a Spoke en modo no-shortcut, la inalcanzabilidad Spoke a Spoke en modo shortcut, y NHRP cayéndose después de haberse establecido previamente. Esta nota trata por completo la primera categoría — el fallo de registro — porque es tanto el punto de entrada más común como el que todas las demás categorías asumen ya resuelto.
A continuación: el flujo de registro paquete a paquete con salida debug real, el orden de diagnóstico que sigue el propio diagrama de flujo de Huawei, seis trampas de campo, y una FAQ extraída de la propia sección de FAQ de DSVPN de Huawei.
Cuatro paquetes, en orden: la solicitud de registro del Spoke, su recepción por el Hub, la respuesta del Hub, y la recepción de esa respuesta por el Spoke. La salida debug de abajo es real, de la propia referencia de depuración de campo de Huawei.
Las etiquetas del diagrama y los nombres de campos debug se mantienen en inglés por claridad técnica.
PacketType 3 es una solicitud de registro, PacketType 4 es una respuesta de registro. SrcNbmaAddr y SrcProtAddr identifican las direcciones pública y de túnel del Spoke; DstProtAddr es la dirección de túnel del Hub; Request ID vincula la solicitud con su respuesta correspondiente. Si el propio debug del Spoke muestra que envió la solicitud y luego recibió una respuesta correspondiente, pero nunca aparece ninguna entrada de par NHRP — ese es el único caso en que la propia guía de Huawei recomienda escalar directamente al desarrollo de NHRP, porque ya se descartaron todas las causas de configuración documentadas.
<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 es el propio diagrama de flujo de Huawei para el fallo de registro de spoke a hub, en orden — cada paso descarta una capa antes de pasar a la siguiente.
<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 una de estas proviene directamente de las secciones de manejo de fallos de DSVPN y FAQ propias de Huawei — nada aquí está inventado.
SÍNTOMALa alcanzabilidad NBMA se confirma correcta, la interfaz Tunnel está up en ambos extremos, y el Spoke sigue sin registrarse nunca — sin ningún mensaje de error que indique por qué.
CAUSAEsta es una de las causas raíz comunes que el propio manual de Huawei enumera para el fallo de registro: la clave GRE configurada en la interfaz de túnel del Spoke no coincide con la del Hub. Como la verificación de la clave GRE ocurre silenciosamente en la capa de encapsulación del túnel, nada en los registros a nivel de NHRP la señala directamente.
SOLUCIÓNCompare el valor de gre key en las interfaces de túnel del Hub y del Spoke con display this, y alinéelos con el comando gre key. Haga esto antes de dedicar tiempo a los contadores específicos de NHRP — es una verificación de una línea que descarta toda una categoría de fallos.
SÍNTOMAEl mismo panorama que el caso de la clave GRE — el enrutamiento está bien, el túnel está up, el registro simplemente nunca se completa.
CAUSAEl manual de Huawei enumera esto como una causa distinta propia: el Hub tiene una cadena de autenticación NHRP configurada pero el Spoke no, o ambos lados configuraron cadenas diferentes. De cualquier manera, el efecto es idéntico a una falta de coincidencia de clave GRE visto desde afuera — fallo de registro silencioso sin error evidente.
SOLUCIÓNCompare nhrp authentication en ambos extremos mediante display this bajo la interfaz tunnel/MGRE, y alinéelos con el comando nhrp authentication. Revise esto junto con la clave GRE en la misma pasada — ambas son verificaciones de consistencia de configuración en el mismo paso.
SÍNTOMAEl Spoke envía su solicitud de resolución/registro con éxito y el Hub incluso genera un candidato de entrada de par, pero la tabla de pares NHRP en el Hub nunca llega a completarse realmente para ese Spoke.
CAUSAEsta es una falla real que el propio manual de Huawei documenta directamente: cuando el protocolo de seguridad IPSec usa SHA-2, y los dos extremos del túnel tienen ipsec authentication sha2 compatible configurado solo en un lado, el registro falla. Esto importa sobre todo entre diferentes fabricantes o diferentes versiones de producto, donde los detalles de implementación de SHA-2 pueden diferir lo suficiente como para necesitar el indicador de compatibilidad en ambos extremos.
SOLUCIÓNCompruebe si ipsec authentication sha2 compatible enable está configurado en ambos extremos siempre que la propuesta IPSec use SHA-2 — no solo en uno. Ejecute display ipsec sa para confirmar que la SA realmente se forma una vez que ambos lados coinciden.
<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 saSÍNTOMAUn caso real documentado: DSVPN sobre IPSec, el Hub usa interfaces Tunnel separadas por Spoke, y la negociación IKE falla por completo — display ike sa en el Hub muestra la SA atascada en estado NEG (negociando) sin llegar nunca a RD (lista).
CAUSAEl debug en el Hub (debugging ipsec all / debugging ikev1 all) mostró directamente la causa real: "IKE check ike peer same, the binding ike peer is different" — las dos interfaces Tunnel del Hub usaban la misma dirección IP de origen (1.1.1.1) pero apuntaban a perfiles IPSec diferentes, por lo que IKE no podía resolver qué identidad de par se aplicaba a la negociación de cada Spoke.
SOLUCIÓNConfigure una ike identity por Spoke (basada en fqdn funciona bien), referéncielá en el ipsec profile de cada Tunnel con match ike-identity, y configure una gre key distinta por interfaz Tunnel para mantener el tráfico NHRP aislado entre ellas. El ike peer de cada Spoke entonces usa local-id-type fqdn con un local-id correspondiente.
<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 spoke1SÍNTOMATodos los parámetros de configuración coinciden — clave GRE, autenticación NHRP, perfil IPSec — y el Spoke sigue sin registrarse.
CAUSALa propia interfaz Tunnel está administrativamente desactivada en un extremo — un paso fácil de omitir porque los ingenieros suponen que si el túnel estuviera caído, algo más también estaría claramente mal. Precisamente por eso figura como paso 3 en el propio flujo de diagnóstico de Huawei.
SOLUCIÓNEjecute display interface interface-type interface-number tanto en el Hub como en el Spoke y compruebe el estado real, no solo suposiciones basadas en síntomas de capas superiores. undo shutdown si está caído. Hágalo temprano — es el paso 3 en el orden de diagnóstico anterior, antes de las verificaciones de consistencia de configuración.
<Hub> display interface Tunnel0/0/0
<Spoke> display interface Tunnel0/0/0
[Spoke-Tunnel0/0/0] undo shutdownSÍNTOMANo es exactamente un fallo de registro — el registro finalmente tiene éxito, pero notablemente lento tras un cambio de dirección de origen del Spoke, o tras una caída/reinicio de la interfaz Tunnel.
CAUSAPor defecto, un Spoke se vuelve a registrar ante el Hub cada 1800 segundos, y el holdtime de una entrada de par NHRP también es de 1800 segundos por defecto. Ambos son deliberadamente conservadores, pero significan que después de un evento desencadenante — como un shutdown/undo shutdown del Tunnel, o un cambio de dirección pública del Spoke — la entrada obsoleta no se limpia y la nueva no se establece hasta que esos valores por defecto terminan de transcurrir, a menos que algo lo fuerce antes.
SOLUCIÓNConfigure nhrp registration no-unique en el Spoke para que le indique explícitamente al Hub que sobrescriba una entrada de par NHRP en conflicto en lugar de esperar a que expire. Ajuste a la baja nhrp entry holdtime seconds y el intervalo de reregistro si su entorno cambia direcciones de origen con la frecuencia suficiente para que los valores por defecto causen un retraso notable.
<Spoke> nhrp registration no-unique
<Spoke> nhrp entry holdtime 7200
// defaults: 1800s re-registration interval, 1800s NHRP peer holdtimeExtraído directamente de la propia sección de FAQ de DSVPN de Huawei.
La activación de la licencia. Ejecute display license accept agreement y display license state — algunos modelos de router AR requieren una licencia DSVPN comprada, y si no está activa, display nhrp peer all informará que la licencia está deshabilitada en lugar de mostrar entradas de par, sin importar lo correcto que esté el resto de la configuración.
<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: 0En orden: estado de la licencia, alcanzabilidad de ruta de la interfaz de origen, si el extremo remoto realmente recibió el paquete, consistencia de la clave GRE y la autenticación NHRP, compatibilidad IPSec/SHA-2 si IPSec está en capas encima, si otra interfaz Tunnel en el mismo equipo referencia el mismo origen (necesita aislamiento con gre key), y NAT en el Hub si hay uno presente (el Spoke debe registrarse en la dirección post-NAT del Hub).
Ponga los contadores a cero y compruebe display nhrp statistics interface tras activar un nuevo registro. Si RegisterRequestSendSuccess no muestra conteo, el Spoke ni siquiera está sacando la solicitud — revise primero la interfaz local y la ruta. Si RegisterRequestSendSuccess tiene conteo pero RegisterReplyCorrectRecv no, la solicitud salió bien pero no volvió ninguna respuesta válida — revise la configuración del Hub y la ruta de retorno.
Porque la antigua entrada de par NHRP del Hub para ese Spoke no se sobrescribe de inmediato por defecto — expira según su propio temporizador holdtime, que es de 1800 segundos a menos que se ajuste. Configure nhrp registration no-unique en el Spoke para que le indique explícitamente al Hub que sobrescriba la entrada en conflicto en lugar de esperar.
No — esa es una categoría de fallo distinta en el propio manual de Huawei (inalcanzabilidad Spoke a Spoke no-shortcut o shortcut, según su modo DSVPN), y asume que el registro ya tuvo éxito, que es exactamente lo que cubre esta nota. Merece su propio análisis por separado.
Esta nota se construye enteramente en torno al fallo de registro de spoke a hub, usando el flujo de diagnóstico real, la salida debug real y casos de fallo reales del propio manual de mantenimiento de la serie AR de Huawei. No cubre la inalcanzabilidad Spoke a Spoke no-shortcut o shortcut, ni el NHRP cayéndose después de haberse establecido previamente — esas son categorías de fallo separadas en el mismo manual, cada una merecedora de su propia nota.
Envíenos los contadores RegisterRequestSendSuccess / RegisterReplyCorrectRecv y la salida de display nhrp peer de ambos extremos — le ayudaremos a interpretarlo.