Frage zu Netzwerktopologien

[Aqualon]

Hi!

Ich habe eine Frage zu Netzwerktopologien, genauer gesagt zur Bus-Topologie bzw. Ring-Topologie.

Ein Bus-Netz ist nicht mehr verwendbar, wenn die Bus-Leitung unterbrochen wird, oder die Leitung nicht an beiden Enden terminiert ist.

Was passiert aber, wenn ein angeschlossener PC ausfällt? Ich hab bisher Infos von passiert gar nix, Netz teilt sich in 2 Hälften bis hin zum Netzkomplettausfall gefunden. Was davon stimmt denn nun?

Genauso habe ich beim Ring die Frage, was beim Ausfall einer Station bzw. beim Kabelbruch passiert. Fällt das Netzwerk danach komplett aus? Ich würde das ja als logisch enpfinden, aber auf http://www.elektronik-kompendium.de/sites/kom/0503281.htm steht "Wird der Ring unterbrochen entsteht ein lineares Netzwerk. Alle Stationen bleiben in Betrieb." Wie verhält sich das ganze also bei einem Ring?

Und kennt jemand eine gute Seite zu Netzwerktopologien, die das korrekt erklärt?

Aqua

[Endorphine]

Original geschrieben von Aqualon
Was passiert aber, wenn ein angeschlossener PC ausfällt? Ich hab bisher Infos von passiert gar nix, Netz teilt sich in 2 Hälften bis hin zum Netzkomplettausfall gefunden. Was davon stimmt denn nun? Bei 10BaseT/10Base2-Ethernet passiert gar nichts. Die entsprechende Station sendet/empfängt dann nur eben nichts mehr. ;) Wenn du den Bus dagegen auftrennst geht nichts mehr, da die Enden nicht mehr terminiert sind. Zumindest theoretisch. In der Praxis läuft es bei kurzen Segmentlängen auch manchmal ohne Terminator. Original geschrieben von Aqualon
Genauso habe ich beim Ring die Frage, was beim Ausfall einer Station bzw. beim Kabelbruch passiert. Das ist doch alles abhängig von der konkreten physikalischen Implementierung der Netztechnik. :) Wenn der Ring physikalisch als Bus aufgebaut ist, dieser aber auch ohne die Stationen elektrischen Durchgang hat läuft das Netz weiter. Bei Ringtopologie ist's dann natürlich noch die Frage, wie die Prozedur "hallo, hier ist 'ne neue Station, ich will ab sofort auch an eurem Ring teilnehmen" abläuft.

Du solltest dir die physikalischen Specs zum Netz deiner Wahl anschauen, das sollte deine Fragen von selbst beantworten.

p.s. Wozu brauchst du das? Die Ethernetspecs findest du beim IEEE (nach IEEE 802.3 googlen). Bei ATM, FDDI etc. ist wieder alles anders. Es hängt von der physikalischen Auslegung des Netzes ab.

[Aqualon]

Original geschrieben von Endorphine
p.s. Wozu brauchst du das?
Für eine Klausur in Rechnernetze nächste Woche. Unsere Aufschriebe sind leider alles andere als ausführlich und viele Fragen ergeben sich leider erst, wenn man es mal genauer betrachtet. Und im Detail kann man bei 3h pro Woche auch nicht auf jede Topologie eingehen.

Aber danke für deine Infos!

Aqua

[Gast]

Für sowas ist das cisco curiculum richtig gut. Und das schöne daran ist das man es kosten los von der cisco webseite bekommt. Ist aber ein paat mb groß ;)

[Aqualon]

Original geschrieben von Gast
Für sowas ist das cisco curiculum richtig gut. Und das schöne daran ist das man es kosten los von der cisco webseite bekommt. Ist aber ein paat mb groß ;)
Kannst du mir einen Link dazu geben? Ich habe nur eine Übersicht zu dem CCNA-Kurs (http://cisco.netacad.net/public/21centuryskills/parents/ccna.html) gefunden, aber keine Inhalte.

Aqua

[loewe]

Original geschrieben von Aqualon
1. Ein Bus-Netz ist nicht mehr verwendbar, wenn die Bus-Leitung unterbrochen wird, oder die Leitung nicht an beiden Enden terminiert ist.

Was passiert aber, wenn ein angeschlossener PC ausfällt? Ich hab bisher Infos von passiert gar nix, Netz teilt sich in 2 Hälften bis hin zum Netzkomplettausfall gefunden. Was davon stimmt denn nun?

2. Genauso habe ich beim Ring die Frage, was beim Ausfall einer Station bzw. beim Kabelbruch passiert. Fällt das Netzwerk danach komplett aus? Ich würde das ja als logisch enpfinden, aber auf http://www.elektronik-kompendium.de/sites/kom/0503281.htm steht "Wird der Ring unterbrochen entsteht ein lineares Netzwerk. Alle Stationen bleiben in Betrieb." Wie verhält sich das ganze also bei einem Ring?

3. Und kennt jemand eine gute Seite zu Netzwerktopologien, die das korrekt erklärt?

Aqua


zu 3.
http://www.netzmafia.de/skripten/netze/index.html

Ist auch bei anderen Fragen durchaus zu empfehlen.

zu 1. Wenn nur der PC ausfällt läuft der Bus problemlos weiter solange der Ausfall nicht durch Defekt des Kabels hervorgerufen wird.

zu 2.l
Bei einem echten Token Ring ist bei Ausfall eines Rechners feierabend, weiteres bei Netzmafia.

[Aqualon]

Original geschrieben von loewe
zu 3.
http://www.netzmafia.de/skripten/netze/index.html
Danke für den Link, ist eine echt interessante Seite!

Aqua

[Xmas]

Original geschrieben von Gast
Für sowas ist das cisco curiculum richtig gut. Und das schöne daran ist das man es kosten los von der cisco webseite bekommt. Ist aber ein paat mb groß ;)
An das CCNA-Curriculum sollte man ohne Login eigentlich nicht rankommen, und das weiterverbreiten ist nicht erlaubt.

[mrdigital]

