Temporär hoher Packet Loss

[svenhenry]

Hallo,

ich betreibe mit einem Freund einen Root-Server auf dem Debian 6 läuft.
Seit einiger Zeit haben wir immer mal wieder einen hohen Packet Loss.

Wir betreiben einen relativ großen Public TS3-Server und fünf Minecraft-Server.

Wenn dieser hohe Packet Loss auftritt, bekommen eig. alle Leute auf unserem TS und MC-Servern einen Disconnect (ist ja klar bei einem Loss von etwa 20%).

Dieser hohe Packet Loss normalisiert sich nach etwa 15 Minuten wieder.

Da dieser hohe Packet Loss nur sehr unregelmäßig vorkommt und immer gegen Abends, sind wir eig. der Meinung das unser Provider evtl. ein Problem hat.

Dieser bestreitet dies jedoch und meint, dass es an unserem System liegt, da sie keine Fehler finden können.
Auch wir können keine Fehler finden, aber wir kennen uns auch nicht so gut aus mit Debian. Haben auch schon mtr vom und zum Server gemacht, mit iptraf den Netzwerkadapter auf Fehler untersucht.

Wir hoffen Ihr könnt uns evtl. Tipps geben woran es liegen kann?

Vielen Dank für jede Hilfe!

[syssi]

Mittels mtr kann man solche Probleme normalerweise schnell dem Provider in die Schuhe schieben. Jeder seriöse Provider erbittet normalerweise einen solchen Mitschnitt, wenn es zu besagten Problemen kommt.

[svenhenry]

Wir haben schon einen MTR zu unserem Provider geschickt.

Hier die richtung "client --> server"

|------------------------------------------------------------------------------------------|
| WinMTR statistics
|
| Host - % | Sent | Recv | Best
| Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.2.1 - 0 | 675 | 675 | 0
| 0 | 3 | 0 |
| 217.0.116.80 - 3 | 612 | 596 | 38
| 40 | 111 | 39 |
| 217.0.69.182 - 0 | 675 | 675 | 39
| 43 | 77 | 43 |
| f-ee5-i.F.DE.NET.DTAG.DE - 0 | 675 | 675 | 43
| 48 | 148 | 44 |
| 194.25.211.54 - 0 | 675 | 675 | 44
| 48 | 96 | 59 |
| 217.118.16.26 - 1 | 656 | 651 | 47
| 49 | 91 | 48 |
| 217.118.16.163 - 0 | 675 | 675 | 47
| 48 | 152 | 48 |
| triton497.server4you.de - 12 | 460 | 406 | 47
| 49 | 125 | 48 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud
Provider


---------------------------------------------------------------------
und hier vom Server zum Client:

Host Loss% Snt Last
Avg Best Wrst StDev
1. static-ip-85-25-99-2.inaddr.ip-pool.com 14.0% 279 1.0
3.7 0.9 76.9 12.7
2. 217.118.16.162 28.0% 279 0.2
4.2 0.2 75.5 14.5
3. 217.118.16.29 15.8% 279 0.4
1.8 0.3 75.4 7.6
4. 217.118.16.25 14.7% 279 3.3
7.5 3.2 86.5 14.3
5. 194.25.211.53 14.7% 279 3.2
7.4 3.2 78.7 14.3
6. m-ea1-i.M.DE.NET.DTAG.DE 15.1% 278 11.2
12.3 9.2 87.0 9.9
7. 217.0.69.181 16.2% 278 12.3
12.1 9.1 85.0 12.0
8. p54981A8F.dip.t-dialin.net 14.0% 278 46.8
49.0 45.9 123.9 11.9


An dem oberen MTR sieht es so aus, als wäre alles an unserem Server verloren gegangen...
Aber ich kann mir nicht vorstellen, das unsere Netzwerkkarte kaputt ist, da dieses Problem nicht jeden Tag existiert.
Jmd. vill eine Idee, ob eine falsche Konfiguration schuld daran ist?

[Cae]

Bitte lerne,

Code: Alles auswählen

