Diskussion:Ethernet

aus Wikipedia, der freien Enzyklopädie

Unter "Verwandte Standards" ist auch das WLAN aufgelistet. Dort könnte doch ergänzt werden, dass wegen der Kompatibilität bei einer Verbindung zw. WLAN und einem kabelgebundenen Ethernet-Rechner kein Routing erforderlich ist, sondern nur Bridging. (War mir bis dato nicht so klar...) 24.07.2005 14:15

Inhaltsverzeichnis 1 10 Gigabit 2 CSMA/CD Verfahren 3 Javascript Stummel 4 Apple Talk 5 Sicherheit und Switches 6 802.x == 802.2 7 AUI und AAUI 8 Gesamtlänge Ethernet-Paket 9 Gigabit Ethernet 10 Ethernet Reichweite 11 Toter Weblink 12 Abkürzungen der Ethernet-Standards 13 Verständnisproblem 14 Keep-Alives 15 Bitübertragungsschicht (Punkt 2) 16 Stacked VLANs (QinQ) 17 ``bitgenaue Signalisierung des Übertragungsendes" 18 Keine Präambel bei Geschwindigkeit > 10 MBit? 19 Lesenswert-Kandidatur: Ethernet (Archivierung Abstimmung 31. Juli bis 7. August 2006) 20 Power over Ethernet

[Bearbeiten] 10 Gigabit

da ich gerade den sehr angennehmen Artikel lese möchte ich hier mal was zum 10 Gbit teil fragen:

in der einleitung steht etwas von ",.. sieben Glasfaser- und einen Kupfermedientyp,.."

ich sehe aber zwei "kabel" standarts ... [..]

1. 10GBase-CX4,
2. 10GBase-T,

habe ich da was falsch verstanden oder sind die zahlen falsch ... wenn da jemand mehr Ahnung hat als ich kann er das mal bitte ausbessern,

--mattes 23:07, 30. Jan 2006 (CET)

[Bearbeiten] CSMA/CD Verfahren

Ich finde dass es nicht CSMA/CD Algorithmus heissen sollte. Denn der Algorithmus ist eine Abfolge von Befehlsschritten, bzw. von Handlungen eines abgeschlossenen Systems / Maschine / Einheit. Insofern würde ich es eher Verfahren nennen, das ist gemeinhin die übliche Benennung...
Lawnmower 18:16, 18. Jan 2006 (CET)

[Bearbeiten] Javascript Stummel

Woher kommen alle diese Javascript Stummel im Artikel? (Stand 13:39, 24. Jan 2005 (CET))

---

Ich würde vorschlagen, den CSMA/CD-Teil komplett in den gleichnamigen Artikel (CSMA/CD) zu verlagern. Spricht was dagegen? Mwka 23:24, 24. Feb 2004 (CET)

Keine grundsätzlichen Einwände, aber lass' von der CSMA/CD-Geschichte noch soviel übrig, dass der Ethernet-Artikel nicht drunter leidet. Mein Vorschlag wäre, den Text von Das Schema ist verglichen mit Token Ring oder Master-kontrollierten Netzwerken relativ simpel. bis zum Ende des zweiten Absatzes nach der 6-Punkte-Liste nach CSMA/CD zu nehmen --Echoray 23:36, 24. Feb 2004 (CET)

done Mwka 10:47, 25. Feb 2004 (CET)

Fehler? Das Verfahren von ALOHANet ist "CSMA/CA" (..Collision Avoidance). Hier wurde gefunkt und auf Bestätigung gewartet, dass weitergefunkt wird. CSMA/CD hingegen arbeitet, wie im Artikel beschrieben, mit einem Jamming-Signal und einer zufälligen Zeitspanne, bis wieder versucht wird, zu senden (es sei denn, jemand anderes sendet vorher). Hedge 09:33, 25. Aug 2004 (CEST)

[Bearbeiten] Apple Talk

Welche Relevanz hat eigentlich der AppleTalk-Protokollstack?

TCP/IP ist ja die allgemeine und plattform-übergreifende theoretische Strukturierung - wenn wir jetzt aber jede Implementation jedes Betriebssystems aufnehmen, wird das IMHO etwas viel. Mwka 07:51, 12. Jun 2004 (CEST)

Stimmt, jetzt wo Du's sagst... Da steht tatsächlich ein Protokollstapel in der Landschaft mit lauter Abkürzungen drin, die mir nichts sagen, und die auch nirgendwo erklärt werden. Wenn keine guten Gegenargumente kommen, nehmen wir den Stapel heraus, OK? --Echoray 12:50, 12. Jun 2004 (CEST)

