schwieriges Netzwerkproblem aufspüren

[DeathAndPain 10]

Hallo,

 

ich stehe vor einem kniffligen Netzwerkproblem.

 

Mehrere Niederlassungen sind sternförmig an unser Haupthaus über einen VPN-Tunnel durch das Internet angebunden. Die WAN-Infrastruktur (Router und VPN-Verschlüsseler in der Niederlassung, doppelte ISDN-Standleitung von dort ins Internet, 2MBit-Standleitung aus dem Internet in Haupthaus, Router und VPN-Verschlüsseler im Haupthaus) ist komplett von der Telekom angemietet.

 

Bei einer Niederlassung haben wir nun Verbindungsprobleme: SAP-Sessions brechen sporadisch zusammen. Anscheinend können die zugrundeliegenden TCP-Verbindungen nicht dauerhaft aufrechterhalten werden. Die einschlägigen Windows-Registry-Parameter für lahme TCP/IP-Verbindungen brachten keine Abhilfe. Am LAN in der Niederlassung kann es nicht liegen: Die habe ich komplett neu verkabelt, ohne daß die Symptome sich verändert haben. Am LAN im Haupthaus kann es auch nicht liegen, denn dort werden über denselben Router alle Niederlassungen bedient, und wenn es im Haupthaus ein Problem gäbe, dann müßten alle Niederlassungen betroffen sein.

 

Bleibt die angemietete Fernverbindung zwischen dem Haupthaus und der problematischen Niederlassung. Ich habe die reguläre Durchsatzrate in die problematische und eine unproblematische Niederlassung mittels dem Freeware-Tool NETIO gemessen. Die Werte sind in etwa identisch. Man kann also nicht sagen, daß die Datenübertragung in die problematische Niederlassung meßbar langsamer wäre.

 

Meine Vermutung ist, daß auf der problematischen Verbindung vereinzelt TCP/IP-Pakete verworfen werden. Sowas kriegt man mit einer einfachen Durchsatzmessung nicht mit. Immerhin müssen die Pakete derart verloren gehen, daß sie auch auf höheren Protokollschichten nicht rekonstruiert werden können (was ja normalerweise durch erneutes Anfordern der fehlenden Daten geschieht). Das könnte z.B. an einem der Verbindungsrouter oder dem VPN-Verschlüsseler in der Niederlassung geschehen. Aber das ist, wie gesagt, nur eine Vermutung.

 

Die Frage ist nun, wie man das Problem weiter eingrenzen kann. Wenn ich einfach an die Telekom rangehe und sage, hier, eure Leitung läuft nicht richtig, dann machen die eine Messung, bei der klappt dann alles (so wie bei meinem NETIO-Test), und dann sagen die, daß doch alles geht und es an ihnen nicht liegt, schreiben eine Rechnung und gehen.

 

Vor einer Störungsmeldung an die Telekom muß ich also einen Weg finden, das Problem greifbar einzugrenzen, so daß ich etwa sagen kann, hier, jedes tausendste Paket geht verloren oder nach durchschnittlich einer Stunde bricht jede TCP-Verbindung zusammen und das auch anhand einer Messung belegen kann. Ich muß also konkreter sein können als "irgendwas geht nicht".

 

Wie kann ich das anstellen? Wie grenzt man solch Fehler ein?

[kurisa 10]

Hallo!

 

