This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Paketverlust bei Echtzeitanwendungen

Hallo in die Runde,

vielleicht habt ihr ja noch einen Hinweis oder einen Tipp:

Das Problem:
Wir bemerken in unserem Bürobetrieb immer wieder verlorene Pakete bei Echtzeitanwendungen wie Telefon, Videokonferenzen oder Multiplayer Spielen (teil unseres Kerngeschäfts). Der Fehler tritt seit einigen Monaten auf.

Unser Netzwerkaufbau:
Glasfasermodem / VDSL Modem / DSL Modem -> Sophos SG210 als Firewall, Router und DHCP Server -> "Backbone" Switch -> Unterverteiler Switches in einzelne Gebäudeabschnitte

Die Tests:

Pingtests
Um das Problem zu eruieren haben wir einen Pingtest laufen lassen in drei Segmenten simultan.
Zum einen senden wir einen Dauerping durch unser internes Netz auf unser Glasfasermodem, zum anderen einen Dauerping durch unser LAN über das DSL Modem (an der Firewall vorbei) durch das WAN auf unser Glasfasermodem und als Drittes von einem Cloud Anbieter auf unser Glasfasermodem.

Ergebnis Pingtest
Die Laufzeiten intern -> Glasfasermodem lagen zum größten Teil wie zu erwarten im kleinen einstelligen Millisekundenbereich. Allerdings gehen die Zeiten alle paar Minuten für ein paar Sekunden hoch bis zu 50ms.
Die Laufzeiten intern -> DSL -> Glasfasermodem verhalten sich genauso wie der "interne" Test nur wie zu erwarten mit grundsätzlich erhöhten Laufzeiten.
Die Laufzeit von dem Cloudanbieter -> Glasfasermodem waren jetzt über Wochen komplett stabil zwischen 5-7ms.

Nach diesem Test haben wir erwartet, dass wir ein Problem in unserem Switch Routing haben, da wir die Firewall und unseren Provider ausschließen konnten.


Teamspeak Test
Da der Fehler unregelmäßig auftaucht und auch nicht immer im selben Maße, haben wir getestet ob wir über den VoIP Dienst "Teamspeak" (TS) den Fehler reproduziert bekommen. Wir haben uns für TS entschieden, da TS Metriken ausgibt über die Verbindungsqualität inkl. verlorener Pakete.
Durch unsere managed Switche war das Routing zudem sehr leicht zu verändern um unterschiedliche Netzsegmente einzeln testen zu können.

Ergebnis TS Test
Wir konnten den Fehler reproduzieren und haben festgestellt, dass wir über einen Zeitraum von zwei Stunden etwa 4-6 Peaks haben mit einem Paketverlust von 0,3% bis zu 35%.

Maßnahme 1: Wir haben unseren Backbone Switch getauscht, da wir eine Überlastung desselbigen vermutet haben.
Ergebnis: Keine Verbesserung
Maßnahme 2: Wir haben nach und nach Netzwerksegmente physikalisch abgeschaltet um ein fehlerhaftes Gerät ausschließen zu können
Ergebnis: Keine Verbesserung
Maßnahme 3: Wir haben die Testrechner an der Firewall vorbei geroutet
Ergebnis: Eine deutliche Verbesserung. Auch nach 16 Stunden war kein Paketverlust zu erkennen. Der Gegentest bei selbem Setup durch die Firewall bestätigte uns in unserer Vermutung und der Fehler ist wieder aufgetaucht.

Stand Jetzt: Wir vermuten einen Konfigurationsfehler oder Software Bug in der Firewall. Die CPU Last liegt dauerhaft bei unter 50%, daher auch die Vermutung auf Konfiguration oder Software, da eine Überlastung scheinbar auszuschließen ist. Zudem ist meiner Ansicht nach das Fehlerbild sehr ungewöhnlich für einen Hardware defekt.
Ich würde als nächsten Test nun die Intrusion Prevention für zwei Stunden ausschalten und den TS Test erneut wiederholen, es sei denn ihr habt noch einen heißen Tipp für uns. 

Ich freue mich auf eure Kommentare.

Lieben Gruß,

Moritz



This thread was automatically locked due to age.
Parents Reply Children
No Data