Tree wird nicht erkannt, aber Unmassen Keep-Alive-Packets vom NW5.0 Server

Christoph Maercker

unread,

Aug 15, 2014, 4:15:08 AM8/15/14

to

Hallo,

nach der Migration eines virtuellen NW5.0-Servers auf einen anderen
VMWare-Cluster finden weder ältere XP-Clients noch der für Win7 den Tree
wieder, bekommen aber vom Server an die 150.000(!) Keep-Alive-Pakete/min.
Vorher wird die Fileserver Info abgefordert und auch korrekt mit
Servernamen u.a.m. beantwortet. Danach wird ein NDS-Ping vom Client
gesendet, anschließend beginnt ein Austausch von tausenden Keep-Alives.
Zwischendurch sendet der Client einzelne TCP-RSTs, so was ist meistens
verdächtig.
Der Client kennt also die IP-Adresse des Servers, aber nicht den Tree-Namen.
SLP ist auf dem Client deaktiviert, da Win7-Clients kein SLP v1 mehr
unterstützen. Die Serversuche muss also via DNS erfolgen und der Server
ist im DNS registriert, anpingbar und antwortet lt. Trace auch via
NCP-Port 524.
Irgendeine Idee, was da schiefläuft?
--

CU Chr. Maercker.

Bernd

unread,

Aug 15, 2014, 4:46:07 AM8/15/14

to

Am Fri, 15 Aug 2014 10:15:08 +0200
schrieb Christoph Maercker <Zwei...@gmx-topmail.de>:

(...)

> Der Client kennt also die IP-Adresse des Servers, aber nicht den
> Tree-Namen. SLP ist auf dem Client deaktiviert, da Win7-Clients kein
> SLP v1 mehr unterstützen. Die Serversuche muss also via DNS erfolgen
> und der Server ist im DNS registriert, anpingbar und antwortet lt.
> Trace auch via NCP-Port 524.

(...)

Ist im DNS ein A-Record für den TREE-Namen vorhanden? Der TREE soll
gefunden werden, nicht der Server.

Was sagt:
# nslookup <TREE-Name>
auf einer der problematischen WkStn? Gibt das die IP-Adresse des NW5.0
Servers zurück?

Bernd

Christoph Maercker

unread,

Aug 15, 2014, 5:41:19 AM8/15/14

to

Bernd wrote:
> Ist im DNS ein A-Record für den TREE-Namen vorhanden? Der TREE soll
> gefunden werden, nicht der Server.

Der Tree-Name steht als Alias des Servers im DNS. Muss es unbedingt ein
A-Record sein?

> Was sagt:
> # nslookup <TREE-Name>
> auf einer der problematischen WkStn? Gibt das die IP-Adresse des NW5.0
> Servers zurück?

Ja:
Name: <server>.<domain>
Address: <server-ip-address>
Aliases: <treename>.<domain>

Von Windoof ist mir übrigens bekannt, dass es Komplikationen gibt, wenn
nach <computername> gefragt wird, selbiger alber als Alias von
<dns-name> eingetragen ist. Die nächste Aktion von Windoof ist nämlich
\\<dns-name>\... und das geht natürlich in die Hose. Falls unter NetWare
was ähnliches passiert, muss ich ggf. aus dem Alias einen A-Record machen.
--

CU Chr. Maercker.

Bernd

unread,

Aug 15, 2014, 6:17:28 AM8/15/14

to

Am Fri, 15 Aug 2014 11:41:19 +0200
schrieb Christoph Maercker <Zwei...@gmx-topmail.de>:

Versuche mal einen 'echten' A-Record.

Soweit mir bekannt ist gibt der DNS-Server bei Alias dem Resolver eine
Antwort die man interpretieren könnte als: <Alias> ist in Wirklichkeit
<A-Record>, frage nach A-Record.

Bernd

Christoph Maercker

unread,

Aug 15, 2014, 7:17:10 AM8/15/14

to

Bernd wrote:
> Soweit mir bekannt ist gibt der DNS-Server bei Alias dem Resolver eine
> Antwort die man interpretieren könnte als: <Alias> ist in Wirklichkeit
> <A-Record>, frage nach A-Record.

"frage nach A-Record" überlässt er dem Client und - wie geschrieben -
Windoof bastelt dann ungültige UNC-Pfade, in denen \\<A-record>\ statt
\\<computername=alias>\ steht. Einen Test ist es also wert, ob die
Novell-Clients ähnliches verzapfen.
--

CU Chr. Maercker.

Christoph Maercker

unread,

Aug 15, 2014, 7:31:54 AM8/15/14

to

Bernd wrote:
> Versuche mal einen 'echten' A-Record.

Ich fürchte, es wird nichts bringen, ich habe eben nochmal das Verhalten
bei der Tree-Suche getraced, vorher ipconfig /flushdns:

Obwohl als Nameservices *nur* DNS und NCP blau hinterlegt = aktiviert
sind, werden 5 SLP-Multicasts und *keine* DNS-Anfrage gesendet. Der
konfigurierte DA wird vorher auch gefragt, kann aber nicht weiterhelfen,
weil NW5.0 nur SLP v1 kann, inkompatibel mit v2 vom Client, deswegen
anschließend Multicasts. :-\
--

CU Chr. Maercker.

Christoph Maercker

unread,

Aug 15, 2014, 8:40:52 AM8/15/14

to

