Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

La implementación de IDPA falló con el error "Reverse lookup failed"

Summary: La implementación de IDPA falló con el error "Reverse lookup failed"

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Symptoms

Versión de software afectada:      
2.5 y versiones

anteriores Problema:       
La implementación inicial de IDPA falla en la fase de configuración de red del dispositivo con el siguiente error de flujo de trabajo:
Configuración de la red del dispositivo. [Paso 1 de 4] Configuración de la red del Administrador de configuración del dispositivo. [Paso 1 de 4] Se completó la configuración de red del Administrador de configuración del dispositivo. [Paso 2 de 4] Se inició la validación de la configuración de red. [Paso 2 de 4] Falló la validación de la configuración de red. Falló la configuración de red del dispositivo.

Error detallado:       
(Nota: x.x.x.11 es una IP pública de ACM y x.x.x.12 es una IP pública de ESXi)
La búsqueda inversa falló para x.x.x.11 con el servidor de nombre de dominio primario x.x.x.240.
La búsqueda inversa falló para x.x.x.12 con el servidor de nombre de dominio primario x.x.x.240.

  • Comprobación de la herramienta NVT aprobada
  • nslookup funciona bien para la búsqueda de DNS directa e inversa
  • Utilice la utilidad dnsjava de ACM para realizar una búsqueda de DNS fallida:
