Inicio / Notas técnicas / Diagnóstico de ARP Miss del mapeo de NAT Server

El mapeo de NAT Server está muerto: el diagnóstico de ARP Miss

La entrada de server-map es correcta. La ruta es correcta. La entrada ARP es correcta. Y el mapeo sigue sin funcionar — porque precisamente que todas esas comprobaciones pasen es lo que hace que esta falla se esconda del orden de resolución de problemas obvio. Esta es la cadena de diagnóstico que profundiza un nivel más, hasta el contador del plano de reenvío que realmente nombra el problema.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Cuando todas las comprobaciones de configuración pasan y el mapeo aún no funciona

server-map normal, ruta normal, ARP normal — y el cliente en internet aún no puede llegar al servidor mapeado.

Un mapeo de NAT Server que simplemente no funciona es una de las fallas más desconcertantes en un router Huawei AR, precisamente porque las tres primeras cosas que cualquiera revisa — display firewall server-map nat-server, display ip routing-table, display arp — vuelven todas limpias. Si ya configuró NAT Server correctamente (vea nuestra guía de configuración de Easy IP para la puesta en marcha en sí), la falla no está en la definición del mapeo; está en algún lugar de la ruta de reenvío debajo de ella, y la forma más rápida de llegar es una verificación de la tabla de sesiones seguida de un contador de descarte de paquetes del plano de reenvío, no otra mirada a la configuración de NAT.

A continuación, esa cadena de diagnóstico en orden, las causas raíz que realmente revela, y respuestas de preguntas frecuentes de casos de campo sobre los comportamientos de NAT Server que siguen causando confusión.

Comprenda la cadena antes de volver a revisar el mapeo

Cuatro comprobaciones se ven completamente normales en esta falla, una por una, antes de que el descarte real aparezca en un contador del plano de reenvío que nadie piensa en revisar primero.

Esta es una cadena lineal, no una bifurcación — cada etapa confirma "no está aquí" y lo envía a la siguiente comprobación, o nombra la causa real y evita que vuelva a verificar una configuración que nunca fue el problema.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Las dos primeras etapas merecen confirmarse rápidamente y luego confiar en ellas — volver a revisar el server-map o la ruta por segunda y tercera vez después de que ya volvieron limpias es el mayor sumidero de tiempo en esta falla. La tabla de sesiones y el contador de reenvío son lo que realmente distingue "el mapeo está mal" de "el mapeo está bien pero el reenvío nunca llega a usarlo".

Recorriendo la cadena

Las dos primeras comprobaciones confirman que el mapeo no es el problema — las dos últimas prueban el descarte y lo nombran.

Etapas 1 y 2 — Confirmar que el mapeo y la ruta no son el problema

Tres comandos, todos limpios, y ninguno de ellos es donde realmente está la falla.

Ejecute display firewall server-map nat-server y confirme que existen tanto la entrada directa (Nat Server) como la inversa (Nat Server Reverse) para la dirección y el puerto mapeados.
Ejecute display ip routing-table para la dirección interna del servidor y confirme que una ruta se resuelve hacia la interfaz de salida correcta.
Ejecute display arp network para la dirección interna y confirme que existe una entrada dinámica con un MAC real — no Incomplete.
Si las tres vuelven limpias, deje de verificar la configuración NAT en sí y pase a la tabla de sesiones — este es el punto de la falla donde volver a leer las mismas tres salidas por segunda vez deja de ser útil.

<sysname> display firewall server-map nat-server
 Current Total Server-map : 2
 Type: Nat Server,  ANY -> 100.1.1.101[192.168.205.101],  Zone:---,  protocol:---
 Vpn: public -> public
 Type: Nat Server Reverse,  192.168.205.101[100.1.1.101] -> ANY,  Zone:---,  protocol:---
 Vpn: public -> public,  counter: 1
// both forward and reverse entries present -- mapping itself is fine

