Re: AW: Debuggen von Netzverbindungen [Virus checked w/ScanMail]

Hallo,

Das Problem sind nicht so sehr die Zahl der Fehler, sondern die Art:

frame:6441

Ein "Frame Error" heißt, das ein Paket empfangen wurde, das nicht durch 8 
teilbar ist (alle Ethernetpakete müssen das sein).

Das wiederum kann nur vorkommen, wenn entweder die Netzwerkkarte der 
Gegenstelle defekt ist (dann geht dort aber gar nichts mehr), oder aber wenn 
es Kollisionen gibt, dann bleiben nämlich Fragmente auf dem Kabel übrig.

Dasselbe sagt der zweite Fehler:

carrier:2

"Carrier" heißt, das die Netzwerkkarte senden wollte, das Kabel aber belegt 
war.

Beide Fehler zusammen deuten auf einen beliebten Fehler im Netzwerkumfeld hin, 
nämlich das "FullDuplex-HalfDuplex-Autonegotiation-Problem".

Dieses entsteht, wenn eine Seite mit FullDuplex (FD) arbeitet, und die zweite 
mit Halbduplex (HD)...dann denkt nämlich der, der FD spricht, das das Kabel 
nie belegt sein kann (ist ja Fullduplex) und sendet immer munter drauf los, 
ohne vorher reinzuhören, ob er jemanden stört.

Die Station, die HD macht, sieht dann ständige Kollisionen, weil die 
FD-Station ständig "reinquatscht". Je nach bevorzugter Datenrichtung (senden 
oder empfangen) gehts dann mal ganz gut und mal fast gar nicht.

Passieren tut so ein Problem übrigens gerne "durch Menschenhand":
Ethernet kennt eine sog. "Autonegotiation", dabei machen beide Geräte (Switch 
und Server oder Client) aus, welche Übertragungsart gefahren wird, also 
entweder 100MBit/FullDuplex oder 100MBit/Halfduplex. (bei 10MBit gibts 
FullDuplex theoretisch zwar auch, macht praktisch aber fast keiner.) 

Haben beide Stationen diese "Autonegotiation" eingeschaltet, dann einig man 
sich in 99% der Fälle auf den höchstmöglichen Standard, den beide 
unterstützten, meist 100MBit/FullDuplex.

Wird jetzt aber auf einer der beiden Systeme diese "Autonegotiation" 
abgeschaltet, weil man z.B. die Switchports fest konfiguriert (auf 
100MBit/FullDuplex), dann klappt das "Ausmachen" des Standards nicht mehr, da 
das Gerät, das fest konfiguriert ist, auf die Anfragen des anderen Systems 
gar nicht mehr antwortet. 
Dieses System geht dann in einen Sicherheitsmodus, und der heißt "Halbduplex". 

Die Folge ist dann ein Switch, der 100MBit/FD spricht und ein Server, der 
100MBit/HD spricht und dazwischen ein Kabel, auf dem sich die Kollisionen 
prügeln.....und schon hängt die Server-Performance im Schacht und keiner 
weiß, worans liegt.

Die Lösung ist einfach:
Entweder den Switchport wieder auf "Auto" zurückstellen, oder den Server 
ebenfalls auf "100MBit/FD" einstellen, letzteres geht bei RedHat über das 
Tool "ethtool" oder das "mii-tool".

Gruß,
Frank.

Am Mittwoch, 8. September 2004 13:31 schrieb Ullrich Ralf:
> das habe ich gerade gemacht und folgendes kam bei raus:
>
> UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> RX packets:1726155 errors:6400 dropped:0 overruns:0 frame:6441
> TX packets:675702 errors:2 dropped:0 overruns:0 carrier:2
> Ist das Im Rahmen des Erträglichen oder schon ein Problem?

-- 
Frank Schneider, <[email protected]>.                           
People would rather live with a problem they cannot solve,
than accept a solution they cannot understand.
... -.-