i.d.R. werden aktuelle Netze physisch als Stern ausgeführt, da diese Topologie die grösste Ausfallsicherheit gibt, logisch kann aber eine andere Struktur zu Grunde liegen (Ethernet ist ein Bus bzw ein Shared Medium, d.h. jede Station kann alle anderen direkt erreichen, Token Ring ist ein logischer Ring). Die Ringstruktur hat einige Vorteile, vor allem wenn man ein Netz hat, das unter hohen Lasten arbeiten soll (hier ist Ethernet so ziemlich das schlechteste Netz), da das Latenzverhalten von Ringen deterministisch ist. Nachteil am Ring ist der höhere Initialisierungsaufwand, bzw. beim Ausfall einer Station wird eine Reinitialisierung fällig.

[Kinman]

Die störungen die ohne Terminierung auftreten sind reflektionnen.
Die logischen Topologien bei Ethernet ist Broadcast bzw. Token passing.

Und am ausfallsichersten sind Meshes und nicht Stars ;)

mfg Kinman

[peecee]

Original geschrieben von Kinman
Die logischen Topologien bei Ethernet ist Broadcast bzw. Token passing.


Die logische Topologie bei Ethernet ist ein Bus, Token Passing ist ein Zugriffsverfahren und ein Broadcast ist ein Paket an alle Stationen im Segment.

[Aqualon]

Original geschrieben von Kinman
Und am ausfallsichersten sind Meshes und nicht Stars ;)
Wenn man das gesamte Netz betrachtet hast du Recht. Wenn mich nur die Anbindung meines Rechners interessiert, ist es egal, ob das Gesamt-Netzwerk als Masche oder Stern aufgebaut ist.

Aqua

[Kinman]

Original geschrieben von peecee
Die logische Topologie bei Ethernet ist ein Bus, Token Passing ist ein Zugriffsverfahren und ein Broadcast ist ein Paket an alle Stationen im Segment.

und was ist der unterschied bei bus zu broadcast?
bei bus sendet jeder an jeden, bei broadcast auch. Das andere Netzwerkdinge auch Broadcas heißen ist was anderes ;)
Nur switches bei anderen phys. Topologien ändern das etwas ;)
Bei token passing kann ich das jetz so nicht sagen. Wir habens nur so gelernt und nix weiteres dazu aufgeschriebn :(

mfg Kinman

[mrdigital]

ein Broadcast ist ein Signal (logischer Art), das über einen Bus (physische Realisierung) zu den Stationen gelangt. Dabei ist nicht festgelegt, ob das über ein Shared Medium (Ethernet) oder ein Token Ring oder was auch immer für ein Medium geschieht. IP ist ein guts Beispiel, man kann ein Broadcast auf IP Ebene durchführen, dabei ist es IP aber ziemlich egal, wie das Signal zu den Stationen gelangt (Ethernet, ISDN, DSL, oder GSM z.B.)

[Kinman]

ok, muss ich mal unseren lehrer beibringen ;)
thx, mfg Kinman

[Crushinator]

Original geschrieben von Kinman
und was ist der unterschied bei bus zu broadcast? Bus heißt in diesem Falle, daß alle Teilnehmer logisch miteinander verbunden sind, auf einander Rücksicht nehmen (Stichwort Kollision) und sich die verfügbare Bandbreite teilen müssen. Broadcasts dagegen beschreiben nur Topologie-unabhängige Datenpakete, die an alle Teilnehmer eines Netzes adressiert sind.

/edit: mrdigital war schneller.

[Xmas]

Es wird eigentlich auch mal Zeit, das "Ethernet ist ein Bus" mal zu Grabe zu tragen. Wer nimmt heutzutage schon noch Half-Duplex? ;)

[mrdigital]

wie meinste das Xmas? Ethernet ist nunmal ein Bus, und man hat ja schon alle möglichen Register gezogen, um mehr als mit nem Koax-Kabel machen zu können, mittlerweile ähnelt ein Ethernet ja auch nicht mehr nem Bus so sehr, aber von der logischen Struktur des Buses wird man nicht wegkommen können, weil wenn, dann wär es kein Ethernet mehr ;) ATM hat sich ja auf dem Desktop nie durchsetzen können und Firewire hat leider zu kurze Reichweiten, und Ethernet ist sooooo billig, dass man lieber an der Übertragungsrate schraubt und dabei auch eine sinkende Effizienz in kauf nimmt, alleine wegen der vorhandenen Verkabelungen...

[Xmas]

Original geschrieben von mrdigital
wie meinste das Xmas? Ethernet ist nunmal ein Bus, und man hat ja schon alle möglichen Register gezogen, um mehr als mit nem Koax-Kabel machen zu können, mittlerweile ähnelt ein Ethernet ja auch nicht mehr nem Bus so sehr, aber von der logischen Struktur des Buses wird man nicht wegkommen können, weil wenn, dann wär es kein Ethernet mehr ;) ATM hat sich ja auf dem Desktop nie durchsetzen können und Firewire hat leider zu kurze Reichweiten, und Ethernet ist sooooo billig, dass man lieber an der Übertragungsrate schraubt und dabei auch eine sinkende Effizienz in kauf nimmt, alleine wegen der vorhandenen Verkabelungen...
IEEE 802.3 definiert zwar hauptsächlich CSMA/CD, aber unter den Begriff Ethernet wird auch der Full-Duplex-Betrieb gezählt. Und der ist Punkt-zu-Punkt, kein Bus. Weswegen ein voll geswitchtes Netz im Full-Duplex-Betrieb topo-logisch (;)) ein (erweiterter) Stern ist, kein Bus.

[mrdigital]

ja das war mir schon klar soweit, ich frag deshalb, weil du ethernet loswerden willst und was du dir als Alternative vorstellst.

[Xmas]

Original geschrieben von mrdigital
ja das war mir schon klar soweit, ich frag deshalb, weil du ethernet loswerden willst und was du dir als Alternative vorstellst.
Will ich nicht. Ich will nur die Verwendung von Ethernet als Bus loswerden ;)

[mrdigital]