-Tags zu verwenden. Das da oben ist unlesbar.

Gibt es eine Firewall? Falls ja, was gibt iptables-save dazu aus?

Gruß Cae

[svenhenry]

Sry, der Auszug war nicht direkt aus Putty sondern aus dem SupportTicket mit unsrem Provider.

Hier ist der Auszug aus iptables-save

Code: Alles auswählen

# Generated by iptables-save v1.4.8 on Thu Sep 20 16:45:41 2012
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [12664:26139878]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8447 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 9987 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 7913 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8899 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 1337 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 6666 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 4657 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 7070 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 2012 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8181 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 30033 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 10011 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 19000 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 21000 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22500 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 23000 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 24000 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 25565 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 25566 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8192 -j ACCEPT
-A INPUT -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth0 -m state --state NEW -j ACCEPT
-A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Thu Sep 20 16:45:41 2012

[unitra]

Aber ich kann mir nicht vorstellen, das unsere Netzwerkkarte kaputt ist...

Sag doch einfach du hast es nicht überprüft.
Schau mal ob Ethernet Frames verworfen wurden, ob es RX oder TX Fehler gibt auf der NIC

Code: Alles auswählen

ifconfig

Schon mal den Duplex Status überprüft? Kann sein das die NIC momentan mit Half-Duplex synchronisiert, da ein Adernpaar defekt ist im Kabel.

Code: Alles auswählen

ethtool -a DEVNAME

Bei Half-Duplex würde die Fehlermeldung passen zeitweise Packetloss, und zwar dann wenn RX und TX gleichzeit die Frames schicken/empfangen müssen (CSMA), Carrier Sense Multiple Access. Ich kann nur senden oder empfangen wenn das Segment nicht belegt ist.
Prüfe die Layer1 und Layer2. Ich kann den MTR zwar nicht entziffern, aber deiner Aussage nach wäre der Packetloss lokal.
Kannst schon ein neues Kabel auspacken und einfach austauschen. Oder auf einen anderen Switchport stecken und beobachten.

[syssi]

Der Trace vom "Server zum Client" kann verfaelscht sein und ist deshalb in deinem Fall nicht aussagekraeftig. Die andere Richtung zeigt recht deutlich, dass an deinem Server der Verlust entsteht.

[svenhenry]

Hi,

erstmal danke für die Antworten.

Bei

Code: Alles auswählen

ifconfig

kann ich keine fehler sehen. Aber es gab/gibt 11 Interrupts? Was bedeutet das?

Code: Alles auswählen

eth0      Link encap:Ethernet  HWaddr 00:19:99:c2:36:f6
          inet addr:85.25.99.41  Bcast:85.25.99.127  Mask:255.255.255.128
          inet6 addr: fe80::219:99ff:fec2:36f6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2784380236 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5728029600 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:391687456550 (364.7 GiB)  TX bytes:846629230259 (788.4 GiB)
          Interrupt:11

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1575605 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1575605 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:867340162 (827.1 MiB)  TX bytes:867340162 (827.1 MiB)

bei

Code: Alles auswählen

ethtool -a eth0

kommt volgendes herraus. Ich kann aber mit dieser Aussage nichts anfangen.

Code: Alles auswählen

Pause parameters for eth0:
Autonegotiate:  on
RX:             off
TX:             off

Laut

Code: Alles auswählen

ethtool eth0

sollte die NIC aber auf 100/Full laufen.

Code: Alles auswählen

Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: No
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes

Wie meinst du das mit Layer1 und Layer2?

[Cae]

Aber es gab/gibt 11 Interrupts? Was bedeutet das?

Das ist kein Zähler, sondern ein Zustand. Der Prozessor tut irgendwas, ein Paket kommt auf die Netzwerkkarte und könnte weiterverarbeitet werden. Allerdings kann das der Prozessor nicht riechen, und immer nachgucken wäre ineffizient. Also sagt die Netzwerkkarte dem Prozessorkern Bescheid, der springt in seine interrupt service routine, macht irgendwas mit dem Paket und fährt dann mit seiner normalen Arbeit fort. Besagte Karte verwendet die physikalische Interruptleitung Nummer 11.