Ich hab eine ähnliche Ausgangssituation wie Du (10 Niederlassungen per VPN mittels XDSL an Zentrale angebunden, Internet nur über Zentrale möglich, etc.). Eine Durchsatzmessung wird dir nur dann was bringen, wenn genau zu diesem Zeitpunkt/-raum die Leitung wegbricht. Was ich immer wieder mal starte ist das Programm Ping-Plotter (http://www.pingplotter.com). Hier sieht man über einen Zeitraum verteilt, wie lange die Pings brauchen bzw. ob sie überhaupt ankommen. Evt. von der Zentrale aus bzw. von den Standorten aus versuchen...

 

Was auch immer recht hilfreich und teilw. informativ ist, ist ein MRTG laufen zu lassen.

 

Hoffe damit etwas geholfen zu haben!

[Das Urmel 10]

An den Router - da von der Telekom- kommst du sicher nicht ran um Stats auszulesen?

Dann bitte die Jungs einfach, die Leitung zu monitoren.

Das machen die im 15-Min. Intervall (dann stehen jeweils Ergebnisse fest)

Nebenher könntest du im einfachsten Fall tatsächlich die Pingzeiten festhalten.

[edv-olaf 10]

Hallo,

 

eigentlich sind die T-Rosas ganz nett zu Firmenkunden, wenn es ums Durchmessen und Testen geht. Ich würde zuerst mal anrufen und fragen.

 

Grüße

Olaf

[Data1701 10]

Hi,

 

auf was für einem System laufen die SAP-Kisten ? Gab es schon vorher Probleme mit SAP über VPN ? SAP mag halt keinen großen Latzenzeiten.

 

Funktioniert der Rest denn noch richtig, Replikation zwischen den Standorten ? Könnte nämlich auch der Hotfix 893066 sein, der Dir die TCP/IP Sitzung stört.

 

http://www.mcseboard.de/showthread.php?t=61031&highlight=bug

 

Wir hatten extreme Probleme damit und mussten überall ein Hotfix füt das Hotfix einspielen und alles war schön.

 

Nutz Du Cisco-Komponeten für das VPN ? Dann lese auch mal bei Cisco nach, unter gewissen Vorraussetzungen kann es dort auch zu Problemen kommen.

 

Überigens SNMP-Zugriff aug T-COM Router ist möglich.

 

Gruß Data

[DeathAndPain 10]

Vielen Dank für die Tipps soweit.

 

auf was für einem System laufen die SAP-Kisten ?

Ein Proliant-Server mit 4 HT-fähigen Xeons unter Windows 2000 Advanced Server.

 

Gab es schon vorher Probleme mit SAP über VPN ?

Nein. Allerdings muß man dazu sagen, daß die problematische Niederlassung auch die ist, in der am meisten gearbeitet wird.

 

SAP mag halt keinen großen Latzenzeiten.

Aber das müßte man doch mit den Registry-Keys MaxDataRetransmissions und MaxConnectRetransmissions in den Griff kriegen können.

 

Funktioniert der Rest denn noch richtig

Na ja, von der Wahrnehmung der Anwender her schon. Allerdings wird zwischen den einander vertrauenden Domänencontrollern von Haupthaus und Niederlassungen relativ häufig der Redirector-Event 3013 "Der Redirector-Dienst hat eine Anforderung zu xyz wegen Zeitüberschreitung aufgegeben." geloggt. Dies betrifft alle Niederlassungen mal, die über doppeltes ISDN angebundenen allerdings häufiger als die über DSL angebundenen, und die problematische am häufigsten.

 

Replikation zwischen den Standorten ?

Der Verzeichnisreplikationsdienst loggt mehrmals täglich Fehlermeldungen (Events 3208, 3209, 3216). Das ist aber in den per DSL angebundenen Niederlassungen nur wenig besser. Ich halte den Windows-Verzeichnisreplikationsdienst wegen seiner hohen Fehleranfälligkeit für Pfusch. Deswegen hat Microsoft ja auch Robocopy entwickelt. Das Replikationsergebnis selbst ist aber zufriedenstellend; die Benutzerprofile und unser Intranet werden einwandfrei verteilt.

 

Könnte nämlich auch der Hotfix 893066 sein, der Dir die TCP/IP Sitzung stört.

Wir haben kein Windows 2003 Server. Die Domänencontroller sind NT 4, und der SAP-Server ist Win2000 Advanced Server und nicht Bestandteil der Domäne.

 

Nutz Du Cisco-Komponeten für das VPN ?

Das VPN wird auch komplett von der Telekom gestellt. Die nutzen dafür Schächtelchen von Lancom. Die Router zwischen den Lancoms und dem Internet sind Ciscos. Gleichfalls in rosa Händen.

 

Überigens SNMP-Zugriff aug T-COM Router ist möglich.

Wenn man das Paßwort kennt. :) Zwar wäre es möglicherweise machbar, das in Erfahrung zu bringen, aber in dem Moment, in dem wir anfangen, in der angemieteten Hardware rumzufuhrwerken, kann sich die Telekom im Fehlerfall rausreden und uns die Schuld zuschieben. Deswegen betrachten wir den ganzen VPN-Tunnel als schwarze Röhre, in die wir auf der einen Seite unsere Daten reinschieben und dann (hoffentlich) auf der anderen Seite rausbekommen. Wenn das nicht klappt, dann müssen wir den Fehler klar beschreiben können und können dann eine Fehlermeldung aufmachen.

[Data1701 10]

Das Hotfix betrifft so ziemlich alle MS-Produkte nicht nur 2003.

 

Wir hatten nach dem einspielen ganz massive Problem mit all unseren W2k DCs. Nachdem wir das Hotfix für das Hotfix eingespielt hatten war alles wieder schön.

 