Ich hatte den Appletalk-Stapel extra eingebaut, um zu zeigen, dass Ethernet eben nichts TCP/IP-Spezifisches enthält. Genausogut hätte man Decnet einbauen können. Würde man den Stapel rausnehmen, entstünde leicht der Eindruck Ethernet sei für IP gemacht worden und umgekehrt. Dies ist nicht der Fall. Anderen sagen die Kürzel UDP, DNS etc. auch nichts. Bin eigentlich gegen rausnehmen. Die Abkürzungen werden teilweise im Appletalk-Artikel erklärt. --Hubi 16:04, 12. Jun 2004 (CEST)

was mir an dem Bild mit dem IP-Protokollstack noch aufgefallen ist: Das ARP-Protokoll ist in der Netzwerkschicht untergebracht. Funktionell ist das sicher nicht falsch. Aber von der Logik her müsste es eigentlich in der Schicht stehen, wo auch DHCP steht. Eigentlich habe ich immer nur Abbildungen gesehen, wo ARP oberhalb der Transportschicht sitzt. Mein Vorschlag wäre also, das ARP nach oben zu tun. Oder ? sorry, Tilden vergessen. Sadduk 16:33, 12. Jun 2004 (CEST)

Nein, niemals!!! Da gab's schon mal eine Diskussion. Von der Logik kann man entweder das OSI-Modell heranziehen, dann gehört ARP so zwischen Schicht 2 und Schicht 3, oder aber einfach die verwendeten Header/Frames

• ARP: Ethernet-Header, ARP-Header -> untere Schicht (2 oder so)
• DHCP: Ethernet-Header, IP-Header (ggf. Dummy-Adressen), UDP-Header, DHCP-Paket -> Anwendungsschicht

DHCP kann man routen (da ja ein IP-Header da ist). DHCP ist technisch gesehen eine Anwendung oberhalb des Transportprotokolls UDP. Hier kann man alle Netzwerkfeatures (z. B. DHCP-Server in Amerika!!!) verwenden. ARP ist jedoch einfach in einen Etherframe reingeklatscht, also auf Subnetze beschränkt. ARP hat einen Ethernet-Type, DHCP nicht (es hat einen UDP Port). Vom OSI-Modell lässt sich ARP nicht eindeutig einordnen, gehört aber auf jeden Fall unten hin, da kein Routing, kein Transport und keine Session erkennbar ist. Vielleicht kannst du ja mal eine Quelle nennen, wo ARP oberhalb der Transportschicht angesiedelt ist???? --Hubi 08:55, 13. Jun 2004 (CEST)

hmmm... in dem Buch, das ich in die Literaturliste eingefügt habe, ist ARP tatsächlich auch unterhalb von TCP eingezeichnet. Deine Argumente sind natürlich auch noch gut, das muß ich zugeben. Hast Du mal in den RFC geguckt, ob da ein Bild drin ist ? Sadduk 11:05, 13. Jun 2004 (CEST)

ARP ist eines der Protokolle, die nicht konkret in eine ISO/OSI Schicht passen, da sie sozusagen "Glue"-Protokolle sind. Sie verbinden einen Aspekt von Layer 2 und 3, der durch keinen generischen Ansatz der Definition abgedeckt wird, denn er verbindet "MAC" Adressen mit "IP" Adressen. In den meisten Skizzen ist es daher tatsächlich in der dazwischen oder als Kästchen mit je einer Hälfte in Layer 2 und 3 angezeigt.Hedge 09:33, 25. Aug 2004 (CEST)

Ich möchte bestätigen, ARP / RARP gehören eindeutig in OSI-Layer 3, TCP/IP-Layer 2, Network Layer, oder alternativ zusätzlich in OSI-Layer 2, TPC/IP-Layer 1, Data Link Layer / Hardware Layer, keinesfalls jedoch irgendwo darüber. ARP/RARP sind TCP/IP-Protokolle, verwenden aber nicht IP, nur IP-Adressen, also keinesfalls über der Network-Layer ansiedeln.

Das AppleTalk-Beispiel würde ich in jedem Fall dalassen, es hat viele positive Aspekte. Es zeigt, dass es außer TCP/IP noch andere Protokollstacks gibt. Und es zeigt, dass Ethernet erstmal nichts mit TCP/IP zu tun hat, sondern TCP/IP nur ein möglicher Client-Stack von Ethernet ist. --ChristianHujer 13:25, 25. Jan 2005 (CET)