[sysname] display ip routing-table 192.168.205.101
Destination/Mask    Proto   Pre  Cost   Flags NextHop         Interface
192.168.205.0/24    Direct  0    0       D    192.168.205.1   10GE0/0/1
// route resolves correctly

[sysname] display arp network 192.168.205.101 32
IP ADDRESS      MAC ADDRESS    EXP(M) TYPE/VLAN   INTERFACE     VPN-INSTANCE
192.168.205.101 0000-c0a8-cd65   11   D           10GE0/0/1
// real MAC, not Incomplete -- ARP is fine too

Etapas 3 y 4 — Probar el descarte y nombrarlo

Aquí es donde la falla realmente se muestra — un nivel por debajo de todo lo que ya confirmó que estaba bien.

Desde fuera de la red, genere tráfico real hacia la dirección pública y el puerto mapeados (un intento de Telnet contra el puerto exacto basta), luego verifique si se creó una sesión para él. Ninguna sesión en absoluto confirma que el tráfico se está descartando en algún lugar de la ruta de reenvío, no enrutado erróneamente en silencio.
Active el contador de paquetes del plano de reenvío para el tráfico reenviado por CPU, límpielo, genere el tráfico de nuevo, luego léalo y observe específicamente ERROR_CNT_IPV4_ARPMISS y ERROR_CNT_BLACK_HOLE. Un contador de errores de ARP-Miss en aumento aquí — aunque display arp en sí se viera bien en la dirección interna — es la señal de que este tráfico nunca se resolvió al siguiente salto correcto.
Verifique directamente la configuración de la interfaz entrante con display this. Si nat enable falta en la interfaz que da al tráfico del lado público, esa es la respuesta: los paquetes destinados a la dirección mapeada nunca pasaron por la traducción de server-map — se reenviaron como una simple búsqueda IP para el destino público original, que no tiene ruta, de ahí el ARP Miss y el descarte de agujero negro.
Agregue nat enable bajo la interfaz y vuelva a probar con el mismo disparador Telnet; el mapeo comienza a funcionar de inmediato una vez que la traducción se aplica realmente al tráfico entrante.

<sysname> system-view
[sysname] diagnose
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag set pfa counter debug 0 1"
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag clear pfa counter 1"
// trigger the Telnet attempt against the mapped port here, then read the counter
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag show pfa counter all 1"
Module     |        error                      |          Value
[ 4]IPV4
           [   4]ERROR_CNT_IPV4_ARPMISS                       14
           [   6]ERROR_CNT_IPV4_NHP_DWN                       14
           [  62]ERROR_CNT_BLACK_HOLE                         37
// ARP Miss and black-hole counts climbing -- traffic never resolved to the right next hop

[sysname] interface 10GE0/0/1
[sysname-10GE0/0/1] display this
#
interface 10GE0/0/1
 ip address 100.1.1.100 255.255.255.0
 device transceiver 10GBASE-FIBER
#
// nat enable is missing here -- ingress traffic never went through server-map translation
[sysname-10GE0/0/1] nat enable

5 causas raíz que aparecen una y otra vez

Una vez que la cadena anterior le indica que el mapeo y la ruta nunca fueron el problema, estas cinco explican la mayor parte de lo que realmente falla.

1. Falta nat enable en la interfaz entrante

SÍNTOMAEl server-map, la ruta y el ARP para la dirección interna están todos limpios, pero nunca se crea ninguna sesión para el tráfico dirigido a la dirección pública mapeada, y el contador de errores de ARP-Miss del plano de reenvío sube cada vez que lo intenta.

CAUSALa entrada de server-map existe globalmente en el dispositivo, pero la traducción NAT solo se ejecuta realmente en una interfaz donde nat enable esté configurado. Sin ello, el tráfico destinado a la dirección pública mapeada se reenvía como una simple búsqueda IP contra esa dirección — que nunca estuvo destinada a ser enrutada a ningún lugar — en lugar de traducirse primero a la dirección interna.

SOLUCIÓNConfirme con display this en la interfaz de entrada, luego agregue nat enable.

