Paketverlust nachvollziehen

[Tockra]

Hallo Leute,

ich habe seit gut 6 Wochen das Problem, dass mein Teamspeakserver, der über meinen Unitymediaanschluss läuft, einen Paketverlust aufweist.
Leider tritt er relativ selten auf und ist recht klein 0,05% bis 30% (je nach Uhrzeit). Häufiger tritt der Verlust nachts auf. Dabei haben nur die Clienten, die übers Internet verbunden sind, einen Paketverlust. Wenn ich per Lan-IP auf den Server zugreife, liegt mein Paketverlust immer bei 0%. Damit könnte ich eigentlich einen Defekt des Servers bzw. der Netzwerkkarte ausschließen. Die Clienten haben unterschiedliche Internetanbieter und sitzen in unterschiedlichen Städten.
Aus meiner Sicht muss das Problem klar bei Unitymedia liegen.
Nun kann man mir bei Unitymedia nicht weiterhelfen und möchte mir einen Techniker vorbeischicken, dessen Kosten ich selbst übernehmen muss, falls der Fehler selbstverschuldet ist (oder einfach kein Problem festgestellt wird).
Vor letzterem habe ich Angst, da die Störung nicht allgegenwärtig ist, sondern nur sehr unregelmäßig und in kleinen Größen auftritt.

Aufbau der Hausverkabelung:

• Verschiedene Räume mit Netzwerkdosen
• Im Keller laufen die Steckdosen in einem geerdeten Patchpanel zusammen und gehen in einen Switch.
• An diesem Switch ist der Server direkt angeschlossen und ein Kabel geht vom Switch übers Patchpanel ins Wohnzimmer an den Router

Um nun auszuschließen, dass es an meinem Switch oder Patchpanel liegt, habe ich den Server nun ins Wohnzimmer mit einem anderen Lan-Kabel direkt an den zweiten LAN-Port der Fritzbox gehangen. Weiterhin kommt es dabei zu den Paketverlusten.
Nach meinem Ermessen MUSS dieser Fehler am Internet liegen und dürfte nicht selbstverschuldet sein.

Könnt ihr mir eine gute Möglichkeit nennen, auf einem Debian Server den Paketverlust zu messen? Mit einer Art Langzeittest ? Dann hab ich was in der Hand, falls der Techniker nichts findet.
Meine erste Idee wäre ein ping über eine längere Zeit. Das Problem dabei ist, dass ich befürchte, dass irgendeine Firewall dann nach einiger Zeit Pakete droppen würde und somit das Ergebnis verfälscht.
Habt ihr Vorschläge, wie ich mich verhalten sollte?

Viele Grüße
T

 

[madmax2010]

Wenn du genau nachvollziehen willst wann wo und wie viel packet loss besteht: Besorg dir eine RipeAtlas Probe und klickt dir einen kleinen test zusammen: https://atlas.ripe.net/
Wenn du mal eben checken moechtest wo gerade genau pakete verloren gehen, kanst du mtr gegen den server laufen lassen
Alternativ kannst du dir auch monitoring aufsetzen. Bspw. mit icinga oder prtg

Vermutlich genuegt mtr - wenn dein Modem / dein router die Pakete verlier siehst du das damit recht schnell

 

[nyxster]

Hatte dieselben Probleme nach der Umstellung auf Docsis 3.1, als UM von Vodafon übernommen wurde. Abhilfe schaffte eine aktuelle Fritzbox, die 3.1 unterstützt, sowie eine Neukalibrierung des Anschlusses (Techniker vor Ort). Da muss man aber am Telefon drauf bestehen, weil sie dir gern sagen, dass alles in Ordnung sei.

 

[JAIRBS]

Hast Du eine Fritzbox als Router? Die erkennt und listet CRC Fehler auf der Leitung, die zu Paketverlust führen. Das klappt bei DSL, ich denke auch bei Coaxial. Sollte hier - falls vorhanden - ein auffällig hoher Fehlerwert anliegen, dann weißt Du, dass das Problem am Internetanschluss liegt.

owie eine Neukalibrierung des Anschlusses