ARP ist ein routing protocol kein routed protocol daher wird es auch niemals in einem dieser Modelle erwähnt. Andere Beispiele: OSPF, BGRP (border gateway routing protocol wenn ich mich richtig erinnere) um zwei routing-protokolle zu nennen die mir noch einfallen. Diese sind nicht in den Modellen inkludiert weil diese Modelle "nur" dazu dienen routed protokolle ... also diejenigen die wirklich die Daten transportieren... abzubilden. Ein routing protokoll ist ein hilfswerkzeug um die Funktionalität zu gewärleisten. - by Privateer at CEST 16.06.2005-23:56

DHCP ... nein man wird niemals einen DHCP-Server am anderen ende der Welt verwenden können. Es werden IP-Broadcasts verwendet... 0.0.0.0/0 ruft 255.255.255.255/0 ... scheitert spätestens am ISP der Broadcasts kaum in andere Netze routen wird. Weil nicht notwendig sondern eher Konfigurationsfehler. (Eben zB requests an einen DHCP die ansonsten das "Netz zumülln") Ebenso werden (zumindest die meißten DHCP-Server konfiguriert um nur auf bestimmte MAC's zu reagieren ... ohne jetzt zu erwähnen dass man die natürlich fälschen kann...) - by Privateer at CEST 16.06.2005-23:56

Man kann sehr wohl einen DHCP-Server am anderen Ende der Welt nutzen, dafür nutzt man dann UDP-Relay. Sprich der Router (Standard Gateway) eines Subnetzes muß dazu lediglich so konfiguriert sein, dass er UDP Anfragen auf den DHCP/BOOTP-Ports an eine definierte IP-Adresse (die des DHCP-Servers) weiterleitet. Und das wird dann geroutet, und der DHCP kann dann auch ruhig an der Westküste der USA stehen, das ist dann nämlich egal. -- Raven 09:06, 15. Okt 2005 (CEST)

[Bearbeiten] Sicherheit und Switches

In diesem Beitrag werden Switches als Lösung des Sicherheitsproblems genannt. Da sich eigentlich alle Switches z.B. mit ARP-Flooding/Spoofing so austricksen lassen, daß sie die Ethernet-Rahmen auch an andere Teilnehmer als den vorgesehenen ausliefern, würde ich vorschlagen diesen Satz anders zu formulieren. Falls Bedarf besteht, erklär ich mich auch dazu bereit Artikel über diese Angriffe zu schreiben.

Du hast recht. Switches sind niemals dazu gedacht gewesen, die Systemsicherheit zu erhöhen und auch nicht dazu geeignet. Dass dann Passwörter nicht überall vorbeihuschen, ist nur ein Nebeneffekt. Der Satz muss erstmal raus. Dass Ethernet per se keine Sicherheit bietet, kann man noch erwähen. ARP etc. gehört genaugenommen nicht zum eigentlichen Thema. Das im Prinzip interessante ARP-Flooding/Spoofing vielleicht unter ARP oder Switch beschreiben. --Hubi 08:08, 19. Okt 2004 (CEST)

Das ist richtig, Ethernet bietet keine Sicherheit.

muss es auch nach OSI-Standart nicht --Jon02

[Bearbeiten] 802.x == 802.2

Unter "Ethernet-Frameformate und das EtherType-Feld" steht mehrfach 802.x. Kann es nicht genauer auch 802.2 heißen bzw. muss es nicht sogar 802.2 heißen?? Vergleiche dazu auch die engl. Version.

Der Ethernet-Frame ist in IEEE 802.3 definiert. Die LLC-Schicht ist in 802.2 definiert. Also wenn dann müsste es 802.3 heissen.

Die Bezeichnung 802.3 habe ich hoffentlich konsequent eingearbeitet. Auch hoffe ich zutreffend dargestellt zu haben wie die historischen Formate Ethernet I und Ethernet II im Standard IEEE 802.3 fortleben. Für Ethernet und die Beförderung von Frames ist der Ethertype, LLC oder SNAP völlig bedeutungslos. Da müssen sich höhere Schichten drum kümmern. Die einzige Ausnahme ist der Ethertype für den tagged MAC-frame.

[Bearbeiten] AUI und AAUI

Eine "Besonderheit" wird in dem Ethernet Artikel leider noch nicht erwähnt und zwar die AUI- (Attachment Unit Interface) und die AAUI-Schnittstellen (Apple Attachment Unit Interface). Die ich leider zu wenig Kenntnis über diese Materie habe, wäre es schön wenn ein Experte diese Beiden Schnittstellen noch in den Artikel einbringen könnte. :) (Stichwort: Transceiver)