naja aber das wird nie geben, nicht solange man das abwärtskompatibel halten will, und CSMA/CD ist halt ein doofes Zugriffsverfahren für einen HiSpeed System... Du musst nur viele Stationen haben (die Broadcasten dann auch munter vor sich hin) und da sind sie, die geliebten Kollisionen und dann ist deine Übertragungsrate hin... wenn die mit dem 10GBit Ethernet kommen, dann wird das IMHO nichts bringen, denn man wird bestenfalls noch 30% Netto-Übertragungsrate haben. Man muss wirklich mal das Zugriffsverfahren ändern, ein Ring wäre gut, vor allem wenn man QoS realisieren will und das wird ja langsam zum Thema.

[peecee]

Ich glaube wer sich 10GBit oder 1GBit Ethernet leisten kann hat auch das Geld sich Switches zu installieren, dann hast du wie oben schon von Xmas gesagt lauter Punkt zu Punkt Verbindungen und Kollisionen gibts nicht mehr.

Soweit ich weiss wir Token Passing ganz gerne verwendet wenn das Netz echtzeitfähig sein soll, IMHO bei einem normalen LAN nicht nötig.

[Gast]

Original geschrieben von Xmas
An das CCNA-Curriculum sollte man ohne Login eigentlich nicht rankommen, und das weiterverbreiten ist nicht erlaubt.

Hmm hatte es über die schule bekommen. Und da wurde es halt so verbreitet.

Werde mal schauen ob mein accout noch geht und mal den link suchen.

[Gast]

Hmm was mir zum weiterverbreiten einfällt.

Bis letzes jahr gab es das auf der webseite von dennen kostenlos. Aber nachdem das auch andere Firmen genutzt haben um zu schulen haben sie es in den geschützen berreich verlegt.

Leider bin ich letztes jahr fertig mit der schule geworden und habe daher nur die alte version 2.xx.

[Gast]

IBM hat das erste Token Ring-Netz in den 70er Jahren entwickelt. Token Ring ist nach wie vor die bevorzugte LAN-Technologie von IBM und steht bei der LAN-Implementierung an zweiter Stelle hinter Ethernet (IEEE 802.3). Die IEEE 802.5-Spezifikation für Token Ring ist nahezu identisch mit dem IBM Token Ring-Netz und vollständig kompatibel. Die IEEE 802.5-Spezifikation wurde in Anlehnung an den Token Ring von IBM entwickelt und folgt auch dessen weiterer Entwicklung. Die Bezeichnung Token Ring bezieht sich sowohl auf den IBM Token Ring als auch auf die IEEE 802.5-Spezifikation. Im Diagramm in der Hauptgrafik sind die Gemeinsamkeiten und Unterschiede der beiden Standards dargestellt.

Token
Token haben eine Länge von 3 Byte und bestehen aus einer Startkennung, einem Zugriffssteuerungs-Byte und einer Endekennung. Über die Startkennung werden die einzelnen Stationen über die Ankunft eines Tokens bzw. Daten-/Befehls-Frame informiert. In diesem Feld sind auch Signale enthalten, die das Byte vom Rest des Frames unterscheiden. Diese folgen nicht dem Kodierungsschema, das im übrigen Frame verwendet wird.

Zugriffssteuerungs-Byte
Das Zugriffssteuerungs-Byte enthält ein Prioritäts- und ein Reservierungs-Feld sowie ein Token- und ein Monitor-Bit. Das Token-Bit unterscheidet ein Token vom Daten-/Befehls-Frame; mit dem Monitor-Bit lässt sich feststellen, ob ein Frame ständig im Ring kreist. Die Endekennung gibt das Ende des Tokens bzw. des Daten-/Befehls-Frames an. Es enthält Bits, die einen beschädigten Frame sowie den letzten Frame in einer logischen Folge identifizieren.

Daten-/Befehls-Frames
Daten-/Befehls-Frames weisen je nach Länge des Informationsfelds unterschiedliche Größen auf. Daten-Frames enthalten Informationen für Protokolle höherer Schichten. Befehls-Frames enthalten Steuerungsinformationen und verfügen über keinerlei Daten für Protokolle höherer Schichten.

In Daten-/Befehls-Frames folgt ein Frame-Steuerbyte auf das Zugriffssteuerungs-Byte. Das Frame-Steuerbyte gibt an, ob der Frame Daten oder Steuerungsinformationen enthält. In Steuer-Frames legt dieses Byte die Art von Steuerungsinformationen fest.

Auf das Frame-Steuerbyte folgen zwei Adressfelder, die die Ziel- und die Sendestationen angeben. Wie bei IEEE 802.5 haben ihre Adressen eine Länge von 6 Byte. Das Datenfeld folgt auf das Adressfeld. Die Länge dieses Feldes wird in 4 Mbit/s Token Ringen auf maximal 4501 Bytes und in 16 Mbit/s Token Ringen auf 17997 Bytes begrenzt..

Auf das Datenfeld folgt das Feld mit der Rahmenprüfsumme (Frame Check Sequence, FCS). Die sendende Station füllt dieses Feld mit einem Wert, der anhand des Frame-Inhalts berechnet wird. Die Zielstation überprüft anhand der CRC-Prüfzeichenfolge, ob der Frame bei der Übertragung beschädigt wurde. Wenn der Frame beschädigt wurde, wird er verworfen. Wie beim Token bildet die Endekennung auch den Abschluss des Daten-/Befehls-Frames.

Token-Zugriff
Token Ring und IEEE 802.5 sind die Hauptbeispiele für Netze mit Token-Zugriff. Netze mit Token-Zugriff lassen einen kleinen Frame, der als Token bezeichnet wird, im Netz kreisen. Der Besitz des Tokens gewährt das Recht zur Datenübertragung. Wenn ein Knoten, der das Token erhält, keine Daten zu übermitteln hat, gibt er das Token an die nächste Station weiter. Jede Station kann das Token für eine bestimmte Höchstdauer behalten. Diese hängt von der jeweils implementierten Technologie ab.

Wenn eine Station, die Daten übertragen möchte, Zugriff auf das Token erhält, nimmt sie es in Besitz und ändert ein Bit des Tokens. Das Token wird zur Frame-Startsequenz. Als nächstes hängt die Station die zu übertragenden Informationen an das Token an und sendet diese Daten an die nächste Station auf dem Ring. Während der Informations-Frame auf dem Ring übermittelt wird, befindet sich kein freies Token im Ring, es sei denn, der Ring unterstützt frühzeitige Token-Freigabe (engl. Early Token Release). Andere Stationen im Ring können zu diesem Zeitpunkt keine Übertragungen vornehmen. Sie müssen warten, bis das Token wieder frei wird. Bei Token Ring-Netzen kommt es zu keinen Kollisionen. Wenn die frühzeitige Freigabe des Tokens unterstützt wird, kann ein neues Token an den Ring übergeben werden, sobald die Frame-Übertragung abgeschlossen wurde.