Ich weiß zwar nicht was exakt im Detail dort gemacht wird, aber habe schon oft mitbekommen, dass bei Coaxial Anschlüssen der Uplink "neu eingemessen" werden muss. Stellenweise wurden bei problematischen Anschlüssen auch Rückkanalverstärker zwischenverkabelt auf Kundenseite, weil die Leitung über die Zeit störanfälliger geworden ist.

 

[Tockra]

Hatte dieselben Probleme nach der Umstellung auf Docsis 3.1, als UM von Vodafon übernommen wurde. Abhilfe schaffte eine aktuelle Fritzbox, die 3.1 unterstützt, sowie eine Neukalibrierung des Anschlusses (Techniker vor Ort). Da muss man aber am Telefon drauf bestehen, weil sie dir gern sagen, dass alles in Ordnung sei.

Eigentlich war der Techniker vor meheren Wochen da, um das Problem der sporadischen Reconnects des Internets zu lösen. Das tat er auch. Dabei wurde das Problem wohl eingetauscht.

Hast Du eine Fritzbox als Router? Die erkennt und listet CRC Fehler auf der Leitung, die zu Paketverlust führen. Das klappt bei DSL, ich denke auch bei Coaxial. Sollte hier - falls vorhanden - ein auffällig hoher Fehlerwert anliegen, dann weißt Du, dass das Problem am Internetanschluss liegt.

Das Problem ist, dass der technische Mitarbeiter am Telefon mir nicht sagen kann, ab welcher Höhe der Fehler kritisch ist. Vor allem habe ich viele korrigierte Fehler und gar nicht mal soo viele nicht korrigierbare Fehler:

	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
	474	482	490	498	522	530	538	546	554	562	570	578	586	594	602	618	626	634	642	650	658	666	674	682	690	698	706	746	754	762	770
	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM	256QAM
	-4.8	-4.6	-4.3	-4.2	-3.9	-3.2	-3.0	-2.9	-2.9	-3.4	-2.4	-1.2	-0.9	-0.4	-0.4	0.2	0.4	0.8	0.6	0.7	0.8	0.7	1.0	0.6	0.6	1.3	1.3	2.0	1.9	2.3	2.5
	-35.8	-35.8	-36.4	-35.8	-36.4	-36.4	-36.6	-36.4	-36.6	-36.6	-36.4	-37.4	-37.4	-37.4	-37.6	-37.4	-37.6	-37.6	-37.6	-37.4	-37.4	-37.6	-37.4	-37.6	-37.6	-37.6	-37.6	-37.6	-38.6	-38.6	-37.4
	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32	0.32
	6060	6586	8073	9071	14237	12487	14122	14395	15205	15370	14508	13032	13441	13977	14344	16023	18914	20241	22143	21695	24406	25913	25283	25836	23450	22346	21289	16437	17048	15552	15278
	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0

Der Router wurde vor 20 Minuten ca. neugestartet, da ich mit dem Support telefoniert habe und die jetzt neuerdings am Ende eines Gespräches ungefragt und ohne Vorwarnung das Internet neustarten.

 

[Raijin]

So wie ich das verstanden habe steht der Server bei dir und der Paketverlust entsteht bei anderen, die mit deinem Server verbunden sind?

Paketverluste sind tricky und Tools wie WinMTR, PingPlotter oder auch die zugrundeliegenden tracert/traceroute Kommandos vermitteln nicht selten ein falsches Bild, weil sie schlicht und ergreifend falsch interpretiert werden. Nur dann, wenn in der Ziel-Zeile Paketverluste und/oder Pingspitzen auftauchen, kann man einen Blick auf die Hops dazwischen machen. Ist am Ziel aber alles ok, ist es unerheblich was an den einzelnen Hops passiert.

 

[Tockra]

Bisher konnte ich den Paketverlust nur durch die Verbindungsinformation des Teamspeaks und die deutlich schlechter werdende Sprachqualität "messen". Ich probiere gerade mal die Software-Variante von RIPE-ATLAS wobei ich bisher nicht weiß, ob die Anwendung dafür da ist Paketverluste zu messen.

 

[Raijin]