Bernd wrote:
> Versuche mal einen 'echten' A-Record.

[x] done. Keine Änderung.
Zusätzlich Eintrag in die lokale etc\hosts. Das hat vor Jahren bei
ähnlichen Symptomen was gebracht, diesmal nicht.
--

CU Chr. Maercker.

Bernd

unread,

Aug 15, 2014, 9:47:23 AM8/15/14

to

Am Fri, 15 Aug 2014 13:31:54 +0200
schrieb Christoph Maercker <Zwei...@gmx-topmail.de>:

(...)

> ich habe eben nochmal das
> Verhalten bei der Tree-Suche getraced, vorher ipconfig /flushdns:
>
> Obwohl als Nameservices *nur* DNS und NCP blau hinterlegt = aktiviert
> sind, werden 5 SLP-Multicasts und *keine* DNS-Anfrage gesendet. Der
> konfigurierte DA wird vorher auch gefragt, kann aber nicht
> weiterhelfen, weil NW5.0 nur SLP v1 kann, inkompatibel mit v2 vom
> Client, deswegen anschließend Multicasts. :-\

Hast Du nicht irgendwo einen SLES/OES der SLPv2 machen könnte? Dem
kannst Du dann ja die von Client gesuchten Services statisch eintragen.

Bernd

Christoph Maercker

unread,

Aug 15, 2014, 10:59:06 AM8/15/14

to

Bernd wrote:
> Hast Du nicht irgendwo einen SLES/OES der SLPv2 machen könnte? Dem
> kannst Du dann ja die von Client gesuchten Services statisch eintragen.

Muss ich mal unseren VM-Admin fragen. WIMRE hatten die mal 1..2 SLES
aufgesetzt. Das aktuelle Problem muss aber noch woanders liegen, der
zweite Client ist ein XP-System, dessen Novellclient macht noch SLPv1.
Evtl. ist am virtuellen Router was faul, dass dort irgendwelche Pakete
nicht durchkommen.
--

CU Chr. Maercker.

Massimo Rosen

unread,

Aug 17, 2014, 3:23:22 AM8/17/14

to

Am 15.08.2014 10:15, schrieb Christoph Maercker:
> Hallo,
>
> nach der Migration eines virtuellen NW5.0-Servers auf einen anderen
> VMWare-Cluster

Hmm. Gebietet die Logik da nicht, bei VMWare anstatt bei Netware nach
dem Problem zu suchen?

CU,
Massimo

Christoph Maercker

unread,

Aug 18, 2014, 3:33:45 AM8/18/14

to

Massimo Rosen wrote:
> Hmm. Gebietet die Logik da nicht, bei VMWare anstatt bei Netware nach
> dem Problem zu suchen?

Das läuft an, sobald unser VM-Admin wieder da ist. ;-)
Wo könnte da am ehesten der Schuh drücken? Virtueller Router? Das VLAN
ist gleich geblieben, Pings werden in beiden Richtungen beantwortet und
Not-Logged-In-Connections via NCP-Port 524 werden jeweils für einige
Sekunden..Minuten aufgebaut und gehalten.
--

CU Chr. Maercker.

Massimo Rosen

unread,

Aug 18, 2014, 8:16:13 AM8/18/14

to

Ohne die Traces gesehen zu haben... keine Ahnung. ;)

CU,
Massimo

Christoph Maercker

unread,

Aug 18, 2014, 12:08:23 PM8/18/14

to

Massimo Rosen wrote:
>> Das läuft an, sobald unser VM-Admin wieder da ist. ;-)
>> Wo könnte da am ehesten der Schuh drücken? Virtueller Router? Das VLAN
>> ist gleich geblieben, Pings werden in beiden Richtungen beantwortet und
>> Not-Logged-In-Connections via NCP-Port 524 werden jeweils für einige
>> Sekunden..Minuten aufgebaut und gehalten.

Inzwischen funktioniert es wieder: Unser VM-Admin hat
a) die VM-Version von v4 auf v8 aktualisiert
b) den vNIC von AMD (PCNTNW.LAN) auf Intel E1000 geändert und
c) angeblich die VM auf eine etwas ältere Hardware migriert.

Eine Aktualisierung der VM-Version auf v10 brachte zunächst keine
Besserung, die Umstellung auf den Intel vNIC auch nicht. Deshalb muss
ich unseren Admin uu letzterem morgen befragen, soweit ich sehen kann,
ist die VM nämlich im gleichen Cluster geblieben wie vorher.

> Ohne die Traces gesehen zu haben... keine Ahnung. ;)

Falls Interesse, lade ich ein Trace auf meine Website hoch. Es sieht
aus, als wären Pakete von und/oder zum Server durch eine Art
Dummy-Packet ersetzt worden, durch wen auch immer. Weil bis zur
TCP-Ebene alles OK ist, aber via NCP wird Mist gebaut. Für einen
(virtuellen) Router ist das aber eigentlich eine Aufgabe auf zu hohem
Niveau. ;-)

--

CU Chr. Maercker.

Massimo Rosen

unread,

Aug 19, 2014, 11:28:04 AM8/19/14

to

Hallo.

Am 18.08.2014 18:08, schrieb Christoph Maercker:
> b) den vNIC von AMD (PCNTNW.LAN) auf Intel E1000 geändert

Ich tippe hierauf.

Der pcntnw mit vmware hat nie wirklich richtig funktioniert.

CU,
Massimo