Der Informations-Frame kreist so lange auf dem Ring, bis er die gewünschte Zielstation erreicht. Diese kopiert dann die Informationen, um sie weiter zu verarbeiten. Der Informations-Frame wird auf dem Ring solange von Station zu Station übertragen, bis er die sendende Station erreicht und vom Ring genommen wird. Die sendende Station kann überprüfen, ob die Zielstation den Frame erhalten und die Informationen kopiert hat.

Im Gegensatz zu Netzen mit CSMA/CD-Verfahren, wie beispielsweise Ethernet, sind Netze mit Token-Zugriff deterministisch. Das heißt, man kann die maximale Zeit berechnen, die jede Endstation warten muss, bevor sie eine Übertragung vornehmen kann. Aufgrund dieser Eigenschaft und weiterer Zuverlässigkeitsmerkmale eignen sich Token Ring-Netze ideal für Anwendungen, bei denen jegliche Verzögerungen berechenbar sein müssen und robuster Netzwerkbetrieb eine große Rolle spielt. Berechenbarer, robuster Netzwerkbetrieb ist beispielsweise in der Produktionsautomatisierung von großer Bedeutung.

Prioritätssystem
Token Ring-Netze arbeiten mit einem ausgeklügelten Prioritätssystem, das es bestimmten Stationen, die vom Benutzer festgelegt werden und hohe Priorität aufweisen, ermöglicht, häufiger auf das Netz zuzugreifen. Token Ring-Frames verfügen über zwei Felder, die die Priorität kontrollieren - das Prioritäts-Feld und das Reservierungs-Feld.

Nur Stationen mit einer Priorität, die mindestens dem im Token enthaltenen Prioritätswert entspricht, können das Token für sich in Anspruch nehmen. Sobald sie das Token in Besitz genommen und in einen Informations-Frame umgewandelt haben, können nur Stationen mit einem Prioritätswert, der höher ist als derjenige der übertragenden Station, das Token für den nächsten Netzwerkdurchlauf reservieren. Das Token, das als nächstes erzeugt wird, enthält die höhere Priorität der reservierenden Station. Stationen, die die Prioritätsstufe eines Tokens erhöhen, müssen das Token auf die vorherige Priorität zurücksetzen, sobald sie ihre Übertragung abgeschlossen haben.

Management-Verfahren
Token Ring-Netze setzen verschiedene Verfahren ein, um Netzwerkfehler zu ermitteln und zu umgehen. Ein Verfahren besteht darin, eine Station im Token Ring-Netz als aktiven Monitor zu wählen. Diese Station fungiert als zentrale Quelle für die Abstimmung mit anderen Ringstationen und führt eine Reihe von Verwaltungsaufgaben im Ring durch. Jede beliebige Station im Netz kann zum aktiven Monitor werden. Eine Funktion dieser Station besteht darin, ständig kreisende Frames vom Ring zu nehmen. Wenn ein sendendes Gerät ausfällt, kreist sein Frame möglicherweise weiterhin auf dem Ring und verhindert, dass andere Stationen ihre eigenen Frames übertragen können. Dadurch kann es zu einer Blockierung der Netzwerkübertragungen kommen. Der aktive Monitor kann diese Frames erkennen, sie aus dem Ring entfernen und ein neues Token erzeugen.

Die Sterntopologie des IBM Token Ring-Netzes erhöht auch die Zuverlässigkeit des gesamten Netzes. Aktive MSAUs (Multi-Station Access Units) können alle Informationen in einem Token Ring-Netz lesen und diese damit auf Probleme überprüfen und, falls erforderlich, einzelne Stationen aus dem Ring entfernen. Durch Beaconing, einem Verfahren zur Fehlerermittlung im Token Ring, werden Netzwerkfehler ermittelt und, falls möglich, behoben. Wenn von einer Station ein schwerwiegendes Netzwerkproblem (z. B. ein Kabelbruch) festgestellt wird, sendet sie einen Beacon-Frame. Der Beacon-Frame definiert eine Fehler-Domain. Eine Fehler-Domain umfasst die Station, die den Fehler meldet, ihren nächsten aktiven höhergelegenen Nachbar (NAUN) sowie allen dazwischen liegenden Komponenten. Der Beacon-Frame leitet einen Prozess mit der Bezeichnung automatische Rekonfiguration ein, bei dem Knoten in der Fehler-Domain automatisch Diagnoseverfahren durchführen. Dabei wird versucht, das Netz um die fehlerhaften Bereiche neu zu konfigurieren. Physikalisch gesehen können MSAUs dies durch elektrische Neukonfiguration bewirken.

Bei der Signalkodierung werden die Takt- und die Dateninformationen zu einem Signalstrom zusammengefasst, der über ein Medium übermittelt wird. Die Manchester-Kodierung kombiniert Daten- und Taktinformationen zu Bitsymbolen, die in zwei Hälften aufgeteilt sind. Dabei weist die zweite Hälfte immer die umgekehrte Polarität der ersten Hälfte auf. Beachten Sie, dass bei der Manchester-Kodierung die Null als Übergang von Hoch zu Niedrig und die Eins als Übergang von Niedrig zu Hoch in der Mitte des Bitintervals kodiert wird.. Da sowohl Nullen als auch Einsen zu einem Signalübergang führen, kann der Takt im Empfänger effektiv wiederhergestellt werden.

Die Token Ring-Netze mit 4 bzw. 16 Mbit/s arbeiten mit der Manchester-Differenzkodierung (einer Variante der Manchester-Kodierung). Token Ring verwendet die Differential-Manchesterkodierung, um Takt- und Datenbit-Informationen als Bitsymbole zu kodieren. Ein Bit von Eins wird durch keine Polaritätsänderung am Beginn der Bitzeit dargestellt, ein Bit von Null wird hingegen durch eine Polaritätsänderung am Beginn der Bitzeit angegeben.