Es gab massive Replikationsprobleme, Sysvol veraltet, DFS nicht durchrepliziert, AD-Änderungen brauchten Tag anstatt Stunden.

 

Anscheinend ist dein Problem ja nicht VPN - oder ISDN-Spezifisch, wenn ich das alles richtig verstanden habe. Also würde ich eher auf der Client- bzw. Serverseite suchen.

 

Was logt denn der SAP-Server so ?

 

Gruß Data

 

Edit: Wenn Du SNMP und den Comunitystrig hast, dann kasst Du wenigstens die Leitungen mal monitoren. Ein Art Haftungsauschluß sehe ich da nicht.

[DeathAndPain 10]

Sorry, ist lieb gemeint, aber Du denkst offenbar in eine völlig falsche Richtung:

 

• Auf dem SAP-Server spielen wir überhaupt keine Windows-Updates ein. Das riskieren wir nicht. Dafür haben wir unsere Firewall.
   
  
• Es sind ja nur zwei Client-Rechner von ca. 100 betroffen (es ist jetzt noch einer mit denselben Symptomen hinzugekommen).

Damit scheidet ein marodierender Hotfix aus. Der eine von den beiden betroffenen Rechnern läuft unter NT 4.0, der andere unter Windows 2000. Damit ist es auch nichts Windows-Versionsspezifisches.

 

Was mir allerdings zu denken gibt, ist die Tatsache, daß diese beiden Rechner zu den wenigen gehören, die mit 512 MB Hauptspeicher ausgestattet sind und auf denen der klickRoute Routenplaner (von klickTel) installiert ist (die anderen haben alle nur 128 MB). Der Routenplaner ist aber gar nicht gestartet und lädt nach meinem Kenntnisstand beim Booten nichts in den Hauptspeicher. Er scheint damit als Ursache auszuscheiden, weil er zum und vor dem Problemzeitpunkt gar nicht geladen war. Der Hauptspeicher? Könnte sich Windows in beiden Versionen netzwerktechnisch anders verhalten, wenn es so viel Speicher hat?

 

Die paar verbleibenden PCs in dieser Konfiguration scheinen keine Probleme zu haben, aber die sitzen auch in Niederlassungen, die über DSL oder besser angebunden sind.

 

Das Rausfliegen aus dem SAP passiert übrigens nur bei Bearbeitungsschritten mit höherer Laufzeit, etwa wenn man eine längere Liste rechnet oder seine BANFen aufruft, dann aber recht reproduzierbar.

 

Dennoch ergeben die Symptome insgesamt noch kein greifbares Bild...

[Data1701 10]

Nun, da wir das Hotfix leider ausschließen können, müssen wir ja wohl woanders suchen.

 

Dann haben wir noch drei Möglichkeiten.

 

a. Ethereal auf die Clients drauf und mal mitsniffen was der Client so erzählt ;-).

 

b. Die rosa Jungs einmal den Verkehr mitsniffen lassen.

 

c. NTOP auf die Clients spielen (lokale Überwachung des Netztwerkverkehrs auf dem Client - läuft als Dienst) und dann mal schauen was da so passiert.

 

Gruß Data

[DeathAndPain 10]

Vielen Dank für den Tipp. Mit Ethereal habe ich vor längerem mal experimentiert, aber da war mir das Programm zu unhandlich. Jetzt habe ich es nochmal ausprobiert, und es hat sich deutlich verbessert. Mit der aktuellen Version kann man gut arbeiten.

 

Also habe ich mir einen Client-PC in der Niederlassung vorgenommen und dort Ethereal installiert. Außerdem habe ich einen Schnüffel-PC hier im Haupthaus (auf der Serverseite) an den VPN-Router mit rangehängt, so daß ich die ganzen durchlaufenden Daten abgreifen kann.

 

Erstaunlicherweise konnte ich von jenem Client-PC aus die SAP-Verbindungsabbrüche mühelos reproduzieren, obwohl er keiner der beiden obengenannten war und auch nicht die Sonderausstattung (512MB+Routenplaner) hat. Also sind vermutlich alle PCs in der Niederlassung betroffen, und die anderen Mitarbeiter rechnen nur halt nix, was länger dauert (oder schreien nicht, wenn es klemmt).

 

