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

IDPA-Bereitstellung fehlgeschlagen mit Fehler „Rückwärtssuche fehlgeschlagen“

Summary: IDPA-Bereitstellung fehlgeschlagen mit Fehler „Rückwärtssuche fehlgeschlagen“

This article applies to   This article does not apply to 

Symptoms



Hinweis: Betroffene Softwareversion: 2.4 und frühere Versionen

Problem: Die anfängliche IDPA-Bereitstellung schlägt in der Konfigurationsphase für das Appliance-Netzwerk mit folgendem Fehler fehl:

Workflow-Fehler:
Konfigurieren des Appliance-Netzwerks. [Schritt 1 von 4]Konfigurieren des Appliance Configuration Manager-Netzwerks. [Schritt 1 von 4]Appliance Configuration Manager-Netzwerkkonfiguration abgeschlossen. [Schritt 2 von 4]Validierung der Netzwerkeinstellungen gestartet. [Schritt 2 von 4]Validierung der Netzwerkeinstellungen fehlgeschlagen. Appliance-Netzwerkkonfiguration fehlgeschlagen. Detaillierter Fehler: (Hinweis: x.x.x.11 ist die öffentliche ACM-IP-Adresse und x.x.x.12 ist die öffentliche ESXi-IP-Adresse) Rückwärtssuche fehlgeschlagen für x.x.x.11 mit primärem Domänennamenserver x.x.x.240. Rückwärtssuche fehlgeschlagen für x.x.x.12 mit primärem Domänennamenserver x.x.x.240. 


– NVT-Tool-Überprüfung bestanden

– nslookup funktioniert ordnungsgemäß für DNS-Vorwärts- und -Rückwärtssuche

– Verwendung des ACM-dnsjava-Dienstprogramms für die DNS-Suche ist fehlgeschlagen:
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 Input : DNS[x.x.x.240], IP Address[x.x.x.11]. Hostname: x.x.x.11 Reverse lookup failed. Vergleich mit dem nslookup-Ergebnis der gleichen DNS-Abfrage, die erfolgreich war: dpappliance-acm:~ # nslookup x.x.x.11 Server: x.x.x.240 Address: x.x.x.240#53 11.x.x.x.in-addr.arpa name = dp4400-acm.sample.local. 
Test Nr. 1: tcpdump-Ausgabe zeigt eine fehlgeschlagene DNS-Suche. DNS-Server x.x.x.240 hat keine Antwort auf „ANY“-Abfrage gesendet: =================================================================================== Von ACM kann der Netzwerkdatenverkehr von der folgenden dnsjava-DNS-Abfrage erfasst werden, indem Folgendes ausgeführt wird: 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 Input : DNS[x.x.x.240], IP Address[x.x.x.11]. Hostname: x.x.x.11 Reverse lookup failed. dpappliance-acm:~ # nslookup x.x.x.11 Server: x.x.x.240 Address: 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: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 01:18:07.955334 IP (tos 0x0, ttl 64, id 49262, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.48611 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x2be5!] 33132+ PTR? 11.x.x.x.IN-ADDR.ARPA. (41) 01:18:07.955914 IP (tos 0x0, ttl 64, id 49263, offset 0, flags [DF], proto UDP (17), length 71) dp4400-acm.sample.local.33633 > x.x.x.240.domain: [bad udp cksum 0x2058 -> 0xa78f!] 39491+ PTR? 240.10.10.10.in-addr.arpa. (43) 01:18:07.956517 IP (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. [1h] NS ns.10.IN-ADDR.ARPA. ar: ns.10.IN-ADDR.ARPA. [1h] A 127.0.0.1 (111) 01:18:07.956815 IP (tos 0x0, ttl 49, id 46189, offset 0, flags [none], proto UDP (17), length 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. [30m] SOA ns.10.in-addr.arpa. mail.10.in-addr.arpa. 102 28800 3600 604800 1800 (87) 01:18:07.956966 IP (tos 0x0, ttl 64, id 49264, offset 0, flags [DF], proto UDP (17), length 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, flags [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. [1h] NS ns.10.in-addr.arpa. ar: ns.10.in-addr.arpa. [1h] A 127.0.0.1 (111) 01:18:07.959536 IP (tos 0x0, ttl 64, id 49265, offset 0, flags [DF], proto UDP (17), length 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, flags [DF], proto UDP (17), length 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, flags [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) 01:18:14.967449 IP (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 packets captured 10 packets received by filter 0 packets dropped by kernel Test Nr. 2: tcpdump-Ausgabe zeigt eine erfolgreiche DNS-Suche. Ein anderer DNS-Server x.x.x.101 hat auf die „ANY“-Abfrage geantwortet: ====================================================================================== Von ACM kann der Netzwerkdatenverkehr mit dem folgenden Befehl erfasst werden (x.x.x.101 ist ein DNS-Testserver, den ein Partner selbst in einer VM erstellt hat): 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 Input : DNS[x.x.x.101], IP Address[x.x.x.11]. Hostname: dp4400-acm.sample.local Reverse lookup successful.. Hostname: dp4400-acm.sample.local IP Address: x.x.x.11 Forward lookup successful. IP Address: x.x.x.11 dpappliance-acm:~ # tcpdump -s 0 -i eth1 host 10.15.1.101 -vvvv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 01:20:01.368557 IP (tos 0x0, ttl 64, id 4344, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.54907 > 10.15.1.101.domain: [bad udp cksum 0x16d0 -> 0xe01c!] 48674+ PTR? 11.x.x.x.IN-ADDR.ARPA. (41) 01:20:01.376214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has dp4400-acm.sample.local tell 10.15.1.101, length 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), length 28 01:20:01.376477 IP (tos 0x0, ttl 128, id 4475, offset 0, flags [none], proto UDP (17), length 106) 10.15.1.101.domain > dp4400-acm.sample.local.54907: [udp sum ok] 48674* q: PTR? 11.x.x.x.IN-ADDR.ARPA. 1/0/0 11.x.x.x.IN-ADDR.ARPA. [1h] PTR dp4400-acm.sample.local. (78) 01:20:01.378905 IP (tos 0x0, ttl 64, id 4346, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.55796 > 10.15.1.101.domain: [bad udp cksum 0x16d0 -> 0x948b!] 47726+ ANY? dp4400-acm.sample.local. (41) 01:20:01.379318 IP (tos 0x0, ttl 128, id 4476, offset 0, flags [DF], proto UDP (17), length 85) 10.15.1.101.domain > dp4400-acm.sample.local.55796: [udp sum ok] 47726* q: ANY? 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, length 28 01:20:06.394227 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.15.1.101 is-at 00:0c:29:6f:47:b6 (oui Unknown), length 46

Cause

Mit dem aktuellen IDPA-ACM-DNS-Client-Modul sendet dnsjava (Version 2.4 oder früher) „ANY“-DNS-Abfragen an DNS-Server für die Rückwärtssuche. Die meisten DNS-Server können „ANY“-Abfragen korrekt beantworten, aber bei DNS-Servern, die nicht in der Lage sind, eine „ANY“-Abfrage zu verarbeiten, schlägt die Rückwärtssuche fehl. 

Resolution

Das Problem wird nach Version 2.4 behoben.

Wenn IDPA in der Version 2.4 oder früher ausgeführt wird, gibt es zwei Umgehungslösungen: 
1: Versuchen Sie es mit einem anderen DNS-Server, der DNS-Abfragen des Typs „ANY“ unterstützt
2: Erstellen Sie ein Ticket für den technischen Support, um Unterstützung zu erhalten.

Affected Products

Integrated Data Protection Appliance Family

Products

Integrated Data Protection Appliance Family