IBM Token Ring-Netzwerkstationen (die oft STP und UTP als Medien verwenden) sind direkt an MSAUs angeschlossen und können zu einem einzigen großen Ring verbunden werden. Patch-Kabel verbinden MSAUs mit anderen, benachbarten MSAUs. Abzweigkabel verbinden MSAUs mit den Stationen. MSAUs enthalten Bypass-Relais (Umgehungsleitungen), so dass Stationen problemlos vom Ring entfernt werden können.

Mitte der 80er Jahre hatte der Einsatz von Hochgeschwindigkeits-Technik-Arbeitsstationen die bestehenden Ethernet- und Token Ring-Netze an ihre Grenzen gebracht. Die Ingenieure benötigten ein LAN, das ihre Arbeitsstationen und auch ihre neuen Anwendungen unterstützen konnte. Zur gleichen Zeit wuchs bei den Systemadministratoren die Sorge um die Zuverlässigkeit der Netze, da zunehmend unternehmenskritische Anwendungen auf den Hochgeschwindigkeitsnetzen implementiert wurden.

Um dieses Problem zu lösen, entwickelte der ANSI X3T9.5-Normungsausschuss den Fiber Distributed Data Interface (FDDI)-Standard. Nach der Ausarbeitung der Spezifikationen übergab das ANSI den FDDI-Standard an die Internationale Normenorganisation (ISO), die anschließend eine internationale Version des FDDI-Standards entwickelte, die vollständig kompatibel mit der ANSI-Standardversion ist.

Auch wenn FDDI in der heutigen Zeit nicht so häufig implementiert wird wie Ethernet oder Token Ring, findet FDDI ein breites Einsatzgebiet, das immer weiter anwächst, je mehr seine Kosten sinken. FDDI wird häufig als Backbone-Technologie sowie für die Verbindung von Hochgeschwindigkeits-Computern mit einem LAN eingesetzt.

FDDI enthält vier Spezifikationen:
Media Access Control (MAC) - legt den Zugriff auf das Medium fest, einschließlich
Frame-Format
Token-Handhabung
Adressierung
Algorithmus für die Berechnung einer CRC-Prüfsumme und Fehlerbehebungsmechanismen


Bitübertragungsschicht-Protokoll (PHY) - legt die Kodier- und Dekodierverfahren für die Daten fest, einschließlich
Taktanforderungen
Frame-Erstellung
anderen Funktionen


Übertragungsschicht-Medium (PMD) - legt die Eigenschaften des Übertragungsmediums fest, einschließlich
Glasfaserverbindung
Leistungsniveaus
Bitfehlerraten
optischen Komponenten
Anschlüssen


Station Management (SMT) - legt die Konfiguration der FDDI-Station fest, einschließlich
Ringkonfiguration
Ringsteuerfunktionen
Einfügen und Entfernen von Stationen
Initialisierung
Fehlerermittlung und -behebung
Zeitplanung
Zusammenstellen von statistischen Informationen

[mrdigital]

bevor ihr solche Artikel Postet, setzt doch lieber einen Link, statt Cut´n Paste ;)

[mrdigital]

Original geschrieben von peecee
Ich glaube wer sich 10GBit oder 1GBit Ethernet leisten kann hat auch das Geld sich Switches zu installieren, dann hast du wie oben schon von Xmas gesagt lauter Punkt zu Punkt Verbindungen und Kollisionen gibts nicht mehr.

Soweit ich weiss wir Token Passing ganz gerne verwendet wenn das Netz echtzeitfähig sein soll, IMHO bei einem normalen LAN nicht nötig.

Es gibt natürlich auch noch Kollisionen, auch in geswitchten Netzen, es gibt keine Kollision zwischen Switch und Station, aber wenn zwei Stationen gleichzeitig zu einer dritten senden, dann muss der Switch diesen Konflikt lösen, wenn er gut ist, dann kann er das (bei zwei gleichzeitigen Sendungen kommt kein Switch ins schwitzen aber nimm mal ne grosse Installation, da kann das eng werden). Noch problematischer sind Broadcasts. Ethernet ist unter hoher Last eines der schlechtesten Netze, da ändert kein Switch was dran, man sieht diesen Effekt auch jetzt schon, denn ein 1 GBit Ethernet ist eben nicht 10 mal schneller als ein 100MBit Ethernet (Klar wenn du nur zwei Stationen hast, dann hast du recht wenig Kollisionen, also kann man recht nah an das theoretische Übertragungsmaximum gelanen). Was Ethernet nur mit grossen Krämpfen kann, ist QoS, wodurch ein selbst Telefoniedienst über Ethernet schon problematisch wird, weil du keine zugesicherte Bandbreite hast (es geht, aber nur, wenn man einige Vorkehrungen trifft und die sind in grossen Installationen aufwendig, d.h. man muss sich Cisco Zeug kaufen, und die machen ein QoS im Switch)

[x-dragon]

Original geschrieben von peecee
Ich glaube wer sich 10GBit oder 1GBit Ethernet leisten kann hat auch das Geld sich Switches zu installieren, ... Zumindest 1 GBit ist auch nicht mehr so teuer, bei meinem Händler gibts solche Netzwerkkarten schon ab ca. 15 €, bei einem 5er-Switch sind wir aber schon bei ca. 80 € und aufwärts.

[edit]
Gibts eigentlich noch richtige 1 GBit-Hubs? Bei www.reichelt.de gibts z.B. nur Switches ...

[mrdigital]

nö 1Gbit gibt es nur geswitcht...zumindest hab ich noch nie einen 1GBit Hub gesehen

[Haarmann]

Gbit über Kupfer ist zwingend switched. Das geht nicht anders, weil nur noch Point to Point möglich ist.

Das System ist ja, dass man 4 Adernpaare nutzt in beide Richtungen. Um das Signal des Gegenüber zu sehen subtrahiert man das eigene Signal und sieht dann das andere. Das geht nur bei 2 Stationen - womit Hubs nicht mehr gehen. Collisions gibts eigentlich nimmer, denn der Switch sollte dem vorbeugen - Betonung bei sollte.

[DrumDub]