Siehe http://www.ccr-computerclub.de/lam2/aui_aaui.htm Mjh 15:48, 28. Apr 2005 (CEST)

[Bearbeiten] Gesamtlänge Ethernet-Paket

Im Bild des Ethernetframes ist ein Fehler: Die Länge der Daten ist fälschlich mit 46-1500 angegeben. Dort sollte, wie auch im nachfolgenden Text richtig beschrieben, 0-1500 stehen. Die Mindestlänge von 46 macht ein Padding überflüssig. Leider weiss ich nicht wie ich das Bild korrigieren kann. Kann da jemand helfen? --HH1946 19:06, 3. Dez. 2006 (CET)

Ich (ein in Sachen Ethernet nicht Unerfahrener) halte das Bild für korrekt. Wenn man das zugrundeliegene Protokoll unberücksichtigt lässt, muss man tatsächlich mindestens 46 Bytes "Daten" ansetzen. Was man letztlich als "Daten" bezeichnet (Nutzdaten+Padding oder "Roh"daten oder...) ist Geschmacksache. Das Bild macht vielmehr deutlich, dass sinnvoll mit der Mindest-"(Roh-)Daten"-Größe von 46 Bytes umgegangen werden muss. Dies leistet das Ethernet-Protokoll nicht. Will man beispielsweise stets pro Frame Daten mit genau 128 Bytes Länge übertragen, wäre eine interne Protokollstruktur unnötig, da der Empfänger die Datenlänge rückrechnen kann. --Hubi 15:11, 4. Dez. 2006 (CET)

Warum wird die Checksumme nicht mitgezählt? Normalerweise wäre die Gesamtlänge max. 1520 Byte... - Appaloosa 01:31, 13. Mai 2005 (CEST)

• Im Bild ist durch den Pfeil die Paketlänge korrekt beschrieben (Vom Anfang der Zieladresse bis zum letzten Byte der Prüfsumme). Die Präambel zählt nicht für die Paketlänge. In der Paketlänge ist das Datenpaket mit maximal 1500 Byte enthalten. Hinzu kommt der Paketkopf mit 14 (mit vlan-Tag 18) Byte und am Ende die Prüfsumme mit 4 Byte. Damit ergibt sich eine Gesamtlänge von 1518 bzw. 1522 Byte -- ohne die Präambel aber einschliesslich Prüfsumme.

Bei der Ermittlung der Prüfsumme wird aber nur der Teil des Pakets vor der Prüfsumme verwendet und nicht die erst zu ermittelnde Prüfsumme selbst. Für die Paketlänge wird die Prüfsumme berücksichtigt, bei der Ermittlung der Prüfsumme bleibt aber dieser Teil des Paketes ausgespart. Im Übrigen ist die Paketlänge sowieso nur für die uralt-Ethernet-I Formate von Bedeutung. Für die neueren Formate ergibt sich die Paketlänge einfach durch das Ende der Übertragung.

Die Präambel gehört zwar per Definition IEEE 802.3 zum Frame, wird aber in der Framelänge nicht berücksichtigt. Da sie keine Informationen überträgt. Die Präambel, sie besteht aus einer alterrierenden Folge von "01" (ausser das letzte Doppelbit, dieses ist "11"), stammt viel mehr noch aus der Zeit als das Ethernet-Signal auf dem Medium (Kable) mit dem Manchester-Code kodiert wurde. Durch die Präambel hatte der Empfänger somit ausreichend Zeit den Signaltakt des Signals zu erkennen und sich auf diesen Takt zu synchronisieren damit er die Takte im informationstragenden Teil des Frames sauber trifft. -- Raven 09:01, 15. Okt 2005 (CEST)

[Bearbeiten] Gigabit Ethernet

In den Angaben stehen: - 1 Gbit/s - 5-PAM - 2 Adernpaare in eine Richtung - 125 MBaud

Irgendwie krieg ich das nicht auf eine Reihe. 5-PAM sind etwas mehr als 2Bit pro Schritt. Sind wir heute etwas grosszügig und runden auf 3Bit auf. Man rechne: 3Bit/Baud x 2Adernpaare x 125MBaud/Adernpaar = 750Mbit/s

Wie kommt man auf 1Gbit, kann mir jemand helfen? Spirig 14.10.2005

Es sind wg. der Fehlererkennung sogar nur 2 Bit pro Schritt und Adernpaare. 4 Adernpaare ergeben 1000 MBit/s. Ob in jede Richtung lediglich 2 Adernpaare=500 MBit/s zur Verfügung stehen, kann ich derzeit nicht sagen --Hubi 17:29, 14. Okt 2005 (CEST)

