[MKay]

OK, gut zu wissen, dass der Kernel schonmal keinen Unterschied macht

Es scheint nun so, dass ich das "Problem" behoben habe:
Ich habe den Server im Rescue Modus gestartet. Und nachdem eine Weile vergangen war hatte ich nicht einen einzigen Drop. Dann habe ich gesehen, dass er im Rescue Modus nur für IPv4 konfiguriert war. Also habe ich in der /etc/network/interfaces den IPv6-Part auskommentiert und normal gebootet. Und nach einer Stunde hatte ich ebenfalls keinen einzigen Drop. Danach wieder IPv6 aktiviert und kurz darauf gabs wieder Drops.
Dann habe ich wie in der der OVH-Hilfe angegeben, mal die IPv6-Adresse XXXX:XXXX:X:XXXX::1 statt XXXX:XXXX:X:XXXX:: konfiguriert. Und siehe da, nach einer Stunde immernoch keinen Drop
Da schwirren also irgendwelche IPv6-Pakete rum, die der Server nicht will und dann verworfen werden.

[marius]

Meistens den OVH-Kernel, aber auf einigen Systemen habe ich auch den Standard-Kernel, dann wenn Modulsupport benötigt wird.
Das ist aber nicht entscheidend, denn ich hab in beiden Fällen verworfene Pakete

[MKay]

Danke für die Info. Verwendest du den OVH-Kernel oder den Standard-Kernel deiner Distro?
Ich habe noch bemerkt, dass die Drops nicht weiter steigen, wenn man mit tcpdump alles auffängt.

[marius]

Wenn ich der einzige mit nem Debian 7 bin, der verworfene Pakete beobachtet, dann liegt evtl. irgendwo ein Problem vor oder der Server steht einfach auf Martian Pakete

Nö, bist du nicht

RX packets:1809174663 errors:0 dropped:34828 overruns:0 frame:0

Hab ich auf so gut wie allen Servern.

[MKay]

Naja, zumindest können verworfene Pakete etwas normales sein, müssen aber nicht
Die Frage ist, wie ich herausfinde, ob das ganze nun ein Problem darstellt oder nicht? Wenn ich der einzige mit nem Debian 7 bin, der verworfene Pakete beobachtet, dann liegt evtl. irgendwo ein Problem vor oder der Server steht einfach auf Martian Pakete

Nach meiner Recherche im Netz habe ich schon ein bisschen mit den sysctl-settings und eth0-Ring-Größen rumgespielt. Leider alles ohne Erfolg.

PS: Debian ist schon auf 7.8 geupdated. Der SYS Manager zeigt nur 7.5 an

Kleines Update:
Ein Blick in "ethtool -S eth0" offenbarte auch keine Fehler. Ich habe allerdings bemerkt, dass wenn der dropped-Counter hochzählt, auch der rx_multicast-Wert aus der ethtool-Ausgabe steigt ... leider jedoch nicht proportional: Der rx_multicast-Wert hat den dropped-Counter mittlerweile überholt.

[Knight]

Verworfene Pakete sind was ganz normales. RX ist ja dein eingehender Traffic daherhegend, hat dein System das Paket verworfen und nicht das RZ. Etwaige Sysctl Settings tun dies und/oder eine Firewall die temporär zb. Maritan Pakete blockt welche es über die sysctl erledigt. Dann steht dies in diesem Counter.

PS: Latest stable Debian ist 7.8 vllt. mal updaten

[Tibain]

Debian 7.5 mit Proxmox, ja

[MKay]

Danke dir. Ist das bei dir auch ein "normales" Debian von OVH?

[Tibain]

          RX packets:82091751 errors:0 dropped:0 overruns:0 frame:0
          TX packets:156437048 errors:0 dropped:0 overruns:0 carrier:0

Auf allen Interfaces

[MKay]

Ich bin auf folgende Seite gestoßen: https://www.novell.com/support/kb/doc.php?id=7007165
Dort steht, dass der dropped-Count uU normal sein kann. Testen lässt sich das ganze wohl, wenn man das Netzwerk-Interface in den promiscuous mode stellt. Dann sollte der dropped-Count nicht weiter steigen. Bei mir steigt er dann aber umso schneller

Kann hier jemand evtl mal schauen, was seine dropped-Counts so sagen?

[MKay]

Hi,

ich habe auf meinem neuen SYS-Server (Debian 7.5, RBX) bemerkt, dass Pakete gedroppt werden:

root@xxx:/# ifconfig
eth0      Link encap:Ethernet  Hardware Adresse xx:xx:xx:xx:xx:x  
          inet Adresse:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.xxx  Maske:255.255.255.0
          inet6-Adresse: xxxx:xxxx:x:xxxx::/64 Gültigkeitsbereich:Global
          inet6-Adresse: xxxx::xxxx:xxxx:xxxx:xxxx/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:3442698 errors:0 dropped:3349 overruns:0 frame:0
          TX packets:1800344 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:3445918847 (3.2 GiB)  TX bytes:1243842176 (1.1 GiB)
          Interrupt:20 Speicher:fe500000-fe520000

Hat jemand das gleiche Problem?
Hat jemand eine Ahnung, wie ich herausfinden kann, ob das ein Kernel, Hardware oder Netzwerk Problem ist?