Paketverluste beim Ping

[MacLux]

Hallo,

ich hab hier mit einem Sarge massive Probleme mit dem Erreichen des SSH-Servers.

Das ist eine noch recht nackte NetInstall, bei der bis auf die Multi-Core-Unterstützung im Kernel nicht viel vom Standard abweichendes installiert ist. Ich komme VOM Rechner netzwerktechnisch überall hin - auf andere Rechner im Firmennetzwerk, durch einen Proxy raus in die Welt, ich kann alles anpingen etc.

Will ich jedoch per ssh von einem anderen Rechner (Suse, anderes Debian, Windows etc.) auf den Problem-Rechner drauf, kann ich meistens weder den Namen auflösen noch per Ping die IP erreichen, geschweige denn per ssh eine Shell dort öffnen. Das Wort "Meistens" ist bewusst gewählt. Geh ich per ssh nämlich vom Problem-Rechner auf einen der anderen und geh von diesem per ssh sofort wieder zurück, geht alles prima: der Name wird aufgelöst, ping funktioniert, einloggen geht.

Dazu kommt noch folgendes Phänomen: Hämmere ich per Ping minutenlang auf Name oder IP des Problem-Rechners herum, steht dort zwar nur 'ne Zeit lang "Host unreachable", irgendwann überlegt er sich das jedoch und macht den Ping. DANN kann ich die Büchse auch wie gewünscht erreichen und mich drauf einloggen. Das geht dann einige Minuten gut, bis die Verbindung zusammenbricht und ich rausfliege. Dann ist er wieder nicht erreichbar.

Eine weitere Sache: Pinge ich vom Problem-Rechner einen anderen an, kommt es dort in regelmässigen Abständen zu Paketverlusten. Haben die anderen Rechner sich entschieden, den Problem-Rechner zu kennen, klappt der Ping von deren Seite her problemfrei.

Erste Lösungsansätze schlossen ein: IPv6 deaktivieren, andere (mit anderem Rechner funktionierende) Netzwerkdose benutzen, inetd manuell starten, mit strace nachschauen, ob der sshd überhaupt reagiert (tut er nicht, wenn "unreachable"), Haare raufen und fluchen.

Brachte natürlich alles nichts. Hat jemand 'nen Tipp für mich?

Grüsse,
Mac

 

[Goodspeed]

Haste mal mit tcpdump an dem Problemrechner gelauscht, ob überhaupt irgendwas ankommt?

Entsprechend der Fehlerbeschreibung würde ich das mal auf's Netzwerk bzw. ein "Fehlrouting" schieben ...

 

[rygar]

Hmm... könnte auch falsch eingestellte Netzwerkkarte sein (10/100 Mbit - Half/Full).

Vielleicht mal mit'm mii-tool schauen.

Netzwerkkabel, Firewall (wobei die sich ja selber beenden müßte ).

Hmm... dmesg könnte auch noch was ausgeben wenn die Karte nen Knacks hat.

 

[tux-alarm]

Firewall ? ...wird ja des öfteren vergessen... Ich spreche aus leidvoller Erfahrung !

 

[MacLux]

Firewall ? ...wird ja des öfteren vergessen... Ich spreche aus leidvoller Erfahrung !

Vielen Dank erstmal für die Tipps.

Firewall:
Hatte ich auch vermutet. Hab aber keine Einstellmöglichkeit im Gnome gefunden. Ich ging dann in meinem jugendlichen Leichtsinn davon aus, es wäre keine drauf. Wo würde man (unabhängig vom Typ) sehen, dass doch eine läuft und wie könnte man die dann abschalten? Eine andere als bei einer Standard-Netinstall kann (wenn überhaupt) eigentlich nicht drauf sein. (Wir haben das Ding so geliefert bekommen. Der Lieferant war Aber Freitagnachmittag leider nicht mehr erreichbar.)

Netzwerkkartenmodus:
Die Karte ünterstützt zumindest alle gängigen Modi, Protokolle etc. Hab da so ein schickes kleines Testgerät, das, angeschlossen an der Karte, nach kurzem Scan anzeigt, welche Modi die Karte kann. Dmesg zeigt auch an, dass da was dran hängt, was diese Modi gerade testet.

Dmesg:
Zeigt nichts an, was ein anderes (funktionierendes) Debian (im gleichen Firmennetz) nicht auch anzeigt.

tcpdump:
Hab ich noch nicht gestestet. Mach ich am Montag.

Wie könnte ein Fehlrouting verursacht werden? Doppelter Rechnername im Netzwerk oder sowas? Aber dann müsste ja wenigstens das Ansprechen per IP klappen. Vielleicht hat ja auch jemand von unseren Netzwerkleuten bei der Registrierung der MAC-Adresse geschlampt, und jetzt passen MAC und der vergebene Name nicht zusammen, weshalb die Anmeldung immer wieder zurückgesetzt wird und das Routing alle paar Sekunden in's Leere geht.

Gruss,
Mac

 

[Goodspeed]

iptables -L

sollte in deaktivierten Zustand nur die 3 Default-Queues mit policy ACCEPT ausgeben.

Fehlrouting:
Der Rechnername ist im Prinzip Wurst. Schlimmer sind doppelte IP's.
Ich weiß ja nicht, was ihr für Netzwerktechnik habt, aber vielleicht kann man an den Switches auch testen, wo was rein/raus geht ...

 

[MacLux]

iptables -L

sollte in deaktivierten Zustand nur die 3 Default-Queues mit policy ACCEPT ausgeben.

Ausgabe:
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Hmm, scheint keine Firewall aktiv zu sein...

Gruss,
Mac

 

[tr0nix]

Ich kenne solche Probleme von Loadbalancern die spinnen bzw. IPMP, kaputten Netzwerkkarten und wie oben angedeutet, full-duplex statt half-duplex, also falsche Settings