Nun wird die Sache interessant. Ich habe beide Ethereals auf Capture geschaltet und dabei ausschließlich auf Pakete zwischen dem Client-PC und dem SAP-Server gefiltert. Dann habe ich auf dem Client-PC eine SAP-Session gestartet und fett BANFen rechnen lassen. Der Verbindungsabbruch kam planmäßig, und ich bin im Besitz von Ethereal-Protokollen von beiden Seiten. Man kann also erkennen, was die beiden Rechner zueinander rausgeschickt haben und was sie von der Gegenseite empfangen haben. Jetzt geht es darum, die Protokolle zu interpretieren. Ich denke, daß im Bereich der Fernverbindung (einschließlich VPN-Tunnel) etwas schief läuft. Vielleicht kannst Du mir bei der Interpretation der Protokolle helfen? Ich habe sie in menschenlesbarer Textform hier abgelegt:

 

Clientseite: http://people.freenet.de/Death/ethereal/synchron_client.txt

Serverseite: http://people.freenet.de/Death/ethereal/synchron_server.txt

 

Die Zeitinformationen in den beiden Protokollen sind natürlich nicht völlig übereinstimmend. Ethereal fängt beim ersten Paket mit Null Sekunden an und zählt dann hoch. Insofern sind die Sekundenwerte in den beiden Protokolldateien aber fast übereinstimmend, weil das erste auf Clientseite ausgehende Paket natürlich Sekundenbruchteile später als erstes auf Serverseite eingehendes Paket erschienen ist.

[Data1701 10]

Hmh,

 

die Cap-Dateien wären schöner gewesen. Aber geht auch so. Anscheiend scheinen etliche Pakete verloren zu gehen, so dass der Server etliche Retransmissions vornimmt. Mag SAP nunmal nicht gerne.

 

Bitte überprüfe mal, ob Switch der NL und der Router wirklich beide mit 100 Mbit Fullduplex kommunizieren. Auto-negoation bitte ausschalten und auf manuell stellen. Es könnte gut sein, dass eine Komponente auf auto steht die andere jedoch auf 100 Full manuell. Das führt dann dazu, dass die Auto-Komponente sich nicht auf die Gegenstelle einschießen kann, da von der manuellen-Seite keine Infos abgegeben werden welcher Modus unterstützt wird. Wenn es schlecht läuft, dann hat man einmal 100 halfduplex und einmal fullduplex. Also CRCs bis zum abwingen.

 

In der SAP-Zentrale scheint ja alles Ok zu sein, da die anderen NLs sich nicht beschweren. Oder haben die auch Angst ;) .

 

Gruß Data

[DeathAndPain 10]

die Cap-Dateien wären schöner gewesen.

Hätten aber möglicherweise sensitive Daten enthalten, die man nicht gerne ins Internet stellt.

 

In Zusammenarbeit mit der Telekom hat der Fehler jetzt geklärt werden können. Die Lancoms auf beiden Seiten, die den VPN-Tunnel realisieren, führen offenbar eine Form von NAT durch (wohl weil jedes Paket im Internet die Zieladresse des anderen Tunnel-Lancoms erhalten muß. Der setzt die Ziel-IP dann wieder auf die des richtigen Rechners innerhalb unseres Netzes. So zumindest erkläre ich mir die Tatsache, daß man bei einer getunnelten Punkt-zu-Punkt-Verbindung überhaupt NAT braucht, obwohl die Lancoms letztlich alle Pakete an den dahinterliegenden Cisco-Router weiterreichen). Und bei NAT ist es halt so, daß sich der NAT-Router die Ports der offenen TCP-Verbindungen merken muß, damit er eingehende Pakete richtig zustellen kann. Dieses "Merken" unterliegt einem Timeout. Und der war so knapp eingestellt, daß der Lancom die TCP-Verbindung als nicht mehr existent betrachtet hat, wenn der SAP-Server zwei Minuten lang gerechnet hat, bevor er wieder eine Antwort an den Client geschickt hat.

[Data1701 10]

Na darauf soll mal einer kommen.

 

Wieder was gelernt. Danke für die Info.

 

Gruß Data

[Hr_Rossi 10]

hi

 

is ja echt krass !

hab zwar gewusst das man das tcp timeout einstellen kann bei NAT,

aber auf das hät ich nicht gedacht !

THX for info !!

 

lg

rossi

[Das Urmel 10]

Dieses "Merken" unterliegt einem Timeout. Und der war so knapp eingestellt, daß der Lancom die TCP-Verbindung als nicht mehr existent betrachtet hat, wenn der SAP-Server zwei Minuten lang gerechnet hat, bevor er wieder eine Antwort an den Client geschickt hat.

 

Wie gemein. :)