[sysname-10GE0/0/1] display this
#
interface 10GE0/0/1
 ip address 100.1.1.100 255.255.255.0
#
[sysname-10GE0/0/1] nat enable

2. La sesión inversa de NAT Server tiene prioridad sobre una regla de denegación de source-NAT

SÍNTOMAEl tráfico en una dirección por la misma ruta funciona bien; la otra dirección falla, aunque la configuración de ambos extremos y el propio enlace se verifican bien — display ike sa (o el equivalente del túnel) muestra todo establecido.

CAUSAEl comportamiento automático de sesión inversa de NAT Server tiene prioridad sobre una política de source-NAT, incluso una que niega explícitamente traducir el tráfico protegido. La dirección privada se traduce a la dirección pública de todos modos en la ruta de retorno, rompiendo lo que esperaba que ese tráfico llegara sin traducir.

SOLUCIÓNConfigure no-reverse en el comando nat server cuando la dirección del lado del servidor solo deba traducirse en entrada, nunca en su propio tráfico saliente; verifique display firewall server-map para la entrada "Nat Server Reverse" y confirme que realmente está en juego.

[sysname2] nat server 0 protocol tcp global 2.1.1.10 3389 inside 10.1.2.2 3389 no-reverse

3. Falta la ruta de agujero negro para la dirección global

SÍNTOMASin síntoma evidente hasta que se profundiza — pero bajo carga, o tras un cambio de topología, el tráfico hacia la dirección global del NAT Server empieza a formar un bucle entre el dispositivo y el router aguas abajo en lugar de llegar al servidor.

CAUSACuando la dirección del pool NAT o la dirección global del NAT Server no está en la misma subred que la interfaz de salida, el dispositivo aún necesita que exista una ruta local para ella, de modo que un dispositivo aguas abajo no intente rebotar el tráfico coincidente. Sin una ruta de agujero negro, el dispositivo aguas abajo cree que el destino todavía es alcanzable a través del dispositivo y lo reenvía, formando un bucle.

SOLUCIÓNConfigure una ruta de agujero negro para la dirección global del NAT Server (o el rango del pool NAT) siempre que no esté en la misma subred que la interfaz de salida física — y considere una incluso cuando lo esté, ya que también evita que el dispositivo genere solicitudes ARP innecesarias para una dirección que en realidad nunca es un host real.

[sysname] ip route-static 100.1.1.101 255.255.255.255 NULL0

4. La dirección de destino de la política de seguridad es la posterior al NAT, no la original

SÍNTOMAEl mapeo y la ruta se ven correctos, pero el tráfico se sigue descartando, y el descarte solo se resuelve una vez que la política de seguridad/ACL se reescribe para referenciar la dirección privada del servidor en lugar de la pública.

CAUSALa traducción de NAT Server ocurre antes de la comprobación de la política de seguridad en el orden de reenvío — una vez que un paquete coincide con la entrada de server-map, su dirección de destino ya está reescrita a la dirección interna para cuando ocurre la evaluación de la política. Una política escrita contra el destino público original nunca coincidirá.

SOLUCIÓNEscriba la dirección de destino de la política de seguridad como la dirección privada (interna) del servidor, no la dirección pública configurada en el mapeo de NAT Server.

5. Ningún comando muestra directamente los conteos de coincidencia en el server-map o el pool NAT

SÍNTOMAQuiere confirmar que el tráfico realmente está impactando una entrada específica de NAT Server o pool, en lugar de simplemente existir como mapeo, y los comandos obvios no muestran un contador por entrada.

CAUSANo existe ningún comando display que informe directamente cuántos paquetes han coincidido con una entrada específica de NAT Server o pool de direcciones NAT.

SOLUCIÓNUse display nat-policy rule all en su lugar — reporta un contador HITS por regla de política NAT, que es el sustituto disponible más cercano para confirmar que una regla dada (y por extensión su server-map o pool asociado) realmente está siendo coincidida por tráfico real.