Original geschrieben von Haarmann
Gbit über Kupfer ist zwingend switched. Das geht nicht anders, weil nur noch Point to Point möglich ist.


mist. das wollt ich auch grad schreiben... ;D

[mrdigital]

Nochmal, solange man Ethernet einsetzt gibt es Kollisionen, Switch hin Switch her, diese Kollision entsteht nicht auf der Strecke Switch - Rechner sondern im Switch, aber die Auswirkungen sind die selben... Wenn man effektiv mehr Daten übertragen will, dann müssen andere Übertragunstechniken her, FDDI, ATM, FC, FireWire, whatever, nur an der "Taktschraube" drehen ist ne Sackgasse, da Ethernet nunmal als Shared Medium konzipiert ist, ist das so tief in dieser Technik drin, das man die Nachteile, die dabei entstehen, nicht ausgleichen kann.

[Legolas]

Original geschrieben von mrdigital
Es gibt natürlich auch noch Kollisionen, auch in geswitchten Netzen, es gibt keine Kollision zwischen Switch und Station, aber wenn zwei Stationen gleichzeitig zu einer dritten senden, dann muss der Switch diesen Konflikt lösen, wenn er gut ist, dann kann er das (bei zwei gleichzeitigen Sendungen kommt kein Switch ins schwitzen aber nimm mal ne grosse Installation, da kann das eng werden).

Wenn ein Switch mehrere Pakete von verschiedenen Sendern für einen Empfänger erhält, dann kann er doch maximal eines gleichzeitig zum Empfänger weiterleiten, der Rest muss doch erstmal in die Warteschlage. So käme es dann nicht zu Kollisionen, aber eventuell zu Packetloss, wenn zuviele Pakete zu schnell reinkommen und der Puffer überläuft.

[mrdigital]

und was ist die Auswirkung von nem verlohrenen Packet? Die Sation muss nochmal senden. Was ist die Auswirkung einer Kollision? Die Staion muss nochmal senden.
Das ein Switch das ein stückweit abfangen kann habe ich schon früher geschrieben, wenn nun aber zwei Stationen mit 1Gbit senden und das eine 3. Staion empfangen soll (Zwei Clients ein Server), was wird dann passieren? Die Übertragungsrate geht (auf der Clientseite) um mindestens 50% runter, in der Realität ist das viel schlimmer, es bleiben pro Client nur noch 30% der Bruttorate übrig. Wenn du dich in einem grösseren Netz bewegst, tritt dieser Effekt sehr häufig auf, auch wenn man eigentlich genug Bruttorate hat. (Ich habe den Server mit 2* 1Gbit an den Switch angebunden um den Efekt ein wenig abzumildern, aber auch das hilft nur begrenzt). Es ist halt leider so, dass Ethernet nicht für schnelle Netze geeignet ist, aber es ist halt gleichzeitig auch so, das Ethernet die einzige einigermassen schnelle Übertragungstechnik ist, die bezahlbar ist

[x-dragon]

Ja dem kann wohl so zustimmen :).

Original geschrieben von Haarmann
... Das System ist ja, dass man 4 Adernpaare nutzt in beide Richtungen. ... Ahja stimmt ja, daran hatte gar nicht gedacht.

[Xmas]

Original geschrieben von mrdigital
und was ist die Auswirkung von nem verlohrenen Packet? Die Sation muss nochmal senden. Was ist die Auswirkung einer Kollision? Die Staion muss nochmal senden.
Das ein Switch das ein stückweit abfangen kann habe ich schon früher geschrieben, wenn nun aber zwei Stationen mit 1Gbit senden und das eine 3. Staion empfangen soll (Zwei Clients ein Server), was wird dann passieren? Die Übertragungsrate geht (auf der Clientseite) um mindestens 50% runter, in der Realität ist das viel schlimmer, es bleiben pro Client nur noch 30% der Bruttorate übrig. Wenn du dich in einem grösseren Netz bewegst, tritt dieser Effekt sehr häufig auf, auch wenn man eigentlich genug Bruttorate hat. (Ich habe den Server mit 2* 1Gbit an den Switch angebunden um den Efekt ein wenig abzumildern, aber auch das hilft nur begrenzt). Es ist halt leider so, dass Ethernet nicht für schnelle Netze geeignet ist, aber es ist halt gleichzeitig auch so, das Ethernet die einzige einigermassen schnelle Übertragungstechnik ist, die bezahlbar ist
Das Problem ist doch nicht Ethernet-spezifisch, sondern das hast du bei jeder verzweigten symmetrischen Struktur (außer nem vollständigen Mesh). Wenn eine bestimmte Teilstrecke nur eine bestimmte Bandbreite zulässt, müssen alle "Zulieferer" sich diese Teilen. Dagegen hilft prinzipiell nur eines: mehr (oder breitere) Leitungen zu den Hosts mit viel Traffic.
Um dann immer noch die beste Auslastung zu haben, muss das Netz z.B. Wartesignale bei annähernd vollen Puffern unterstützen.



Ach ja, es gibt auch Gbit Ethernet mit CSMA/CD... will nur scheinbar keiner ;)

[mrdigital]

Das Problem an sich ist nicht Ethernetspezifisch, aber andere Netzwerktypen können mit sowas besser umgehen, weil man eben von vorne herein sich über sowas Gedanken gemacht hat und es nicht erst im nachhinein reinfummelt. Ein Tokenring (ich meine jetzt nicht DAS Tokenring, sondern Tokenverfahren im allgemeinen) sind was Hochlast angeht wesentlich robuster und lassen sich nahe an die theoretische Bruttotransferrate auslasten. QoS ist mit FW oder selbst mit USB kein Problem, weil man sich eine bestimmte Bandbreite zusichern lassen kann, mit Ethernet ist das ein Problem...

[Legolas]

Also wenn unser Prof (und die Begleitliteratur) heute nicht gelogen hat, dann vermeiden Switches Kollisionen vollständig. Die Aufteilung der Bandbreite bei mehreren Sendern zu einem Empfänger geschieht ja nicht auf der Ebene der Switches, sondern auf TCP-Ebene (afaik Layer 4) durch die Flusskontrolle.

[mrdigital]