Was meinst du mit Layer1 und Layer2?

unitras Hinweis impliziert, dass du dich mit deiner Technik auskennst. Das tust du offensichtlich nicht, sonst würdest du nicht so nachfragen. Denk' mal drüber nach, ob das nicht der falsche Platz für dich zum Rumspielen ist.
Im OSI-Schichtenmodell ist Layer 1 die physikalische Schicht (das Kabel, die Stromsignale darauf) und Layer zwei typischerweise der Bereich der MAC-Adressen, von ARP und so weiter. Alles unterhalb von IP und nur im Netz messbar, in dem das Gerät selbst steht.

Wie hoch ist die Uptime von der Kiste? Was wird da typischerweise drauf gemacht? Ein Terrabyte Traffic ist eine Menge Holz.

Gruß Cae

[svenhenry]

Ah ok, danke für die Aufklärung.

Ich dachte mir schon das er das OSI-Schichtenmodell meint, aber ich wüsste jetzt nicht wie ich das "testen" kann. Da ich keinen Zugang zum Server habe.

Die Uptime ist bei 55 Tagen, und es läuft ein TS3-Server und 5 Minecraft-Server, aber dies sollte eig. nicht die Ursache sein, da es eine Zeit lang keine Probleme gab....

[unitra]

Hier noch einmal ausführlich was die einzelnen OSI Layer machen, und wie man sie einordnen kann in deinem Beispiel:

Layer 1 sind die Kabel, Steckverbindungen. Alles physikalische was du anfassen kannst, NIC, Kabel, Module, Switchports. etc.
Layer 2 ist in deinem Fall Ethernet, reines Ethernet ohne IP Adresse. Nur die Ethernetframes
Layer 3 wäre dann IP Adresse.
Layer 4 ist dann UDP/TCP in deinem Fall. TCP Session Aufbau. UDP Packete senden

Die Layer 5-7 sind eigentlich recht uninteressant.

Danke Cae.

Ich sehe momentan in deiner Konfiguration keinen Fehler für die beschriebenen Layer1-3.
Du könntest noch wenn der Fehler wieder mal aufkommt folgendes dir anschauen
Am Server kannst du dann den MTR laufen lassen und nachschauen wo der Packetloss herkommt, die Uhrzeit wäre dann wichtig wenn du dass bei deinem RZ provider melden möchtest dass die das überprüfen sollen.

Code: Alles auswählen

ethtool -S eth0 | grep -i error

Schau mal wie das Routing jetzt ist mit mit traceroute, speichere die Datei ab. und vergleiche ob der erste IP Hop hinter deinem Traceroute eine andere IP Adresse hat, wenn das Problem wieder aufkommt. Jetzt nur von dem Server aus gesehen.

Anschliessend mache noch einen Traceroute von deiner Workstation jetzt, und speichere es ab, und vergleiche es mit dem Traceroute wenn das Problem auftaucht. Es kann nämlich sein dass es auch asymmetrisches Routing gibt.

Das sind nur Tests, und müssen nicht zutreffen. Hilft aber wenn du die Ursache des Packetloss lokalisieren willst.

Es kann auch sein dass der Uplink zum RZ überlastet ist, was nicht dein Fehler ist sondern des RZ betreibers.
Es kann auch sein dass die IP Packete verworfen werden an einer RZ Firewall, weil sie ausgelastet ist, dann werden IP Packete schon mal gedroppt.

[svenhenry]

Hey,

vielen Dank für die Rückmeldungen, ich glaube ich habe das Problem gefunden und beseitigt. Der Server läuft nun schon seit 2 Wochen stabil

Falls jmd. das gleiche Problem hat:

Wahrscheinlich war der Grund für die Ausfälle "brutforce" Attacken (sieht man im /var/log/auth.log). Habe nun Fail2ban installiert.

Nochmals vielen Dank Community