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.

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

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

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



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.

Article Properties


Affected Product

Integrated Data Protection Appliance Family

Product

Integrated Data Protection Appliance Family

Last Published Date

01 Jun 2021

Version

3

Article Type

Solution