Es stehen in jede Richtung die selben 4 Adernpaare zur Verfügung, weil sowohl der Sender als auch der Empfänger an den Enden der full-duplex Verbindung die selben 4 Adernpaare zum Senden und Empfangen benutzen. Der Duplexbetrieb, sprich das gleichzeitige Senden und Empfangen auf den selben Adernpaaren wird durch Echokompensation erreicht. -- Raven 08:55, 15. Okt 2005 (CEST)

Die Variante mit 2 Paaren ist 1000BASE-CX (625MHz Übertragungsfrequenz,150 Ohm Kabel), die Variante mit 4 Paaren aber nur 2 pro Richtung ist 1000BASE-TX (125 MHz Übertragungsfrequenz). Beide sind kaum noch anzutreffen. -- Schmendrik 27. Jun 2006

[Bearbeiten] Ethernet Reichweite

Es ist ein sehr Umfangreicher Artikel, darum musste ich ihn mehrfach Überfliegen um fest zu stellen, das zwar für jede Außerdienst genommene Variante z.B. 10Base2 die max. Leitungslänge angegeben wird, aber beim Standard nicht auf die maximale Ausdehnung eingegangen wird. Diese Information sollte für 100BaseTX definitiv nachgepflegt werden. Weiss aber selber nicht wo ich die jetzt finden könnte. -- wannabee3 13:25, 29. Dez.2005

Die maximale Ausdehnung ist nur im halb-duplex Betrieb von Bedeutung. Sie ergibt sich aus der Ausbreitungsgeschwindigkeit des Signals im Kabel. Der Grund liegt im CSMA/CD, hier wird eine gewisse "Zeit" gebraucht um Kollisionen zu erkennen und den Zustand der Kollision, mittels des sogenannten JAM-Signals, zu kommunizieren. Die hierfür benötigte Zeit beträgt bei 10 und 100 MBit Ethernet ca. 512 "bit times". Eine "bit time" ist die Zeit, die auf Layer 2 benötigt wird um ein Bit auf dem Medium zu senden. Für 10Base5 ergibt sich eine maximale Ausdehnung von ca. 2,8 km pro Kollisionsdomäne. Für 10BaseT gibt es noch als einfache Faustregel die "5-4-3-Regel für Repeater". Bei 100BaseTX beträgt die maximale Ausdehnung in der Kollisionsdomäne dagegen nur noch ca. 210m, da erstens in einem Twisted Pair-Kabel die Ausbreitungsgeschwindigkeit des Signals geringer ist als in einem Koaxialkabel und zweitens natürlich die "bit time" nur noch ein Zehntel der "bit time" von 10 MBit-Ethernet enspricht. Im full-duplex Betrieb, in dem es per Definition keine Kollision geben kann besteht auch keine direkte Grenze für die maximale Ausdehnung eines "lokalen" Ethernet-Netzes. Hier werden nur irgendwann einfach die Antwortzeiten zu lang, aber damit sollte man in der Praxis keine Probleme bekommen. -- Raven 14:17, 29. Dez 2005 (CET)

Bei full-duplex-Betrieb werden durch die Dämpfung Grenzen gesetzt. Bei einer Dämpfung von zB 20 dB kommt nur noch ein Zehntel der Eingangsspannung am Ende der Leitung an usw.. Die Antwortzeiten sind nach meiner Kenntnis unproblematisch.

Wobei hier wieder anzumerken ist, dass jeder Switch das Signal elektrisch verstärkt, somit kann die Dämpfung immer nur ein Problem auf Teilstrecken sein, z.B. vom PC zum Switch oder von Switch zu Switch. Für die Gesamtausdehnung ist die Dämpfung eher unerheblich. -- Raven 14:35, 24. Feb 2006 (CET)

Da findet sich etwas hierzu in IEEE 802.3 2. Teil Kapitel 29.1-4. Speziell "29.4 Full duplex 100Mb/s topology limitations" sagt definitiv aus, dass auch für ein voll-geswitchtes 100Mbps FD Netz mit UTP (Clause 25 - beschreibt wohl Cat5) die Segmentlänge auf 100m limitiert ist. Auch wenn praktisch eine längere Verbindung funktioniert, dann würde ich keinem Kunden/Anwender dies empfehlen. HH1946 17:01, 15. Apr 2006 (CEST)

