Sie sagen die Wahrheit, sofern sie nicht falsch erfasst wurden. In diesen Fällen können Pakete in der Tat fett gedruckte Lügen erzählen.
Beim Durchsuchen von Trace-Dateien können wir in den Paketen auf Symptome stoßen, bei denen so mancher überrascht die Stirn runzeln würde. Dies sind Ereignisse, die auf der Oberfläche seltsam erscheinen und sogar unsere Fehlerbehebung für eine Zeit ablenken können.
Einige dieser Probleme haben tatsächlich Netzwerk Analysten stundenlang irregeleitet, wenn nicht sogar Tage, wodurch sie Problemen und Ereignissen nachgejagt haben, die einfach nicht im Netzwerk existieren.
Die meisten dieser Beispiele können einfach vermieden werden, indem die Pakete von einem Netzwerk Test Access Point (TAP) aus erfasst werden, anstatt auf dem Rechner, auf dem der Verkehr erzeugt wird. Mit einem Netzwerk-TAP können Sie die Netzwerkdaten transparent und unverfälscht erfassen und sehen was wirklich über die Leitung übertragen wird.
Sehr große Pakete
In den meisten Fällen sollten Pakete nicht größer als das Ethernet-Maximum von 1518 Bytes sein, oder das was für die Link-MTU festgelegt wurde. Dies gilt jedoch nur dann, wenn wir nicht mit 802. 1Q-Tags verwenden oder uns in einer Jumbo Frame Umgebung befinden.
Wie ist es möglich Pakete zu haben, die größer sind als das Ethernet-Maximum? Einfach ausgedrückt, wir erfassen sie, bevor sie von der NIC segmentiert werden. Viele TCP/IP-Stacks verwenden heutzutage TCP Segmentation Offload, welche die Last der Segmentierung von Paketen an die NIC delegiert.
Der WinPcap- oder Libpcap-Treiber erfasst die Pakete, bevor dieser Vorgang stattfindet, sodass einige der Pakete viel zu groß erscheinen können, um legitim zu sein. Wenn die gleiche Aktivität auf dem Netzwerk erfasst wurde, würden diese großen Frames für den Transport in mehrere kleinere segmentiert.
Zero Delta Zeiten
Zero Delta Zeiten bedeutet, dass es keine gemessene Zeit zwischen den Paketen gibt. Wenn diese Pakete in das Erfassungsgerät gelangen, erhalten sie einen Zeitstempel und eine messbare Delta Zeit. Der Zeitstempel für den Eintritt auf dem Erfassungsgerät konnte nicht mit dem Paketaufkommen mithalten. Würden diese Pakete hingegen mit einem externen Tap-Server erfasst, könnten wir wahrscheinlich eine fehlerfreie Zeitstempelung erhalten.
Vorherige Pakete nicht erfasst
Diese Warnung wird angezeigt, weil Wireshark eine Lücke im TCP-Datenstrom bemerkt hat. Es kann anhand der sequenzierten Zahlen feststellen, dass ein Paket fehlt. Manchmal ist dies aufgrund des Upstream-Paketverlusts berechtigt. Allerdings kann es auch ein Symptom sein, dass der Analysator oder SPAN das Paket fallen gelassen hat, weil es nicht mit der Belastung mithalten konnte.
Nach dieser Warnung sollten Sie nach einer Reihe von doppelten ACK-Paketen suchen, anstatt eines defekten Pakets. Dies deutet darauf hin, dass ein Paket tatsächlich
verloren gegangen ist und erneut übertragen werden muss. Wenn Sie keine erneute Übertragung oder defekte Pakete sehen, konnte der Analyzer oder SPAN wahrscheinlich nicht mit dem Datenstrom mithalten. Das Paket war tatsächlich im Netzwerk, aber wir haben es nicht gesehen.
TCP ACKed unbemerkte Segmente
In diesem Fall wird eine Bestätigung für ein Datenpaket angezeigt, das nicht erfasst wurde. Das Datenpaket hat eventuell einen anderen Weg genommen, oder das Erfassungsgerät hat es einfach nicht wahrgenommen.
Vor Kurzem habe ich diese Ereignisse bei Trace-Dateien gesehen, die von Switches, Routern und Firewalls erfasst wurden. Da die Erfassung von Datenverkehr eine niedrigere Priorität als eine Weiterleitung hat (Gott sei Dank!), kann das Gerät schlichtweg einige der Frames im Datenstrom übersehen. Da wir die Bestätigung gesehen haben, wissen wir, dass das Paket es zu seinem Bestimmungsort geschafft hat.
Zum größten Teil sagen Pakete die Wahrheit. Sie können uns zur Hauptursache unserer Netzwerk- und Anwendungsprobleme führen. Da sie solche klaren und detaillierten Daten präsentieren, ist es sehr wichtig, dass wir sie so nah am Netzwerk wie möglich aufzeichnen.
Das bedeutet, dass wir sie während der Übertragung erfassen müssen, und nicht auf dem Server selbst. Dies hilft uns dabei, keine Zeit mit falschen Negativwerten zu verschwenden.
Wenn Sie mehr über die Berücksichtigungen von Netzwerkvisualisierungen für Fachleute erfahren möchten, dann kontaktieren Sie uns doch einfach – wir sind gerne für Sie da.