wenn du im Switch einen Puffer vollaufen lässt, dann geht ein Packet verlohren. Ob das Packet IP war und ob in diesem IP Packet dann noch ein TCP gesteckt hat ist dem Switch wurscht, das Packet ist weg. Nun kann der Switch der sendenden Station ein Jam signalisieren und die kann sich überlegen, wie sie darauf reagieren soll, aber da verfolgen verschiedene Switches verschiedene Strategien, manch ein Switch macht einfach nichts, wenn er ein Packet verliert. Was du meinst, mit der TCP Flusskontrolle ist die Window-Size, die wird am Anfang einer Übertragung immer klein gewählt und dann im Verlauf der Übertragung suksesive hochgesetzt, sobald aber ein Packet verlohren geht (d.h. die Gegenstelle hat nicht mit ACK geantwortet) wird die Window Size sofort zurückgesetzt und das Spiel geht von vorn los. Das Phänomen hier ist keine Kollision, im Sinne von zwei Stationen wollen gleichueitig auf das elektrische Medium zugreifen, aber die Konsequenzen sind die selben. Die Bandbreitenaufteilung geschieht nicht auf TCP Ebene, weil TCP absolut keine Ahnung vom Transportmedium hat und auch nicht haben sollte, zumal ich über das selbe Ethernet nicht nur IP (und TCP) transportieren kann sonder auch beliebige andere Protokolle und die sich sicherlich überhaupt nicht um TCP Flusskontrolle scheren. Dein Prof hat schon recht, wenn man die Strecke Station - Switch betrachtet, hier treten wirklich keine Kollisionen mehr auf, das Problem ist in den Switch gewandert. Zur Bandbreitenaufteilung: Ethernet kennt keine (ausser man hat einen schlauen Switch, der Layer 3 switching beherrscht und für den Preis eines Kleinwagens zu haben ist, deshalb ist Cisco so reich ;)) und genau deshalb ist Ethernet auch schlecht für schnelle Netze mit hoher Last.

[peecee]

@mrdigital

wenn du Interesse hast les dir mal das Kapitel (http://www.netzmafia.de/skripten/netze/netz7.html#7.6) über Switches durch.

Zusammenfassung:
Eine Switch arbeitet intern mit einer viel höheren Bandbreite, darum kann er mehrere Ports gleichzeitig bedienen ohne Pakete zu verlieren.
Wenn an einem Switch Port nur eine Station angeschlossen ist gibts keine Kollisionen mehr und jede Station hat die volle Bandbreite zur Verfügung.

mfg

[mrdigital]

peecee, das ein Switch intern eine schnellere Backplane hat ist mir schon klar, aber wenn du dir meine Postings durchgelesen hättest, dann hättest du auch das Problem erkannt, das Problem ist nicht eine zu langsame Backplane, das Problem ist auch nicht, das eine (schnelle) Backplane einen einzelnen Port nicht schneller machen kann (ich wiederhole mich, 2 Clients á 1Gbit senden an 1 Server, der ja auch nur 1 Gibt hat, du erkennst das Problem?), das Problem ist, das Ethernet keine Mechanismen zu Lastaufteilung und der Medienzuteilung kennt, die man bei hoher Geschwindigkeit und hoher Last dringend brauch, um halbwegs vernünftige Nettotransferraten zu erzielen. Das es keine Kollisionen zwischen Station und Switch auftreten habe ich mehrfach geschrieben...

[Crushinator]

@peecee

Aber das, was Du NICHT erzählst ist viel interessanter, nämlich was passiert, wenn mehrere Stationen an einem Switch mit ihrer vollen Bandbreite gleichzeitig zu einem bestimmten Port senden? Ja, genau, es gibt "Stau" bzw. Kollisionen, denn der Switch kann soviel interne Bandbreite haben, wie er will, er wird die Daten am Zielport nicht los. Daraufhin gehen Pakete verloren und die sendenden Stationen senden erneut, weil sie entweder von der "Kollision" erfahren oder durch fehlende ACKs dazu genötigt werden.

Diese "Kollisionen" verursachen auch in einem "switched" Netz zu hohe Latenzzeiten, (und zwar nicht immer nur bei den an der Kollision beteiligten Stationen) die entweder durch voriges Anfragen der gewünschten Bandbreite zum Ziel (fällt unter QoS) oder durch vorhersehbare Maximallaufzeit aufgrund der festgelegten Datenübermittlungsart (siehe Token Passing) vermeidbar bzw. nicht so unberechenbar wären.

Um mal ein Beispiel aus der Praxis zu nennen: Nur weil zu unserer neuen Telefonanlage eine Software (auf TCP-Basis mit der Anlage kommuniziernd) auf dem PC installiert werden kann, die Einen bei diversen Dingen in der Bedienung - u.A. bei der Nummernwahl - unterstützt, und nur bei einer lächerlich kleinen Anzahl von 4 Leuten aus meinem Segment installiert ist, muß ich damit leben, daß auch ich - als notorischer Nichtnutzer von so einem "Teufelszeugs" - seitdem gerade mal 60% der vorigen "Bandbreite" zu unseren Servern habe. Der Grund ist übrigens nicht etwa der, daß unser Server oder sein "Link" überbelastet sei, sondern viel mehr daß die permanent anliegende Datenübertragung zwischen TK-Anlage und den 4 PCs - mit eigentlich lächerlich kleinen Datenmengen - jene PCs in der sonstigen Kommunikation (zu File- App- oder Druck-Servern) teilweise so stört, daß sie selbst oder die mit ihnen kommuniziernden Stationen oft Pakete erneut senden müssen, was wiederum u.A. die Laufzeit meiner durch dieselbe Abteilungsswitch-zu-Hauptswitch Verbindung laufenden Pakete übermäßig erhöht.

[GloomY]

Original geschrieben von mrdigital
und was ist die Auswirkung von nem verlohrenen Packet? Die Sation muss nochmal senden. Was ist die Auswirkung einer Kollision? Die Staion muss nochmal senden.
Das ein Switch das ein stückweit abfangen kann habe ich schon früher geschrieben, wenn nun aber zwei Stationen mit 1Gbit senden und das eine 3. Staion empfangen soll (Zwei Clients ein Server), was wird dann passieren? Die Übertragungsrate geht (auf der Clientseite) um mindestens 50% runter, in der Realität ist das viel schlimmer, es bleiben pro Client nur noch 30% der Bruttorate übrig. Wenn du dich in einem grösseren Netz bewegst, tritt dieser Effekt sehr häufig auf, auch wenn man eigentlich genug Bruttorate hat.
Original geschrieben von mrdigital
[...]Was du meinst, mit der TCP Flusskontrolle ist die Window-Size, die wird am Anfang einer Übertragung immer klein gewählt und dann im Verlauf der Übertragung suksesive hochgesetzt, sobald aber ein Packet verlohren geht (d.h. die Gegenstelle hat nicht mit ACK geantwortet) wird die Window Size sofort zurückgesetzt und das Spiel geht von vorn los.Findest du den Mechanismus mit der Windows-Size nicht geeignet, um die Datenraten der Sender zu beinflussen?

In deinem obigen Beispiel würden beide Clients nach kurzer Zeit ihre Windows-Size und damit ihre zu versendenden Daten so reduziert haben, dass kaum noch Pakete verloren gehen. Ich kann mir nicht vorstellen, daß deine genannten 30% Durchsatz sich auf lange Dauer einpendeln würden.

Sicherlich ist diese Lösung nicht perfekt, weil die Regulierung der Datenraten nicht direkt durch das Übertragungsmedium (Ethernet) sondern durch ein Kontrollprotokoll (TCP) geregelt wird, aber dadurch ist Ethernet auch ziemlich einfach zu realisieren und daher eben auch billig. Alle anderen Übertragungsarten, die eine mediumbasierte Kontrolle besitzen, sind zwar effektiver (wieviel?) jedoch zwangsläufig damit auch teurer. Es ist IMHO eine Frage der Preis-Leistung, die man hier abwägen muß. Und wenn ich mir die Preise für Gigabit Ethernet so anschaue, dann muss ich sagen, dass dieses meiner Meinung nach sehr gut dasteht. :)