dpappliance-acm:~ # java -cp /usr/local/dataprotection/tomcat/webapps/dataprotection/WEB-INF/lib/vcedpa-externalutil-2.4.0.jar com.emc.vcedpa.network.IPResolveUtil x.x.x.240 x.x.x.11 Entrada: DNS[x.x.x.240], dirección IP [x.x.x.11]. Hostname: x.x.x.11 La búsqueda inversa falló.
Compare el resultado de nslookup de la misma consulta dns que se realizó correctamente:
dpappliance-acm:~ # nslookup x.x.x.11 Servidor: x.x.x.240 Dirección: x.x.x.240#53 11.x.x.x.in-addr.arpa name = dp4400-acm.sample.local.  
Prueba #1: la salida de tcpdump muestra una búsqueda de DNS fallida. El servidor DNS x.x.x.240 no respondió a la consulta "ANY": ================================================================================= De ACM, capturamos el tráfico de red de la siguiente consulta dns dnsjava mediante la ejecución de:
dpappliance-acm:~ # java -cp /usr/local/dataprotection/tomcat/webapps/dataprotection/WEB-INF/lib/vcedpa-externalutil-2.4.0.jar com.emc.vcedpa.network.IPResolveUtil x.x.x.240 x.x.x.11 Entrada: DNS[x.x.x.240], dirección IP [x.x.x.11]. Nombre de host: x.x.x.11 Búsqueda inversa fallida. dpappliance-acm:~ # nslookup x.x.x.11 Servidor: x.x.x.240 Dirección: x.x.x.240#53 11.x.x.x.in-addr.arpa name = dp4400-acm.sample.local. dpappliance-acm:~ # tcpdump -s 0 -i eth1 host x.x.x.240 -vvvv tcpdump: escuchar en eth1, tipo de enlace EN10MB (Ethernet), tamaño de captura 262144 bytes 01:18:07.955334 IP (tos 0x0, ttl 64, id 49262, compensación 0, marcas [DF], proto UDP (17), longitud 69) dp4400-acm.sample.local.48611 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x2be5!] ¿Más de 33132 PTR? 11.x.x.x.IN-ADDR.ARPA. (41) 01:18:07.955914 IP (tos 0x0, ttl 64, id 49263, offset 0, marcas [DF], proto UDP (17), length 71) dp4400-acm.sample.local.33633 > x.x.x.240.domain: [bad udp cksum 0x2058 -> 0xa78f!] ¿Más de 39491 PTR? 240.10.10.10.in-addr.arpa. (43) IP 01:18:07.956517 (tos 0x0, ttl 49, id 65199, offset 0, flags [none], proto UDP (17), length 139) x.x.x.240.domain > dp4400-acm.sample.local.48611: [Udp sum ok] 33132* q: ¿PTR? 11.x.x.x.IN-ADDR.ARPA. 1/1/1 11.x.x.x.IN-ADDR.ARPA. [1h] PTR dp4400-acm.sample.local. Ns: 10.IN ADDR. ARPA. [1 h] NS ns.10.IN-ADDR.ARPA. ar: ns.10.IN-ADDR.ARPA. [1 h] A 127.0.0.1 (111) 01:18:07.956815 IP (tos 0x0, ttl 49, id 46189, compensación 0, marcas [none], proto UDP (17), longitud 115) x.x.x.240.domain > dp4400-acm.sample.local.33633: [udp sum ok] 39491 NXDomain* q: ¿PTR? 240.10.10.10.in-addr.arpa. 0/1/0 ns: 10.in-addr.arpa. [30 m] SOA ns.10.in-addr.arpa. mail.10.in-addr.arpa. 102 28800 3600 604800 1800 (87) 01:18:07.956966 IP (0x0, ttl 64, id 49264, compensación 0, marcas [DF], proto UDP (17), longitud 69) dp4400-acm.sample.local.57840 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x71f6!] 30381+ ¿PTR? 11.x.x.x.in-addr.arpa. (41) 01:18:07.957783 IP (tos 0x0, ttl 49, id 14608, offset 0, marcas [none], proto UDP (17), length 139) x.x.x.240.domain > dp4400-acm.sample.local.57840: [udp sum ok] 30381* q: ¿PTR? 11.x.x.x.in-addr.arpa. 1/1/1 11.x.x.x.in-addr.arpa. [1h] PTR dp4400-acm.sample.local. Ns: 10.in-addr.arpa. [1 h] NS ns.10.in-addr.arpa. ar: ns.10.in-addr.arpa. [1 h] A 127.0.0.1 (111) 01:18:07.959536 IP (tos 0x0, ttl 64, id 49265, compensación 0, marcas [DF], proto UDP (17), longitud 69) dp4400-acm.sample.local.60791 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x4144!] ¿61612+ ANY? dp4400-acm.sample.local. (41)  01:18:08.960896 IP (tos 0x0, ttl 64, id 49284, offset 0, marcas [DF], proto UDP (17), longitud 69)dp4400-acm.sample.local.47615 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x74bc!] ¿61612+ ANY? dp4400-acm.sample.local. (41) 01:18:10.963164 IP (tos 0x0, ttl 64, id 49516, offset 0, marcas [DF], proto UDP (17), length 69)dp4400-acm.sample.local.50636 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x68ef!] ¿61612+ ANY? dp4400-acm.sample.local. (41) IP 01:18:14.967449 (tos 0x0, ttl 64, id 49830, offset 0, flags [DF], proto UDP (17), length 69)dp4400-acm.sample.local.44092 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x827f!] ¿61612+ ANY? dp4400-acm.sample.local. (41) ^C 10 paquetes capturaron 10 paquetes recibidos por el filtro 0 paquetes descartados por el kernel
Prueba #2:la salida de tcpdump muestra una búsqueda de DNS correcta. Otro servidor DNS x.x.x.101 respondió a la consulta "ANY": ==================================================================================== de ACM, capturamos tráfico para la siguiente ejecución del comando (x.x.x.101 es un partner de servidor DNS de prueba creado en una VM):
dpappliance-acm:~ # java -cp /usr/local/dataprotection/tomcat/webapps/dataprotection/WEB-INF/lib/vcedpa-externalutil-2.4.0.jar com.emc.vcedpa.network.IPResolveUtil x.x.x.101 x.x.x.11 Entrada: DNS[x.x.x.101], dirección IP[x.x.x.11]. Nombre de host: dp4400-acm.sample.local Búsqueda inversa correcta.. Nombre de host: dp4400-acm.sample.local Dirección IP: x.x.x.11 Búsqueda directa correcta. Dirección IP: x.x.x.11dpappliance-acm:~ # tcpdump -s 0 -i eth1 host 10.15.1.101 -vvvv tcpdump: escuchar en eth1, tipo de enlace EN10MB (Ethernet), tamaño de captura 262144 bytes 01:20:01.368557 IP (tos 0x0, ttl 64, id 4344, compensación 0, marcas [DF], proto UDP (17), longitud 69) dp4400-acm.sample.local.54907 > 10.15.1.101.domain: [bad udp cksum 0x16d0 -> 0xe01c!] ¿Más de 48 674 PTR? 11.x.x.x.IN-ADDR.ARPA. (41) ARP 01:20:01.376214, Ethernet (len 6), IPv4 (len 4), Request who-has dp4400-acm.sample.local tell 10.15.1.101, longitud 46 01:20:01.376222 ARP, Ethernet (len 6), IPv4 (len 4), Reply dp4400-acm.sample.local is-at 00:0c:29:93:b3:a0 (oui Unknown), longitud 28 01:20:01.376477 IP (tos 0x0, ttl 128, id 4475, compensación 0, marcas [none], proto UDP (17), longitud 106) 10.15.1.101.domain > dp4400-acm.sample.local.54907: [Udp sum ok] 48674* q: ¿PTR? 11.x.x.x.IN-ADDR.ARPA. 0/1/0 11.x.x.x.IN-ADDR.ARPA. [1h] PTR dp4400-acm.sample.local. (78) 01:20:01.378905 IP (0x0 ttl 64, id 4346, compensación 0, marcas [DF], proto UDP (17), longitud 69) dp4400-acm.sample.local.55796 > 10.15.1.101.domain: [bad udp cksum 0x16d0 -> 0x948b!] 47726+ ¿ALGUNA? dp4400-acm.sample.local. (41) IP 01:20:01.379318 (0x0 ttl 128, id 4476, compensación 0, marcas [DF], proto UDP (17), longitud 85) 10.15.1.101.domain > dp4400-acm.sample.local.55796: [udp sum ok] 47726* q: ¿ALGUNA? dp4400-acm.sample.local. 1/0/0 dp4400-acm.sample.local. [1h] A 10.15.1.11 (57) 01:20:06.393279 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.15.1.101 tell dp4400-acm.sample.local, longitud 28 01:20:06.394227 ARP, Ethernet (len 6), IPv4 (len 4), Respuesta 10.15.1.101 is-at 00:0c:29:6f:47:b6 (oui desconocido), longitud 46

Cause

Con el módulo de cliente DNS actual de ACM de IDPA: dnsjava (v2.4 o anterior), envía la consulta "ANY" de DNS al servidor DNS para realizar una búsqueda inversa. La mayoría de los servidores DNS pueden responder correctamente a la consulta "ANY", pero para los servidores DNS que no pueden procesar la consulta "ANY", la búsqueda inversa falla.

Resolution

Este problema se aborda permanentemente en IDPA 2.6.0 y versiones posteriores.

Si la serie DP de IDPA/PowerProtect se ejecuta en 2.4, v2.4.1 o v2.5 o anterior, hay dos soluciones alternativas:       
  • Pruebe un servidor DNS diferente que admita "CUALQUIER" tipo de consulta DNS.
  • Cree un ticket de soporte técnico para obtener asistencia. 

Article Properties


Affected Product

PowerProtect DP4400, PowerProtect Data Protection Software

Last Published Date

01 Jun 2021

Version

3

Article Type

Solution