Traveler sync dauert unendlich... Alle "normalen" Massnahmen bringen nichts

[Tode]

Ich dachte, vielleicht hat mir hier jemand noch einen anderen Ansatzpunkt: Es ist ein Traveler 9.0.1 Im Einsatz (IF weiss ich gerade nicht), die Mailserver sind ebenfalls 9.0.1, die Mailfiles der Benutzer und Clients aber noch auf 8.5.3.

Der Traveler steht in einer DMZ in Deutschland, die Mail- Home- Server in verschiedenen Ländern.

Seit ungefähr 2-3 Wochen ist es nun so, dass einige Benutzer (hauptsächlich neu für den Traveler freigegebene) in den Aussenstellen Ihren Traveler nicht mehr gesynct bekommen.

Die Verbindung wird aufgebaut, aber der Sync wird nie fertig.
Wenn ich mir die Traveler- Aktivitäten über NTS_CONSOLE_REQUEST_RESPONSE=true auf der Konsole anzeigen lasse, dann sehe ich, dass für die Benutzer eine Verbindung zu stande kommt, die aber nach 88.000 - 89.000ms wieder abgebaut wird (Timeout?). Der Sync kommt nicht zum Ende.

Folgendes habe ich probiert:

1. im Browser am PC traveler.domain.com/traveler eingegeben, und mit dem Benutzer angemeldet: Alles grün (Zugriff auf Mailfile, etc.)
2. Vom Traveler auf den Mail- Home- Server des Benutzers Pings mit grossen Paketen gemacht: Pakete gehen durch, Latenzen sind um die 30ms
3. tell traveler show stat: Auffällig ist, dass ca. 10% der Verbindungen zu den Aussenstellenservern zwischen 30 und 60 Sekunden brauchen

[0C6C:009F-1718]    DCA.DB_OPEN.Time.Histogram.CN=CHSERVER02/O=ZERT.000-001 = 15
[0C6C:009F-1718]    DCA.DB_OPEN.Time.Histogram.CN=CN=CHSERVER02/O=ZERT.030-060 = 3
[0C6C:009F-1718]    DCA.DB_OPEN.Time.Histogram.CN=UKSERVER02/O=ZERT.000-001 = 64
[0C6C:009F-1718]    DCA.DB_OPEN.Time.Histogram.CN=UKSERVER02/O=ZERT.005-010 = 2
[0C6C:009F-1718]    DCA.DB_OPEN.Time.Histogram.CN=UKSERVER02/O=ZERT.030-060 = 3

4. Test- Benutzer mit 150 MB Mailfile angelegt, auf Server in Deutschland: Traveler Test: OK. Dann User auf Server im Ausland verschoben: Gleiches Problem. Es liegt also nicht am Benutzer und auch nicht an der Grösse des Mailfiles

Hintergundinformationen:
Die Anbindung erfolgt über eine MobileIron Sentry in der selben DMZ wie der Traveler. Die würde ich aber -eigentlich- ausschliessen, weil ja alles sauber beim Traveler ankommt.
Die Anbindung der Aussenstellen läuft über eine Riverbed zur Performance- Optimierung (könnte das ein Ansatzpunkt sein !?)
Auf dem Traveler sind ca. 100 Benutzer mit ca. 150 Devices, also keine "Mega- Auslastung", die HTTP- Threads stehen auf 400, Prozessorauslastung und Memory dümpeln vor sich hin

Alle Troubleshooting- Guides für Traveler die ich gefunden habe, habe ich durch...

Hat jemand noch eine "neue Sichtweise"?
Thanx

[m3]

Ich würde die Riverbed verdächtigen ...

[Tode]

Ich auch... Aber das müsste man ja irgendwie "nachweisen"...

[schroederk]

Kannst Du nicht vorübergehend die Riverbed rausnehmen? Wie siehts aus, wenn mal (natürlich ganz rein zufällig) die Riverbed keinen Strom mehr hat?
Hängt dann die ganze Strecke oder ist sie so konfiguriert, dass dann eben alles an der Riverbed vorbei geht?

[Tode]

Nun: Es handelt sich um das Netzwerk eines Kunden... Dem werde ich nicht mal "aus Versehen" die Riverbed ausschalten...

Die Riverbed wurde Ende letzter Woche auch gegen eine bessere getauscht. Das Problem hat sich aber nicht "verändert".

Aber wie würdet Ihr "testen", wenn ein Notes- Client, der auf dem Traveler parallel installiert ist, einigermassen schnell auf die Mailfiles auf den ausländischen Servern zugreifen kann und auch die Ping- Zeiten unauffällig sind, nur eben die Traveler- Verbindung hakt...