Troubleshooting: Kann nicht mit Kollegen aus USA chatten Was muss ich überprüfen

[fsinani]

Gegeben:
4 (3 in DE einer in US) Sametimeserver 8.02 auf Windows OS.
Personen aus USA können nicht mit uns in DE chatten. Wir sehen ihre presence gar nicht und umgekehrt.

Wo fange ich mit der Fehlersuche am Besten an?


Vielen Dank

[hallo.dirk]

Du hast 2 verschidene Sametime Server, richtig?

zunächst erst einmal Netzwerk überprüfen beide Richtungen):
- Können die ST Server sich erreichen (ping)?
- Ist Port 1516 offen
- Ist der Notes Port (1352)offen ?
- bin mir nicht sicher aber der St Client Port 1533 wird nicht unbedingt benötigt.

Dann hätten wir die ST Konfiguration:
Mindestens müsssen die Server sich gegenseitig als allowed Community Hosts eingetragen haben.
Kann es sein, das man dies unter 8.0.x noch im Browser konfigurieren kann? (Sametime Administration)
Ansonsten steht das auch in der stconfig.nsf
 im CommunityConnectivity Dokument unter Community Trusted IPS

P.S.: Antwort aus dem Kopf keine Garantie auf Vollständigkeit

[fsinani]

Hallo.dirk,

Danke für Diene erste Antwort.
Hier die Details:
ServerA = (- Server(DE; ST R8.02 (Win2003+Dom R8.53)
ServerB = (- Server(US; ST R8.01 (Win2003+Dom R8.02FP3)

Testabfolge:
ServerA pingt ServerB  (hostname) an. Ergebnis OK
ServerA pingt ServerB  (DominoSrvName) an. Ergebnis NICHT OK (DNS)

ServerB pingt ServerA  (hostname) an. Ergebnis OK
ServerB pingt ServerA  (DominoSrvName) an. Ergebnis OK

ServerA startet per Domino trace zu ServerB (hostname) und wird mit dem DominosrvNamen verbunden. Ergebnis OK
ServerB startet per Domino trace zu ServerA (hostname) und wird mit dem DominosrvNamen verbunden. Ergebnis OK

ServerA startet per Domino trace zu ServerB (DominoSrvNamen) und wird mit dem DominosrvNamen verbunden. Ergebnis OK
ServerB startet per Domino trace zu ServerA (DominoSrvNamen) und wird mit dem DominosrvNamen verbunden. Ergebnis OK

ServerA startet telnet zu ServerB Port 1516. Ergebnis OK
ServerB startet telnet zu ServerA Port 1516. Ergebnis OK

ServerA startet telnet zu ServerB Port 1352. Ergebnis OK
ServerB startet telnet zu ServerA Port 1352. Ergebnis OK

stconfig.nsf
Ich habe festgestellt, dass in der TrustedIPs von ServerB die IP des ServerA fehlte.

Ich werde aber erst nach einem Neustart testen können. Der Server steht in US und da muss ich bis 14:00 Uhr auf den Admin dort warten.

[hallo.dirk]

Wenn das nicht hilft, dann schau Dir mal mal What is required for Sametime community awareness and chat to work on multiple servers und How a Sametime server establishes a community connection with other Sametime servers an

Da sollte alles dabei sein:)

[fsinani]

Prima. Das werde ich mir dann zu Gemüte führen.
Hab Dank und ein schönes WE.

Ergebnis poste ich frühestens ab Montag

EDIT:!!

Jetzt war ich doch schneller:
Hab die beiden Server neu gestartet. Dennoch geht es nicht.
Jemand sagte mir, es wird von IBM nicht unterstützt, dass man die VPUserinfo.nsf repliziert, es sei denn, man hat einen Cluster, was ich nicht habe. Aber ich repliziere trotzdem. Also habe ich auf dem besagen server meine Buddyliste gelöscht, die Replikation ausgeschaltet und sah, dass meine Buddyliste nun in ST weg ist. Aber es geht immer noch nicht.

Der nächste Hinweis wäre Domino 8.5.3 auf dem der ST 8.02 läuft. Da sagte mir jemand, "er hätte gelesen, dass ST 8.02 nur auf Domino < 8.5 unterstützt wird"

Tausend Fragezeichen
??

[stoeps]

Zumindest ist es nicht supportet: http://www-01.ibm.com/support/docview.wss?uid=swg27013765

Code

Domino levels supported
Domino 7.x releases
Domino 8.0.x releases (32-bit only)
Note: To support IPv6, you must use version 8.0.x of Domino

Wichtig ist auch immer:

Code

Based on the IP addresses and the last Octet of the IP addresses, the Sametime server decides which server should contact which server. If a server IP's last Octet is less than the server that just came online, 
then the first server online will initiate the connection to that server. If a server's last Octet is greater than the last octet of the first server online, the first 
server online waits to be contacted by that server. In other words, lower octets listen for higher octets to call.

http://www-01.ibm.com/support/docview.wss?uid=swg21206752

Das trifft einem bei NAT Verbindungen immer ziemlich hart, da kann es passieren, daß durch das IP drehen sich keiner der Server für die initiale Verbindung zuständig fühlt.

[hallo.dirk]

Im Domino Verzeichnis gibt es doch auch noch die sametime.log datei, schau da mal bei beiden Servern rein, ob du Hinweise findest

[fsinani]

Hallo Zusammen und vielen Dank für die Antworten,

ich habe einen IBMler beauftragt, sich das mal anzuschauen. Jedoch bezweifle ich, dass etwas Gescheites bei raus kommt,.
Ein frisch aufgesetzteer Server in den USA am WE funktionierte jedenfalls mit unserem tadellos.

Einziger Unterschied (zumindest sichtbar) - ein Domino 8.02 und ein ST 8.02 (vorher war es der ST 8.01 auf Domino 8.02)

Falls ich etwas herausfinde, poste ich es hier.

Danke nochmal

[fsinani]

Also, mal wieder etwas ganz dolles.

Hier die Lösung:
wir haben ja folgende Ausgangssituation -
Hier die Details:
ServerA = (- Server(DE; ST R8.02 (Win2003+Dom R8.53)
ServerB = (- Server(US; ST R8.01 (Win2003+Dom R8.02FP3)

Die Kommunikation zwischen Sametime Servern funktioniert so, dass ja ein Server eine Connection zu einem anderen aufbaut. Aber welcher Server ist das? Das entscheidet sich bei ST ja anhand der Oktette in deren IP Adresse. Ein höheres Oktett initiert die Verbindung zu einem ST Server mit niedrigerem Oktett. Soweit bekannt?


Und jetzt kommt das Problem:

ServerA (8.02) hat die IP 172.19.1.229
ServerB (8.01) hat die IP 172.21.181.172

Währed ST 8.0.2 die Oktette von Links nach Rechts untersucht, macht ST 8.0.1 dies von rechts nach links :-)

Anhand der obigen IP Adressen könnt Ihr dann selbst erraten, dass sich beide Server zu fein dafür waren, die Verbindung zu dem jeweils anderen aufzubauen.

Ich habe nun die IP Adresse von ServerB geändert. Und siehe da - nun klappt es.

Was für ein Bullshit....