Wobei anzumerken ist, dass das Layer-2-Segment jeweils aus einem PC und einem Switch, oder einem Switch und einem Switch, besteht und das darf jeweils 100m lang sein. Aber wenn man PC - Switch - Switch - Switch - Switch - PC nimmt, können die beiden PCs einen halben Kilometer auseinander stehen... eben weil man 5 Layer-2-Segmente hat. -- Raven 19:04, 15. Apr 2006 (CEST)

Ob der PC bzw. Switch zum Segment gehört kann man bezweifeln. Die IEEE Designer hatten eigentlich ein 5m Patchkabel (etwas dünnere Drähte und daher biegsamer) an jedem Ende und maximal 90m Festverkabelung dazwischen vorgesehen und bezeichnen eher die Verbindung zwischen den Geräten als Segment. Wenn man mehrere Switches ins Spiel bringt dann haben wir natürlich mehrere Segmente und dementsprechend addieren sich die Längen. Praktisch sind die Verbindungen zwischen den Switches dann auch sehr oft in GF-Technik ausgeführt (aber das ist nicht gegenstand dieser Diskussion) und dann kann ein Segment zwischen zwei Switchen ja auch mehrere Kilometer (z.B mit Monomode-Glasfasern und long-range Laser Licht) sein. Auch besteht beim Einsatz von Switches nicht mehr die Beschränkung auf 5 Segmente wie bei der alten Repeaterregel. Durch's Hintertürchen (Spanningtree) wird aber dann die Anzahl der Switches doch wieder limitiert. Ich glaube hinsichtlich der technischen Möglichkeiten sind wir uns ziemlich einig. Für die Wikipedia Leser müssten wir aber jetzt mal als Reaktion auf die obige Anfrage Länge bei 100BaseTX auch was gut verständliches, möglichst im Artikel selbst, zustande bringen. Auch diese Diskussion könnte damit zusammengekürzt werden. HH1946 18:03, 16. Apr 2006 (CEST)

Jetzt habe ich als schnelle Lösung 100m als zulässige Segmentlänge bei 100Base-T und bei 1000Base-T im Artikel eingetragen. Vielleicht wäre im Artikel ein ganz neues Kapitel Ethernet-Topologie der richtige Platz für all diese Längenangaben. HH1946 18:28, 16. Apr 2006 (CEST)

[Bearbeiten] Toter Weblink

Bei mehreren automatisierten Botläufen wurde der folgende Weblink als nicht verfügbar erkannt. Bitte überprüfe, ob der Link tatsächlich down ist, und korrigiere oder entferne ihn in diesem Fall!

• http://www.10gea.org/
  • In Ethernet on Sun Jan 22 01:43:22 2006, Socket Error: (-3, 'Tempor\xc3\xa4rer Fehler bei der Namensaufl\xc3\xb6sung')
  • In Ethernet on Sun Jan 29 21:12:12 2006, Socket Error: (-3, 'Tempor\xc3\xa4rer Fehler bei der Namensaufl\xc3\xb6sung')

--Zwobot 21:12, 29. Jan 2006 (CET)

• 10 Gigabit Ethernet Alliance Website aus Artikel entfernt

Auch eine heutige Suche nach 10gea über google war ziemlich erfolglos; keine Hinweise auf 10gea aus 2005, 2006. Die Domäne 10gea.org ist noch registriert, hat aber keinen MX, keinen www, keinen info Eintrag. Auf http://www.nortel.com/corporate/technology/standards/participation_de.html#etf gibts noch einen Hinweis, dass nortel früher bei 10gea aktiv war und auch den Vorsitz hatte - aber sonst nichts brauchbareres als einen Rückverweis auf IEEE 802.3ae archive. HH1946 22:03, 20. Apr 2006 (CEST)

[Bearbeiten] Abkürzungen der Ethernet-Standards

Seit Tagen suche ich mir einen Wolf nach der Bedeutung der Abkürzungen SX, TX, FX, usw. Vor allem: was bedeutet das X? Wäre Euch dankbar, wenn das einer klären könnte.

Ob es eine wörtliche Bedeutung des "X" gibt kann ich Dir leider nicht sagen, das entzieht sich auch meiner Kenntnis. Aber den jeweiligen X-Standards kommt jeweils das Gleiche block encoding zum Einsatz. So nutzen 100BaseTX und 100BaseFX 4B/5B-Symbole und 1000BaseCX, 1000BaseSX und 1000BaseCX 8B/10B-Symbole. Ich kenne daher nur den jeweiligen Zusammenhang über das block encoding. Ebenfalls ist den X-Standards gemein, dass sie von anderen Verfahren adaptiert wurden. Die 100-X-Verfahren sind ursprünglich für FDDI und die 1000-X-Verfahren für Fibre Channel entwickelt und erst später für Ethernet adaptiert worden. Leider klärt das aber noch immer nicht, wofür das "X" steht. Achja, das "S" steht für short, das "T" für twisted pair, das "F" für fibre, das "C" für copper und das "L" für long. -- Raven 22:16, 22. Feb 2006 (CET)