<sysname> display nat-policy rule all
Total:3
RULE ID  RULE NAME                  STATE        ACTION       HITS
1        test                       disable      no-nat          0
2        abc                        enable       src-nat         5
0        default                    enable       no-nat          0

Seis preguntas que surgen constantemente

Sacadas directamente del campo — las que merece la pena tener una respuesta lista.

¿Puedo usar la propia dirección IP de la interfaz del router como dirección global del NAT Server?

Técnicamente sí, pero evítelo. Una vez que esa IP de interfaz se convierte en la dirección global del NAT Server, cada paquete destinado a la propia interfaz se traduce primero a la dirección interna del servidor — lo que rompe el ping, la gestión Web y Telnet al dispositivo en esa dirección. Usar la IP de la interfaz para la traducción de source-NAT en su lugar no tiene este problema, ya que el tráfico iniciado activamente hacia la interfaz sigue el proceso del primer paquete y evita la política de source-NAT.

¿Hay un comando que muestre cuántas veces el tráfico realmente impactó una entrada específica de NAT Server?

No directamente. No hay un contador dedicado a una sola entrada de NAT Server o pool NAT. display nat-policy rule all es lo más cercano — reporta un conteo de HITS por regla de política NAT configurada.

¿Cuándo exactamente un despliegue de NAT necesita una ruta de agujero negro?

Dos casos: cuando el pool NAT o la dirección global de NAT Server está en una subred diferente a la interfaz de salida (obligatorio, para evitar un bucle de reenvío), y — vale la pena hacerlo de todos modos — incluso cuando está en la misma subred, ya que evita que el dispositivo genere solicitudes ARP inútiles para una dirección que nunca fue un host real.

El mapeo funciona para el acceso entrante pero el servidor no puede llegar a internet por sí solo — mismo NAT Server, ¿por qué la asimetría?

Este es el comportamiento no-reverse. Sin él, la sesión inversa automática de NAT Server traduce el propio tráfico saliente del servidor a la misma dirección pública que el mapeo — lo cual normalmente está bien. Pero si una política de source-NAT o un pool de direcciones diferente también está manejando el tráfico saliente de ese servidor, las dos traducciones no coinciden y las conexiones fallan; alinéelas a la misma dirección pública, o aplique no-reverse y configure NAT de salida explícitamente para ese host.

Nuestra política de seguridad referencia al servidor mapeado por su IP pública, y el tráfico sigue siendo bloqueado — ¿por qué?

Porque la traducción de NAT Server ocurre antes de la comprobación de la política de seguridad. Para cuando la política evalúa el paquete, el destino ya se ha convertido en la dirección privada interna. Apunte la dirección de destino de la política a la dirección interna en su lugar.

Ya tenemos una guía de configuración para Easy IP / NAT Server — ¿cuándo necesitamos esta nota en su lugar?

La guía de configuración lo lleva a un mapeo definido correctamente. Esta nota es para el caso en que la definición ya es correcta y el tráfico aún no llega — lo que casi siempre significa que la falla está un nivel más abajo, en si la traducción NAT realmente se está aplicando a la interfaz de entrada, o en un descarte del plano de reenvío que el propio mapeo no puede mostrarle.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en el modelo de fallas de NAT Server del router Huawei serie AR, los diagnósticos de server-map / forward information cpu-forward y los casos de campo que los respaldan. En otras plataformas, los contadores de descarte del plano de reenvío equivalentes están bajo comandos diferentes, pero la cadena subyacente — mapeo, ruta, ARP, sesión, descarte de reenvío, habilitación de NAT en la interfaz — se traslada directamente. No cubre en profundidad los despliegues de NAT Server con balanceo de carga o multiactivos, ni escenarios NAT64/NAT-PT.

¿El mapeo aún no funciona?

Envíenos su salida de display firewall server-map nat-server más qué etapa de esta cadena ha confirmado limpia, y le ayudamos a interpretar el resto.

WhatsApp con un ingeniero →