Prinzipiell sind Paketverluste bei TeamSpeak nicht ungewöhnlich im eigentlichen Sinne. Standardmäßig benutzt TS nämlich das UDP-Protokoll und das ist verbindungslos. Das heißt, dass es keinen protokoll-eigenen Mechanismus gibt, der sicherstellt, dass alle Pakete ankommen. UDP ist daher auf Performance ausgelegt, also schnelle Datenübertragung ohne für den jeweiligen Zweck unnötigen Overhead des Protokolls. Dewegen wird bei UDP in Kauf genommen, dass unterwegs unter Umständen Pakete verloren gehen können.
Das ist auch ok so und nachvollziehbar. Beim Download einer Datei wäre es fatal, wenn auch nur ein einziges Byte fehlt, weil die Datei damit komplett unbrauchbar werden kann. Dagegen ist es bei Voice-Übertragungen eben einfach nur ein kurzer "Knacks".

Damit will ich sagen, dass die alleinige Existenz eines Fehlerzählers bei TeamSpeak nicht der Gradmesser sein sollte. Wenn du tatsächlich eine schlechte Sprachqualität und/oder gar massive Aussetzer bemerkst, ist das etwas anderes. Wäre die Sprache aber ok, könnte dir der Fehlerzähler egal sein, weil er dann auch einfach egal ist
Ich meine mal gelesen zu haben, dass bei TeamSpeak alles unter 5% unkritisch sein soll.

 

[Tockra]

Es geht dabei um das gehäufte Auftreten von Paketverlusten. Ich kenne die Unterschiede zwischen TCP und UDP, allerdings erklärt die Verwendung von UDP alleine nicht ein Paketverlust über 0% bei allen Clients zu bestimmten Zeitpunkten. Während die selben Clients auf anderen Teamspeak Servern zu diesen Zeitpunkt 0,00% Paketverlust haben.

 

[Raijin]

Paketverluste entstehen u.a. wenn Knotenpunkte im www überlastet sind. Insbesondere bei Kabel-Internet, das nun mal per Definition ein shared Medium einsetzt - man teilt sich ja die Bandbreite mit anderen Kunden am selben Kasten - kann das natürlich häufiger passieren, wenn die anderen Kunden ihrerseits die Leitung belasten. Es ist daher nicht ungewöhnlich, dass man bei Kabelinternet über den Tag verteilt schwankende Downloadraten bemerken kann und ggfs eben auch zu bestimmten Zeiten mal Paketverluste.

Wie gesagt, alles unter 5% sollte unkritisch sein. Wenn es tatsächlich mehr ist und/oder massive Qualitätsverluste hörbar sind (so wie du es ja beschrieben hast), ist sicherlich etwas im Busch. Ich wollte nur darauf hinaus, dass der Fehlerzähler als solches nicht zwingend auf ein Problem hindeuten muss.

Während die selben Clients auf anderen Teamspeak Servern zu diesen Zeitpunkt 0,00% Paketverlust haben.

Hast du denn auf anderen TS-Servern Paketverluste? Wie oben beschrieben kann es ja durchaus sein, dass es an deiner Leitung liegt. Insbesondere wenn ein Techniker kommen soll, ist es natürlich ungünstig, wenn das nur sporadisch auftritt oder genau in dem Zeitfenster kommt, in dem immer alles gut läuft. Paketverluste sind schwierig zu diagnostizieren, weil sie in der Regel außerhalb deines Einflussbereichs entstehen, irgendwo auf dem Weg von A nach B.

Ich würde vorschlagen, dass du bei deinen Kumpels jeweils einmal PingPlotter oder WinMTR laufen lässt. Ziel: Dein TS-Server. Nachdem du alle Ergebnisse eingesammelt hast, vergleichst du sie und schaust ob sich Parallelen zeigen. Dazu ein kurzer Hinweis wie man sowas deutet:

Kein Problem:

Hop	PL	Ping
1	0	1 ms
2	0	200 ms
3	100	Timeout
4	0	15 ms
Ziel	0	20 ms

Problem:

Hop	PL	Ping
1	0%	1 ms
2	0%	200 ms
3	100%	Timeout
4	30%	210 ms
5	30%	215 ms
Ziel	30%	220 ms

Der Trick liegt darin, Folgefehler zu identifizieren. Im ersten Beispiel ist das Ergebnis am Ziel 100% ok. Keine Paketverluste, Ping in Ordnung. Die Tatsache, dass Hop 2 mit 200 ms einen miesen Ping hat und Hop 3 gar in einen Timeout rennt und 100% Paketverluste zu verzeichnen hat, spielt keine Rolle, weil die Hops genau so konfiguriert ist.

Im zweiten Fall sieht das anders aus. Hop 2 reagiert immer noch langsam, aber dieses Mal bleiben die 200 ms als Offset für alle folgenden Hops bis zum Ziel bestehen. Das gleiche gilt hier nun beim Paketverlust an Hop 4, der sich ebenfalls nach unten fortsetzt.

Sammle also WinMTR/PingPlotter-Logs deiner Clients ein und vergleiche sie. Wenn sich an ein und demselben Hop die Paketverluste konzentrieren und dieser mit Glück sogar innerhalb des Netzwerks deines Providers ist, hast du gute Karten, wenn du den Support kontaktierst.



Wenn alles nix hilft, sollte jemand anderes den TS hosten. Ich selbst würde mir das sowieso nicht mehr antun, weil man TS bereits ab ~15 cent pro Slot pro Monat mieten kann. Ein 10er Server kostet folglich nicht einmal 2 Euro im Monat und ist 24/7 verfügbar, kostet keinen Strom und keine Wartung und braucht keine Portweiterleitung im Router

 

[error]

Moin,

lass es mich so sagen, wie du die Ursache der Verluste findest: Gar nicht!

Um ein solches Problem zu indentifizieren und zu analysieren reicht es nicht am Server zu messen. Für diesen Fall, muss am Client und am Server mitgeschnitten werden. Hinzu kommt, da der Fehler wohl nur sporadisch auftritt, Massen an Daten anfallen, die du alle auswerten musst. Sofern du nicht Einfluss auf das Netz dazwischen hast oder es genau abgrenzen kannst, wirst du das Problem nicht lösen. Dazu wird noch UDP als Protokoll verwendet, was es nicht einfacher macht. Und dann reden wir von Verlusten im Promillebereich! Lass dir das von jemandem sagen, der fast tagtäglich soetwas analysieren und auswerten darf. Du suchst die Nadel im Heuhaufen.

Wenn du von dir (deinem Server) Testpakete ins Internet schickst, dann kannst du nur sagen, dass bei dir vermutlich alles stimmt. Wobei ich davon ausgehe, dass du einen Privatkundenanschluss hast und sich der Provider nicht für deine Probleme interessieren wird.
Es ist auch nicht unüblich, dass Unitymedia/Vodafone/Kabelnetzanbieter in den Abendstunden überlastet sind. Da gibt es eben Spitzen und Pakete werden verworfen. Das ist normal und auch gewollt.

gruß

PS: Sorry, wenn das jetzt so hart klingt, aber das zeigt einfach die Erfahrung. In solchen Fehlern kannst du Tage vergraben, wenn du nicht direkt etwas findest. Vorallem wenn es über das "Internet" geht. Da ist alle Hoffnung verloren...

EDIT: Ist dein Paketverlust im Zeitfenster von ca. 18-22/24 Uhr Abends dann ist es zu 99% ein überlasteter Knoten im Netz der Unitymedia/Vodafone.

 

[JAIRBS]

@Tockra Testet doch einfach mal Discord. Discord zeigt auch CRC loss an. Wenn Du das Problem da auch hast weißt Du eigentlich auch ziemlich sicher, dass es an der Internetleitung und nicht am Server liegt.

 

[Tockra]

@Tockra Testet doch einfach mal Discord. Discord zeigt auch CRC loss an. Wenn Du das Problem da auch hast weißt Du eigentlich auch ziemlich sicher, dass es an der Internetleitung und nicht am Server liegt.

Naja oder an meinem Rechner oder irgendeinem Bauteil zwischen Rechner und Router...