Übrigends kommt es beim Netzwerk nicht nur auf den Durchsatz an. Die Latenz, also die Dauer einer Übertragung, ist gerade bei Parallelrechnern nicht unbedeutend. Und hier ist die von dir kritisierte Erhöhung der Übertragungsfrequenz das einzig richtige Mittel.

[mrdigital]

Versteh mich nicht falsch, ich bin kein Ethernet-Hasser, das Ethernet ist ein Kompromiss, aber wenn ich mir den Aufwand ansehe, der mit dem (ursprünlichen) Ethernet betrieben wird, um das heute noch verwenden zu können, dann muss man sich schon fragen, ob man nicht mehr davon hätte, wenn man mal auf eine "neue" Netztechnik setzten würde, die halt mehr an die heutigen Anforderungen angepasst ist. Das Ethernet billig ist, ist aber nur der schieren Masse zu verdanken, wenn ich mir so ansehe was man alles an Technik aufbringen muss (ein Gbit Switch ist schon ein ganz schönes Stück Technik, Karten, so sie denn ein bisschen besser sind, sind auch recht aufwendige Teile).
Das mit den Übertragungsraten hab ich selbst nachgemessen, das ist wirklich so, dass es auf ca. ein drittel runter geht, (Zwei Clients mit SMB, an einen Server), da bleiben pro Client 3-4 MB/s übrig, wenn es nur ein Client ist, dann ist es immerhin ~8MB/s (an Sonntagen auch ma 8,5;)) Sobald nur ein bisschen anderer Verkehr dazukommt, im Web surfen z.B. bröselt das weg. Zugegeben SMB ist ein lahmes Protokoll und ich hab das bei mir zuhause mit nem mässigen LevelOne Switch gemessen. Natürlich ist der Window Size Mechanismus geeignet, den Datenfluss zu regeln dafür ist er da, aber das ist erst auf TCP, alleine wenn ich mir die Zeit ansehe, die verstreicht, wenn ein Packet flöten ging, das tut doch weh, wenn ich ein 1GBit schnelles Netz habe. Die Window Size ist ja deswegen nötig, weil ich ja das darunterliegende Transportmedium nicht kenne, bzw es einen Mediumwechsel geben kann. Was deine Latzenzen angeht, für Parallelrechner ist Ethernet, mit verlaub, das mieseste wo gibt, weil man nichts vorhersehen kann. In der Regel sind die Latzenen kurz aber wenn was los ist, wird das schon anders. Klar für kürzere Latenzen muss ich an der Taktscharaube drehen (oder den Overhead verkleinern und der ist bei IP over Ethernet doch recht gross, wie gross ist ein Ethernetheader - 8Byte Pramble zm synchronisieren, 22 Bytes Ethernetheader , 20 Bytes IP Header, 20 Bytts TCP Header, endlich ein paar Daten und dann nochmal 4 Bytes Ethernet FCS und nun die Interframe Gap, da bin ich schon mal bei 74 Bytes + Gap um dann gerade mal 44Bytes Nutzdaten zu übertragen), aber dann kann mir Ethernet noch immer keine Zeiten garantieren und ich muss mir in den höheren Schichten wieder jede Menge Synchronisierung einbauen, auch nicht toll.
Das Killerargument für Ethernet ist die (in Firmen) bereits existierende Verkabelung, das wär einfach zu teuer da was zu änderen, und andererseits die enorme Verbreitung und die damit verbundenen niedrigen Preise. Wegen seiner hohen Qualität ist Ethernet sicher nicht so beliebt.

[Xmas]

Billig zu sein ist auch eine Qualität ;). Außerdem besticht (Gigabit) Ethernet eben durch die enorme Rohbandbreite. Selbst wenn man davon nur 20% nutzen kann, ist das immer noch mehr als ausreichend für die Einsatzzwecke vieler Firmen und erst recht für Privatnetzwerke. Dass die Latenzen wirklich entscheidend sind, ist eher die Ausnahme. Zum Thema Overhead, da sind andere Netzarchitekturen auch nicht so viel besser.

[mrdigital]

Ja das sehe ich doch genauso ;) Ethernet ist halt das Feld, Wald und Wiesennetz, aber für spezielle Anwendungen ist Ethernet nunmal nix...