[Bearbeiten] Verständnisproblem

Der erste Satz "Ethernet ist eine Rahmen basierte Computer-Vernetzungstechnologie für lokale Netze (LANs)." war für mich selbst beim dritten Mal lesen unverständlich, irgendwo fehlt da einfach ein Wort oder (definitiv!) ein Bindestrich. "Rahmen-basierte" oder "Rahmenbasierte"? Aber was ist eine solche Computer-Vernetzungstechnologie? (Imho müsste es ja "Computervernetzungstechnik" heißen.) Ich wäre dafür, dass jemand -mit mehr Ahnung als ich- diesen ersten Satz mal verständlich macht und "grammatikalisch optimiert". --^icewind^ 21:12, 14. Apr 2006 (CEST)

Ich hoffe den ersten Absatz etwas lesbarer gemacht zu haben und die enthaltenen Aussagen im wesentlichen erhalten zu haben. Den Hinweis, dass Ethernet heute aus dem LAN heraus gewachsen ist, konnte ich mir nicht ganz verkneifen. Weggelassen habe ich die MAC/LLC Sublayer-Hinweise. Ich glaube nicht, dass diese an so prominenter Stelle wichtig sind. Auch müsste dann auf die LLC Standardisierung in 802.2 eingegangen werden. HH1946 16:36, 15. Apr 2006 (CEST)

1) Ich werfe das rahmenbasiert gleich mal raus, schließlich dient Ethernet ja der Übertragung von Datenrahmen (2. Satz), das Wort macht den Einstieg echt unverständlich.

2) Bzgl. Deines unverkniffenen Hinweise: Wie weite Strecken denn? Ahoi, Fragment 21:32, 28. Mai 2006 (CEST)

Unter dem Stichwort MetroEthernet kann man da vieles finden, insbesondere auch über Ethernet-Erweiterungen wie z.B. hierarchische Vlans oder auch Diskussion über besseres Management. Mit entsprechenden optischen Transceivern sind auf jeden Fall 40 km überbrückbar. So lassen sich in Städten wunderbare (native) Ethernets aufbauen - 2 Coreswitches reichen um Standorte oder auch Access Switches im Abstand von z.B. 20km anzubinden - man braucht nur einige Glasfasern an der richtigen Stelle. Mit einigen Coreswitches mehr oder besonderen Transceivern ist da auch noch wesentlich mehr drin. Meine Firma nutzt z.B. ein solches Stadtnetz in Nürnberg. Diese nativen Ethernets haben den Charm, sich hinsichtlich Laufzeiten wie ein LAN zu benehmen. Daneben gibt es auch die Technik eine Ethernetschicht auf eine WAN Struktur drauf zu legen, z.B Ethernet über SDH. Damit sind beliebige Entfernungen machbar und die Schnittstellen benehmen sich auch wie Ethernet. Aber die Struktur darunter macht sich doch immer wieder mit Laufzeiten oder vielfach kleineren Bandbreiten in irgendwelchen Links bemerkbar. HH1946 19:02, 9. Jun 2006 (CEST)

Spannend, Danke :) Fragment 12:57, 11. Jun 2006 (CEST)

[Bearbeiten] Keep-Alives

Habe etwas bzgl. den bei Ethernet-Hardware verwendeten keep-alives geschrieben, da hierzu noch nichts veröffentlicht wurde. Habe das mal in einer Router-Dokumentation von CISCO gelesen (nehme an Zertifizierungsprogrammen von der CISCO-Academy teil), wenn unbedingt erforderlich kann ich ggf. mal den Link zu dem Paper raussuchen. --Andreas Weber 19:41, 27. Apr 2006 (CEST)

[Bearbeiten] Bitübertragungsschicht (Punkt 2)

