Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: schroederk am 26.09.14 - 11:06:27
-
Hallo,
ich habe ein sehr merkwürdiges Problem, dass ich nicht gelöst bekomme:
Wir haben 2 Domino Server, einer 8.5.3FP3 und einer 9.0.1FP1, beide Win2008 R2 Std 64bit, die über eine Site-2-Site-VPN-Verbindung verbunden sind.
Server 1 findet einfach keine Verbindung zum Server 2. Die Mails verbleiben in der Mail.box des Servers.
Folgende Tests habe ich durchgeführt:
Auf Server 1:
- Auf der Domino Konsole: trace MAIL01/SRV
[037C:0006-0A8C] trace MAIL02/SRV/
[037C:0006-0A8C] Determining path to server MAIL02/SRV/
[037C:0006-0A8C] Available Ports: TCPIP
[037C:0006-0A8C] Checking normal priority connection documents only...
[037C:0006-0A8C] Local network connection document found for MAIL02/SRV/
[037C:0006-0A8C] Verifying address '10.20.1.1' for MAIL02/SRV/ on TCPIP
[037C:0006-0A8C] Unable to connect to MAIL02/SRV/ on TCPIP (Remote system no longer responding)
[037C:0006-0A8C] Unable to find any path to MAIL02/SRV/ because Remote system no longer responding
- trace 10.20.1.1
037C:0006-0A8C] trace 10.20.1 .1
[037C:0006-0A8C] Determining path to server 10.20.1.1
[037C:0006-0A8C] Available Ports: TCPIP
[037C:0006-0A8C] Checking normal priority connection documents only...
[037C:0006-0A8C] Allowing wild card connection documents...
[037C:0006-0A8C] Enabling name service requests and probes...
[037C:0006-0A8C] Checking for 10.20.1.1 on TCPIP using address '10.20.1.1'
[037C:0006-0A8C] Unable to connect to 10.20.1.1 on TCPIP (Remote system no longer responding)
[037C:0006-0A8C] Checking low and normal priority connection documents...
[037C:0006-0A8C] No default passthru server defined
[037C:0006-0A8C] Unable to find any path to 10.20.1.1 because Unable to find path to server. Check that your network connection is working. If you have a working connection, go to Preferences - Notes Ports and click Trace to discover where it breaks down.
- In einer DOS-Box des Servers: ping domain-name und ping 10.20.1.1 funktioniert
- telnet 10.20.1.1 1352 funktioniert
- Windows-Share-Zugriff funktioniert (\\10.20.1.1\d$)
- tracert 10.20.1.1 funktioniert
Da ich nur Zugriff auf den Mailserver habe, kann ich leider keine Tests von einem Client aus machen.
Auf Server 2 funktionieren alle Tests, also auch der trace von der Domino Konsole aus. Und ich kann mit meinem Client sowohl die mail.box öffnen, als auch über den Admin-Client auf die Konsole von Server 1 wechseln.
Ich habe die Verbindungsdokumente geprüft und auch schon im Serverdeokument vom Server 1 die Felder $SavedAddresses, $SavedPorts und $SavedServers gelöscht.
Den Router-Task habe ich schon einige Male neugestartet.
Domino einmal komplett neugestartet.
So langsam gehen wir die Ideen aus, was ich noch testen könnte.
PMR bei IBM ist aufgemacht.
-
Mehrere NICs im Server und der Domino bindet sich auf die "falsche"?
-
- telnet 10.20.1.1 1352 funktioniert
Hi, auf die schnelle:
Hab ihr da irgendwelche Netzwerk kompressions Kompetenten im Einsatz?
In Zeiten wo auf VPN Ebene mit Netzwerk Kompression gearbeitet wird, könnte das trügerisch sein.
Denn hier antwortet nicht der andere Domino Server sondern die dafür verantwortliche Netzwerkkomponente, da bin ich schon oft drauf rein gefallen. (zumindest bei uns)
-
Es ist nur eine Netzwerkkarte enthalten.
Und von einer Kompression im Netzwerk weiß ich von meiner Seite aus zumindest nichts.
-
Mir ist jetzt eine Sache aufgefallen:
Ein ping auf den domain-Namen liefert mir die korrekte internet IP-Adresse zurück,
ein nslookup aber die Outside-Adresse der Domain.
Ich denke, dass dort die Ursache liegt.
Die Frage ist nur, wie so etwas zustandekommt, dass ping und nslookup andere Ergebnisse zeigen.
Der Domain-Name steht korrekt in der lokalen Hosts des Servers.
Ein ipconfig /flushdns und ein nbtstat -RR hat am Ergebnis nichts bewirkt.
-
Ein nslookup frägt den eingetragenen DNS-Server.
Ein ping geht nach einer bestimmten Reihenfolge vor ( http://de.wikipedia.org/wiki/Namensaufl%C3%B6sung#Verfahren )
-
Ein nslookup frägt den eingetragenen DNS-Server.
Du hast natürlich recht, hab mich da wieder irreführen lassen.
Das Problem besteht weiterhin, aber nachdem ich nun herausfinden konnte, dass nicht nur der Domino auf der einen Seite zu keinem anderen Domino bei uns eine Verbindung aufbauen kann, sondern auch alle Clients, bin ich doch eher geneigt, dies als Netzwerkproblem zu sehen.
Ich habe den Tunnel nochmals überprüft, auch nochmal neugestartet, sieht alles fehlerfrei aus.
Auf den Coreswitchen sind keine Accesslisten definiert.
Auch wenn die 1352er-Pakete vom Domino sicherlich anders aussehen als ein Telnet auf Port 1352, was gibt es hier für Unterschiede, dass Telnet funktioniert aber Domino nicht?
Wireshark auf dem Domino zeigt einfach, dass die Pakete losgeschickt werden, aber kein Paket zurückkommt.
Könnte es eventuell noch an veränderten MTU-Werten eines der beiden beteiligten Internet-Providern liegen?
Mir gehen so langsam die Ideen aus, was als Ursache in Frage kommen könnte.
-
Ich hatte mal was ähnliches, ein "tell router update config" hatte geholfen (auch wenn ich nicht viel Hoffnung habe, das es hilft, da auch die Clients das Problem haben :-: )
-
Die ganze harte Methode in der lokalen HOSTS den mail02 testhalber einzutragen hast Du vermutlich schon probiert?
-
Das sieht alles nach Problemen im Netzwerk aus... MTU, Firewall, unterschiedliche Routingwege, etc. so dass Pakete verloren gehen.
Gruss,
Thorsten
-
@ MartinG:
Eintrag in der lokalen hosts-Datei hatte ich auch schon versucht.
Denke aber das es kein DNS-Problem ist, denn ein trace über den FQDN oder den Canonischen Namen liefert die korrekte IP.
@Jörg P.: Ich denke, ein Router stoppen und neustarten und sogar ein kompletter Neustart vom Domino dürfte ebenso effektiv wie ein "tell router update config" sein, oder?
Zusätzlich hatte ich auch immer wieder "sh nlcache reset" und ein "tell router dump routingtables" probiert.
Ebenso wie das Verbindungsdokument bearbeiten und speichern, es vom einen Server über push gezwungenermaßen erneut zu übertragen und die üblichen compact- und updall-Geschichten für die names.nsf
Die Router Debugging-Parameter sind alle gesetzt.
@Thorsten: mir ist schleierhaft, wieso nur Domino oder Notes-Client keine Antwortpakete über Port 1352 erhalten, Telnet aber schon.
MTU hatte ich auch kurz im Verdacht, aber steht überall gleich. (Firewall + Switche) Firewall macht keine Port-Inspektion und es gibt keine Accesslist, die Pakete droppen würde, wird auch nicht im Logging angezeigt.
Grundsätzlich vermute ich auch ein Netzwerkproblem, daher:
Ich werde gleich die große Debugging-Aktion starten:
- Wireshark auf beiden Domino-Servern
- beide Firewalls Logging auf Debugging und Session Monitoring für die beiden Server
- Debugging auf beiden Core-Switchen
Dann will ich sehen, welcher Paketzusteller die Pakete verschlampt. >:D
-
Update.
Das Problem konnte mittlerweile gelöst werden:
Bei einem Ping -l 8152 von Server 1 zu Server 2 konnten wir recht viele Timeouts feststellen (ca. 20%).
Beim ping von Server 2 nach Server 1 gab es aber keine Ausfälle.
Nachdem gestern Abend der Internet-Provider vom Standort 1 einen Verbindungsausfall von ca. 5 Minuten hatte, war anschließend auch die Verbindung der Domino-Server wieder da.
Ich hatte allerdings in der Notes.ini des Servers noch den Parameter TCPIP_TcpConnectTimeout=0,30 gesetzt.
Und erst nachdem ich diesen Parameter auch auf einem Notes-Client gesetzt hatte, konnt auch der Client sich mit dem Server 2 verbinden.