Eleu Geschrieben 13. Januar 2010 Geschrieben 13. Januar 2010 Hallo, ich hätte mal eine Frage zum Thema Switch. Und zwar geht es mir um die von einigen Switchen implemtierte Arbeitsweise "Cut-Through" Bei wiki steht: http://de.wikipedia.org/wiki/Switch_(Computertechnik) Hierbei schaut der Switch beim eingetroffenen Frame nur auf die Ziel-MAC-Adresse, trifft eine Weiterleitungsentscheidung und schickt den Frame entsprechend weiter. Um Zeit zu sparen wird der Frame nicht auf Fehlerfreiheit geprüft. Der Switch leitet deshalb auch beschädigte Frames weiter, diese müssen dann durch andere Schicht-2-Geräte oder höhere Netzwerkschichten aufgefangen werden. Was für Geräte sind das, die das dann auffangen ? Ist es so, dass TCP (Schicht 4) fehlerhafte Frames herausfiltert oder benötigt man hierfür ein besonderes Protokoll ? Gruß Eleu Zitieren
axxis Geschrieben 13. Januar 2010 Geschrieben 13. Januar 2010 Das Zielgerät muss dann anhand der FCS eine Fehlererkennung durchführen. Gruß Hauke edit: Sollten dann Frames fehlerhaft sein, fordert das Endgerät diese erneut beim Quellgerät an. Zitieren
VaNaTiC Geschrieben 13. Januar 2010 Geschrieben 13. Januar 2010 Also mir persönlich sind keine Geräte bekannt, die sich speziell zwischen eine Ethernet-Verbindung schalten lassen und defekte Ethernet-Frames (Schicht 1/2) herausfiltern. Denn das ist Teil der Implementierung eines jeden IP-Stacks bzw in diesem Fall Treiberangelegenheit. Wenn der Ethernet-Frame defekt am Zielgerät ankommt und dort aus Schicht 2 kein Paket der Schicht 3 extrahiert werden kann, wird das i.d.R. einfach verworfen. Zitieren
Eleu Geschrieben 13. Januar 2010 Autor Geschrieben 13. Januar 2010 Wenn der Ethernet-Frame defekt am Zielgerät ankommt und dort aus Schicht 2 kein Paket der Schicht 3 extrahiert werden kann, wird das i.d.R. einfach verworfen. Aber wie kann man denn gewährleisten, dass alle Daten am Zielgerät korrekt zusammengesetzt werden, wenn defekte Frames nicht noch mal neu bei der Quelle angefordert werden ? Ich gehe mal davon aus, dass in solchen Switchen ohne Kollisionsdetektion gearbeitet wird (CDMA/CD), sonst muss der Switch ja doch wieder warten. Was ist denn FCS ? Zitieren
VaNaTiC Geschrieben 13. Januar 2010 Geschrieben 13. Januar 2010 Hmm, da bin ich anscheinend einer Fehlinformation in meinem Kopf auf den Leim gegangen was das Verwerfen betrifft. FCS ist ein CRC über einen Teil des Ethernet-Frame: Ethernet ? Wikipedia Du meintest wahrscheinlich CSMA/CD, nicht CDMA/CD, oder? Kollisionen sind bei Switches eigentlich nicht möglich, hier ist eher das flow-control relevant. Zitieren
lordy Geschrieben 13. Januar 2010 Geschrieben 13. Januar 2010 Um die erneute Übertragung kümmert sich in dem Fall TCP, denn das erkennt, anhand der Sequenznummer, das ihm Pakete fehlen, die evtl. auf unteren Layern verworfen wurden. Zitieren
Eleu Geschrieben 13. Januar 2010 Autor Geschrieben 13. Januar 2010 (bearbeitet) Hmm, da bin ich anscheinend einer Fehlinformation in meinem Kopf auf den Leim gegangen was das Verwerfen betrifft. FCS ist ein CRC über einen Teil des Ethernet-Frame: Ethernet ? Wikipedia Du meintest wahrscheinlich CSMA/CD, nicht CDMA/CD, oder? Kollisionen sind bei Switches eigentlich nicht möglich, hier ist eher das flow-control relevant. Habe mich verschrieben und vertan. In einem geswitchten Netz besteht die Kollisionsdomäne ja nur aus zwei Stationen, dem Host und dem Switchport. Also is nix mit Kollisionen. Im deinem Wikipedia - Link steht aber doch, dass defekte Frames aufgrund der ungleichen Prüfsumme im Frame vom Treiber verworfen werden ? Heisst das jetzt, dass Endgerät fordert bei defekten Frames diese erneut beim Quellgerät an ? -------------------- Lordy....sorry, habe dein posting zu spät bemerkt Bearbeitet 13. Januar 2010 von Eleu Zitieren
axxis Geschrieben 13. Januar 2010 Geschrieben 13. Januar 2010 Kollisionen können durchaus in einer geswitchen Umgebung entstehen, nämlich wenn im Half-Duplex Modus operiert wird Heisst das jetzt, dass Endgerät fordert bei defekten Frames diese erneut beim Quellgerät an ? Nur wenn das Schicht 4 Protokoll TCP ist, denn TCP arbeitet Verbindungsorientiert und "zuverlässig" (im Sinne von "Ich will auf jeden Fall, das alle Frames ankommen"). Wenn aber UDP das operierende Protokoll ist, werden keine fehlerhaften Frames neu angefordert (Im Sinne von "Mir doch latte ob der seine Daten bekommt" ). Gruß Hauke Zitieren
Eleu Geschrieben 14. Januar 2010 Autor Geschrieben 14. Januar 2010 Vielen Dank für die Infos. Insofern die Endgeräte vollduplexfähig sind und TCP/IP verwendet wird, (Und das ist ja vielen Stellen so) sind solche Switche doch eigentlich ne gute Sache. Um wie viel Prozent sind solche Switche denn schneller, gegenüber den Switchen mit der gängigen "store and forward" Arbeitsweise ? Ist es so, dass man entweder einen Switch kaufen kann der "Cut-Through" kann und dafür kein "store and forward" und umgekehrt, oder gibt es Switche die wahlweise beides können ? Darf man diese Arbeitsweisen in einer Broadcastdomäne mischen ? Ich habe mal gelesen, dass die Arbeitsweise "Cut-Through" meistens nicht mehr verwendet wird. Ist das richtig ? Und wenn ja, warum denn ? Gruß Eleu Zitieren
axxis Geschrieben 14. Januar 2010 Geschrieben 14. Januar 2010 Moin, mit TCP/IP meinst du sicher das TCP/IP-Referenzmodell. Nichts desto trotz hast du bei bestimmten Diensten immernoch UDP als operierendes Layer4 Protokoll. Performance Store-and-Forward vs. Cut-Through kann ich leider nichts zu sagen. Warum letzteres nicht gern verwendet wird, kann man eigentlich gut nachvollziehen. Stell dir vor ein Frame muss um von PCA zu PCB zu kommen, 7 Switche passieren. Wenn dann erst PCB merkt "Oho, Frame ist aber kaputt", muss er eine erneute Anfrage über 7 Switche zurückschicken und PCA schickt dann erneut den Frame über die 7 Switche wieder an PCB. Wenn aber Switch1 schon merkt "Oho, Frame ist aber kaputt", sind bzw. können die "Wege" wesentlich kürzer (sein). Hoffe war verständlich:confused: Hauke Zitieren
ardcore Geschrieben 14. Januar 2010 Geschrieben 14. Januar 2010 Hoffe war verständlich:confused: Hauke Verständlich aber falsch. Wie sollte denn der Weg kürzer werden? Um wie viel Prozent sind solche Switche denn schneller, gegenüber den Switchen mit der gängigen "store and forward" Arbeitsweise ? Schneller war einmal. Bei heutigen Geräten gibt es zwischen Cut-Through und store and foreward keinen Unterschied mehr was die Processing-Delay angeht. Ist es so, dass man entweder einen Switch kaufen kann der "Cut-Through" kann und dafür kein "store and forward" und umgekehrt, oder gibt es Switche die wahlweise beides können ? Es gibt Geräte die unterstützen nur eine Switchingvariante, dann gibt es Geräte die unterstützen alle 3 Varianten. Darf man diese Arbeitsweisen in einer Broadcastdomäne mischen ? Ja. Ich habe mal gelesen, dass die Arbeitsweise "Cut-Through" meistens nicht mehr verwendet wird. Ist das richtig ? Und wenn ja, warum denn ? Siehe Erklärung oben. Wieso verwenden wenn nachteilig und nicht mehr schneller? Gruss, ardcore. Zitieren
axxis Geschrieben 14. Januar 2010 Geschrieben 14. Januar 2010 Anmerkung: Habe mich uneindeutig ausgedrückt. Ich wollte nicht sagen das der Weg zwischen PC und erstem Switch kürzer wird. Der Gesamtweg des zu übertragenden Frames war gemeint Gruß Hauke Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.