Man sollte mal mit dem Gedanken spielen den Punkt 2, "Bitübertragungsschicht" umzustrukturieren. Der Unterpunkt "Broadcast und Sicherheit" hat rein gar nichts mit Layer 1 zu tun (bezieht sich auf Layer 2-Angaben), während der von mir hinzugefügte Absatz zu Keep-Alives Layer 2-Frames benutzt um Layer 1-Konnektivität zu beschreiben; ich würde hier also nicht wie es derzeit der Fall ist eine Linie ziehen und sagen hier steht alles zum Thema Bitübertragungssicht. Was meint ihr wie man das am besten löst? (der Broadcast-Unterpunkt muss aber da definitiv raus) --Andreas Weber 19:51, 27. Apr 2006 (CEST)

[Bearbeiten] Stacked VLANs (QinQ)

Stacked VLANs sind in Text und Grafik nicht berücksichtigt. Sollte man das ändern?

-- Gerald Klix

[Bearbeiten] ``bitgenaue Signalisierung des Übertragungsendes"

... beim Ethernet II-Frame-Format. Wie funktioniert das?

Beim 10Mbps Ethernet wird eine Schlussequenz verwendet, die durch "Bitstuffing" so im regulären Datenstrom vermieden wird. Darüber findet man z.B im Artikel zu HDLC im Absatz Blockaufbau eine Erläuterung. Bei den höheren Ethernetgeschwindigkeiten werden in der Übertragung spezielle Symbole verwendet die nicht in der Darstellung des eigentlichen Frames Verwendung finden. Ein Symbol hat beispielsweis 5 mögliche Werte. 0-3 können dann z.B für die Darstellung einer ZweiBit Kombination verwendet werden und der 5 Wert signalisert eine Steuersequenz. HH1946 19:22, 9. Jun 2006 (CEST)

[Bearbeiten] Keine Präambel bei Geschwindigkeit > 10 MBit?

Eine kleine Anmerkung zu dem (echt guten) Artikel: Stimmt es das bei Geschwindigkeiten größer als 10 MBit/s keine Präambel mehr verwendet wird? Also ich habe davon noch nichts gehört, und auch nach wälzen von dem 802.3 Standard nichts gefunden.. Henning

Nein, das stimmt nicht. Das Dokument (IEEE 802.3) sagt eindeutig in Absatz 4.1.4, dass es die Aufgabe des "MAC sublayers" ist einem jeden IEEE 802.3-Frame eine Preambel, einen StartFrameDelimiter, usw. hinzuzufügen! Und da die Geräte mit Geschwindigkeiten über 10MBit/s weiterhin gültige IEEE802.3-Frames erzeugen (müssen) senden Sie auch eine Präambel. -- Raven 17:31, 28. Jun 2006 (CEST)

[Bearbeiten] Lesenswert-Kandidatur: Ethernet (Archivierung Abstimmung 31. Juli bis 7. August 2006)

Ethernet [i:θənɛt] ist eine Datennetztechnologie für lokale Datennetze (LANs). Sie ermöglicht den Datenaustausch in Form von Datenrahmen zwischen allen in einem lokalen Netz (LAN) angeschlossenen Geräten (Computer, Drucker, etc.).

• pro - für mich als Laien, der sich gerade mehr und mehr in unsere Computerartikel einliest, ein sehr schöner und verständlicher Artikel. Imho scheint er auch keine größeren Lücken oder schwerwiegenden Fehler aufzuweisen. -- Achim Raschka 20:59, 31. Jul 2006 (CEST)
• pro Der Artikel enthält eigentlich alle Informationen, die man zum Verständnis braucht. Ob alerdings auch Personen ohne Erfahrung mit Netzwerken dies so sehen, sei dahin gestellt. JulianP 23:12, 31. Jul 2006 (CEST)
• Pro Erst TCP (s.o.), dann Ethernet, warum nicht? Überraschend viel Information in so einem Artikel. --Rohieb 会話 00:21, 2. Aug 2006 (CEST)
• Pro meiner meinung nach durchaus lesenswert.--wdwd 19:24, 2. Aug 2006 (CEST)

[Bearbeiten] Power over Ethernet

Die Erklärung des Ausdrucks Power over Ethernet ist etwas dürftig, zumal ihm ein ganzer Abschnitt gewidmet ist. In dem Abschnitt wird dann nur kurz PoE erwähnt, aber nicht so richtig erklärend darauf eingegangen. Das könnte mal noch jemand nachholen.--Sammler05 19:22, 5. Dez. 2006 (CET)

Naja, wer mehr wissen will sollte wirklich Power over Ethernet lesen. Ich gebe zu, dieser Link versteckt sich derzeit etwas verschämt hinter der kryptischen Zeichenfolge "802.3af". Ist es OK, wenn wir nur das ändern? --Echoray 19:42, 5. Dez. 2006 (CET)