Diskussion:Ethernet/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Ethernet/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Ethernet/Archiv#Thema_1

Falsche Darstellung der Ethernet Frames

Hier wurde eine unglücklich Formulierung und ein in sich nicht stimmendes Bild verwendet. Ich habe leider noch keine vollen Rechte und kann deshalb den Artikel noch nicht richtig bearbeiten. Also kommen wir zum Problem unter IEEE 802.3 Tagged MAC Frame ist ein Bild dargestellt das nicht in sich stimmig ist. Es gibt 2 verschiedene Hauptframe Arten einmal Ethernet 2.0 und halt 802.3 Der Hauptunterschied ist das 802.3 kein Type Field hat sondern ein Length Field. Dadurch kann es keine Information zum nächst höheren Protokoll weitergeben. Dadurch kommt SNAP zum Einsatz dies ist ein Overload der den ersten Teil der MAC-Adresse beinhaltet und ein Type Field mit sich bringt. Desweiteren sollte man auf die unter Arten von 802.3 eingehen. Ich habe dazu eine gute Webseite gefunden, wo mein Standpunkt nochmal verdeutlicht wird. Selbst CISCO ist bei dem Frame Aufbau der selben Ansicht. Also ich finde bei Ethernet sollten die Frames überarbeitet werden.

Hier eine Quelle:

[1]

Ich stimme dem vorhergehenden Komentar zu. Hie soll das Ethernet-Format dargestellt werden (ohne Tag) und in der Präamble sollte AA.. stehen, im SFD sollte AB stehen. Das Bild zeigt das Format wie die Bytes übertragen werden (mit LSB first). Alle Standards definieren wie die Daten übertragen werden z.B. IEEE 802.3 LSB first, IEEE 802.5 MSB first. Die Daten werden aber als 10101010 d.h. xAA angegeben und nicht als 55. Das Format war schon einmal hier richtig dargestellt. Bitte wieder die vorherige Version wieder einstellen. In der jetzigen Form ist im Type-Feld 0800 (für IP) angegeben, das ist richtig. Im Übertragungsformat, wie der Rest dargestellt ist, müsse das auf 1000 geändert werden.

Wolfgang

Warum hat noch keine das falsche Ethernet_Frameformat ausgetauscht?

Wolfgang

Da hätte ich eine tolle Idee, geht zu [2] , holt euch die Originale, seht nach was stimmt. Wenn's eindeutig ist, malt ein korrektes Bild; wenn nicht diskutiert eventuelle Probleme hier. Und Vorsicht, der oben angegebene Link mag korrekt sein, wenn ja, so könnten seine Bilder dann übernommen werden, wenn der Author dem zustimmt. Ohne Freigabe unter GFDL fliegen auch korrekte Bilder wieder raus. --Kgfleischmann 07:37, 16. Jul. 2008 (CEST)

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)

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)

Wenn ich es richtig verstanden habe, dann stimmt doch aber folgendes nicht: "...Kollisionserkennung vorgeschriebene minimale Frame-Länge, bis hinauf zu 10-GBit-Ethernet unverändert." Ist die minimale Framelänge zur Kollisionserkennung nicht schon bei 1-GBit-Ethernet, im Halbduplex-Modus mit Hubs, und nur hier kann es ja die Kollision geben, auf 512Byte angestiegen? Sonst läge ja die maximale Netzgröße bei ca. 25m, oder?

CSMA/CD ist kein Algorithums sondern ein Zugrifssverfahren auf das Medium (Kupferkabel oder Frequenzband). Die minimale Bit Anzahl für 100Base-TX ist 512 Bit somit 64 Byte. Die Länge ist auf 100m pro Segment mit maximal 4 Repeatern begrenzt. Die maximale Länge ist damit 500m.

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)

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

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.

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)

Gesamtlänge Ethernet-Paket

Im Bild ist das Typ-Feld enthalten. Dies ist definitiv falsch! Es gibt nur im DIX-Format (welches in den meisten Home-Netzwerken zum Einsatz kommt) ein Typfeld.

• Da liegst du leider falsch! Im Standard 802.3 ist das Feld als typ/length Feld definiert. Anders als im DIX wird der Inhalt bei Zahlenwerten bis 1500 als length interpretiert. Bei Zahlenwerten über 1500 ist eine Interpretation als Typ vorgeschrieben. In 802.3 is nichts mehr über die Interpretation des Datenfeldes enthalten. Aus Sicht von 802.3 sind DSAP, SSAP, ff Teil des Datenfeldes und daher ist auch in 802.3 darüber nichts zu finden. In der Praxis sind mir bisher nür noch Formate mit Typ-werten begegnet. HH1946 19:12, 18. Aug. 2007 (CEST)

Im IEEE 802.3 Frame Format ist dieses Feld das Längenfeld, und danach kommt 1Byte DSAP (Destination Service Access Point, 1 Byte SSAP (Source Service Access Point) und dann 1 oder 2 Byte Control (Steuerfeld; erstes Bit 0 oder erste 2 Bits = 10 => 2 Byte; erste 2 Bit = 11 => 1 Byte Control) Bitte das Bild entsprechend ändern! Denn dann kommt als maximale LLC-SDU (Hier Datenfeld genannt), eine maximale Länge von 1497Bytes raus (Da ja 3Byte für DSAP, SSAP und Control reserviert sind). Dies ist der Grund, warum man im Netz der Telekom eine MTU von 1492 angeben soll. Denn man "funkt" mit dem DIX-Format raus, die Telekom jedoch arbeitet mit dem IEEE-Format. Deshalb muss das DIX-Format in ein IEEE-Format "verpackt" werden, damit es geroutet werden kann. Dazu muss dann noch ein SNAP-Header mit. Der SNAP-Header besteht aus 3Byte OUI (Organizationally Unique Identifier) und der 2Byte Type aus dem DIX-Format. Damit fallen für die Daten wiederum 5Byte weg und es bleiben die 1492Byte übrig, da die gesamt-MAC-PDU ja maximal 1518Byte lang sein darf.

Im Bild des Ethernetframes war ein Fehler: Die Länge der Daten war fälschlich mit 46-1500 angegeben. Das hatte ich an dieser Stelle beanstandet --HH1946 19:06, 3. Dez. 2006 (CET)

• Mittlerweile hat ein freundlicher Helfer diesen Mangel behoben. Danke. Diesen Diskussionspunkt erlaube ich mir hiermit zu schliessen. HH1946 19:12, 18. Aug. 2007 (CEST)

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)

Zu dem muss ich ein Statement abgeben... Wenn man das Layer 1 betrachtet, muss die Präambel, SFD und auch das Interfrage Gap berücksichtigt werden. Will man aber nur das Layer 2 betrachten, so lässt man diese 3 Sachen weg.

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

== 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)

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)

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)

Wie wärs mit X für "Full Duplex"? Sturmflut 21:42, 17. Apr. 2007 (CEST)

Verständnisproblem

Der erste Satz ... war für mich ...unverständlich, --^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)

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)

Hier ist erst mal dein Absatz, den ich aus dem Artikel entfernt habe:

Keep-Alives

Keepalive-Nachrichten werden in Ethernet-Netzwerken verwendet, um sicherzustellen, dass eine physikalische Verbindung nicht zwischenzeitlich unterbrochen wurde. Da Ethernet ein gemeinsam genutztes Medium (engl. „shared medium“) ist, wird jedoch nicht überprüft, ob eine Verbindung zu einem bestimmten Teilnehmer besteht, sondern lediglich, ob Lese- und Schreibzugriff auf das Medium (OSI-Schicht 1) möglich sind. Hierzu wird ein Datenpaket („frame“) mit der eigenen MAC-Adresse im Absender- als auch Empfänger-Feld sowie dem Wert 0x9000 im EtherType-Feld gesendet. Der unmittelbare Empfang des gerade versendeten Frames stellt sicher, dass die Ethernet-Hardware korrekt funktioniert und dass die Integrität des Übertragungsmediums sichergestellt werden kann.

In Full-Duplex-Installationen gibt es keine Keep-Alives. Höherwertige Techniken wie kontinuierliche Trägerwellen und Auto-Negotiation sowie ausgefeilte Loopback-Funktionen der PHY-Bausteine treten an ihre Stelle.

Absatz Ende

Wie du schon selbst schreibst, ist bei den heute üblichen Ethernetausprägungen - geswitched und 100 oder 1000 Mbps fullduplex ein keepalive nicht mehr notwendig um den Zugang zum Äther zu verifizieren. Viel wichtiger aber erscheint mir, dass diese Keep alives überhaupt nichts mit dem im Standard festgelegten Ethernet zu tun haben. Das ist ein Cisco Versuch der heute obsolet geworden ist und nie viel wert war. Ende zu Ende keepalives auf Anwendungsebene sind viel wichtiger als keep alives zwischen Endgerät und dem nächsten Switch. Dein Text könnte vielleicht eine Ergänzung zum Artikel über keepalive sein.HH1946 19:57, 18. Okt. 2007 (CEST)

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)

``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)

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)

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)

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)

N

==

Überschrift

== aja, 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)

10Base-T mit vier Adern

Wenn 10Base-T nur vier Adern nutzt, könnte man es doch auch durch ein Telefonhörer- bzw. 6P4C-Modemkabel schicken, oder? 217.86.30.191 14:36, 3. Jan. 2007 (CET)

Im Prinzip hast Du recht. Wenn die Leitungslänge ausreichend kurz ist, funktionieren vielleicht auch noch nasse Schnürsenkel. </irony>

Dem üblicherweise mit ungeschirmten Modularsteckern verwendeten Telefon-Flachkabel fehlt die geforderte Verdrillung der Adernpaare. -btl- 13:49, 23. Jan. 2007 (CET)

Wellenlängen bei 1000Base-LX / 1000Base-ZX

Im Text wird die Wellenlänge für 1000Base-LX / 1000Base-LX/LH mit 1350 nm angegeben. Meiner Meinung nach richtig wäre aber die Wellenlänge von 1310 nm (siehe diverse Herstellerspezifikationen). Bei 1000Base-ZX liegt die Wellenlänge bei 1550 nm.

Telephono 15:48, 23. Apr. 2007 (CEST)

Eigener 802.3 Artikel ?

Im englischen gibt es einen Artikel des sich expli. mit IEEE 802.3 befasst (im deutschen gibt es bisher nur eine Weiterleitung von 802.3 auf Ethernet). Wie sieht eure Meinung dazu aus? Ich wäre bereit bzw. ich habe für mich Teile des Artikels übersetzt die ich bei Bedarf/auf Wunsch einstellen könnte.

Meine eigene Meinung ist, dass der Artikel 802.3 einiges nochmal aufgreift was hier in Ethernet schon steht, also redundant ist. Andererseits ist die Tabelle aus dem englischen Artikel zur Übersicht nicht schlecht - vielleich einfach nur diese hier einbinden? (ich habe diese Übersetzt vorliegen..) GandalfTheWhite 17:41, 10. Jun. 2007 (CEST)

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

ARP ist um Gottes Willen KEIN Routing protokoll. ARP kann nicht routen weil es im gegensatz zu echten Routing Protokollen (RIP, EIGRP, OSPF, etc.) auf Schicht-2 des OSI-Modelss arbeitet. Was hier für Vollpfosten rumrennen die meinen sie wüssten irgendwas. Lächerlich. Routingprotokolle dienen auch nicht dazu irgendwelche Daten zu transportieren sondern Pakete zu durch das Netz zu routen. Transportfunktionen werden von Transportprotokollen (TCP, IPX, etc.) übernommen. Ein Routingprotokoll dient auch nicht dazu irgendein geroutetes Protokoll abzubilden. Das sind zwei komplett verschiedene Dinge. Am besten du frischst dein "Wissen" im Bereich Netzwerkkram etwas auf bevor du hier so einen Schwachsinn erzählt. Sorry für die harten Worte, aber da wird mir als Cisco-Experte echt schlecht bei sowas.--84.184.193.253 16:42, 19. Okt. 2008 (CEST)

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)

Leitungslänge 100Base-X

Ich vermisse im Artikel einen Hinweis zur maximalen Leitungslänge bei 100Base-X (IEEE 802.3 Clause 24) für Twisted-Pair-Kabel.

Rudolf

[[3]] 10BASE5 coax cables had a maximum length of 500 meters / [[4]] According to the standards, they all operate over distances of 'up to 100 meters'. – However, with high quality cabling, cable runs of 150 meters or longer are often obtained … – 100BASE-TX and 1000BASE-T both require a minimum of Category 5 cable (5e or 6 with 1000 Mbit/s) and also specify a maximum cable length of 100 meters. Furthermore while 10BASE-T is more tolerant of poor wiring such as split pairs, poor terminations and even use of short sections of flat cable, 100BASE-T is not as much so, and 1000BASE-T is less tolerant still. Since testing of cable is often limited to checking if it works with Ethernet, running faster speeds over existing cable is often problematic. This problem is made worse by the fact that Ethernet’s autonegotiation takes account only of the capabilities of the end equipment, not of the cable in between. Fritz Jörn 08:46, 14. Mai 2009 (CEST)

Flow Control

Flow Control findet auf der Logical Link Layer statt und wird auch bei Ethernet implementiert, die englishe Wikipedia hat dazu einen Artikel: Ethernet flow control. Dieser sollte zumindest kurz zusammengefasst (und übersetzt :) hier eingebaut werden.Eke 15:02, 28. Mai 2009 (CEST)

Licht

Im Artikel ist mehrfach von Licht die Rede. Bei der Übertragung mithilfe von Glasfasern kommt jedoch nur elektromagnetische Strahlung aus dem Infrarot-Bereich zum Einsatz. Nur der für das menschliche Auge sichtbare Bereich des elektromagnetischen Spektrums wird als Licht bezeichnet. Dieser liegt etwa zwischen 380 nm und 780 nm. Im Artikel sollte der Begriff "Licht" durch "Strahlung" ersetzt werden. Wenn bei 100Base-SX (850 nm) von einigen Menschen noch ein schwaches Rot erkannt wird, liegt das nach meinem Kenntnisstand daran, dass bei 1000BaseSX keine Laser-Dioden zum Einsatz kommen, sondern Infrarot-Leuchtdioden. Diese verhalten sich bei der Aussendung von Strahlung nicht so schmalbandig wie das für Laser gilt. -- Tornadohalt 11:53, 15. Jun. 2009 (CEST)

8P8C

"Anschluss erfolgt über 8P8C-Modularstecker/-buchsen (häufig falsch als „RJ45“/„RJ-45“ bezeichnet) in einer Sterntopologie." Imho, und auch so im Artikel zu den Steckern genannt, ist die übliche Handelsbezeichnung RJ45. Von falsch kann nicht direkt die Rede sein.

Nur in Europa/Deutschland führt der Handel die Bezeichnung RJ45. Die Bezeichnung mit RJ45 hat sich durch den Handel in Europa/Deutschland stark verbreitet. Sie wird dadurch jedoch nicht automatisch korrekt. -- Tornadohalt 11:36, 15. Jun. 2009 (CEST)

Diskussion Schichtenmodell

In den rechten BOXen "Ethernet mit..." ist eine Schicht Net vorhanden. Müsste da nicht Vermittlungsschicht stehen?

-> nein, da es sich um vom ISO-OSI-Referenzmodell verschiedene! Protokollstapel handelt. Vergleiche mal das OSI-Modell mit dem TCP/IP-Modell. Diese sind verschieden! (Ben)

Ich halte von ISO-OSI-Referenzmodell verschiedene... Modelle für Unsinn. Man sollte beim ISO/OSI-Modell bleiben und nicht neue Modelle einführen. Natürlich gehören dann die Informationen wie (u.a.) "kein Unterschied in den Schichten 5-7 in der Praxis" dazu. Verschiedene Modelle widersprechen dem Sinn "Erklärung und Darstellung des Verhältnisses der vielen benutzten Protokolle untereinander". P.S. Ich arbeite seit 25 Jahren in der Branche. Sehr ärgerlich ist auch, dass die sehr gängigen Protokollstandards wie IEEE 802.3ab weitgehend durch die "clause"-Bezeichnung ersetzt wurden - seht euch mal die Geräte-Handbücher an, was da steht. Str. (nicht signierter Beitrag von 88.79.240.168 (Diskussion | Beiträge) 13:40, 12. Aug. 2009 (CEST))

Mindestlänge

"Bei einer Übertragungsrate von 10 Mbit/s und einer maximalen Entfernung von 2,5 km zwischen zwei Stationen ist eine Mindestlänge von 64 Byte (14 Byte Header, 46 Byte Nutzdaten, 4 Byte CRC) vorgeschrieben."

Ich würde den Satz folgendermaßen ändern: "Bei einer maximalen Länge von 2500 Metern und vier Repeatern (nach der 802.3-Sepzifikation) ist die maximale Übertragungszeit bei 10 MBit/s im schlechtesten Fall etwa 50µs (plus der Zeit, die für den Durchlauf der Repeater benötigt wird, die nie Null ist). Ein Bit benötigt daher 100 ns für die Übertragung. Der kleinste zu übertragende Rahmen muss deshalb 500 Bit enthalten, um Kollisionen zu verhindern Um einen gewissen Spielraum für Sicherheit zu gewährleitsen, wurde dies auf 512 Bit bzw. 64 Byte aufgerundent"

-- matsbecker 11:16, 25. Jul. 2009 (CEST)

Begrifflichkeit im Bild zu Ethernet-Frames

Im Bild des Artikels, der das Ethernet-Frame darstellt, wird der kleinere Teil Ethernet-Frame und der Teil mit Präambel von Ethernet-Paket bezeichnet. Pakete werden aber nur in der Schicht 3 (Internetschicht) im TCP/IP-Referenzmodell so bezeichnet. Das Ethernet-Frame inklusive Präambel wird aber von der Netzübertragungsschicht Schicht 1-2 im OSI-Referenzmodell nach dem Ethernetstandard übertragen. Somit ist das Wort "Paket" in diesem Zusammenhang höchst wahrscheinlich unkorrekt (falsch).

Meiner Ansicht nach geht das Ethernet-Frame von Anfang bis Ende in diesem Bild, also inklusive Präambel.(nicht signierter Beitrag von 77.134.114.65 (Diskussion) 00:03, 13. Mär. 2009 (CEST))

- muss dir widersprechen, laut 802.3 standard heißt es frame und packet, so wie es im bild steht :) zum nachlesen: figure-3-1 (nicht signierter Beitrag von 80.187.104.162 (Diskussion | Beiträge) 00:31, 3. Sep. 2009 (CEST))

Korrekte Schreibweise 100BASE-TX, 10BASE2 usw.

In der Spezifikation wird BASE immer groß geschrieben. Dies ist die offizielle IEEE Schreibweise und sollte daher auch so im WIKI verwendet werden. Nach dem Base kommt direkt die Zahl (z.B. 10BASE2) bzw. ein Bindestrich, falls ein Buchstabe folgt (100BASE-TX, 100BASE-FX). Das ist leider überall falsch ("base" oder "Base")geschrieben und breitet sich somit aus - richtiger wird es dadurch jedoch nicht. Sollte mal bei der nächsten Änderung korrigiert werden. (nicht signierter Beitrag von 62.225.145.235 (Diskussion | Beiträge) 18:19, 25. Aug. 2009 (CEST))

Danke für den Hinweis. Eine Quelle dafür habe ich sogar auch schnell auftreiben können: die IEEE-Seite selbst. --Uncle Pain 10:05, 26. Aug. 2009 (CEST)

Grafik fehlerhaft?

Meiner Meinung nach ist die Grafik 'IEEE 802.3 Tagged MAC Frame' falsch dargestellt, allerdings bin ich mir nicht sicher.

Hier meine Begründung:

In der Grafik ist das Präambelfeld mit (0x)55 dargestellt, was (0b)01010101 entspricht, allerdings steht in der Standardisierung (802.3) folgendes unter 4.2.5:

The preamble pattern is: 10101010 10101010 10101010 10101010 10101010 10101010 10101010 The bits are transmitted in order, from left to right.

weiterhin steht dort unter 3.1.1:

Relative to Figure 3–1, the octets of a packet are transmitted from top to bottom, and the bits of each octet are transmitted from left to right.

es gibt also keinen Anlass aus einem Byte von 10101010 ein 01010101 zu machen!

oder irre ich? (nicht signierter Beitrag von 80.187.105.163 (Diskussion | Beiträge) 23:42, 2. Sep. 2009 (CEST))

Bitübertragungs vs. Sicherungsschicht

Unter der Überschrift "Bitübertragungsschicht" steht reichlich zu MAC-Protokoll, aber ich finde dort nichts zur Bitübertragungsschicht. Bitte die Überschrift ändern in "Sicherungsschicht" oder auch was Schreiben zur Bitübertragungsschicht... -- 90.186.20.58 17:27, 4. Sep. 2009 (CEST)

Subartikel

Bitte den Artikel in Subartikel aufteilen, da er viel zu lang ist. Bitte auf Sachlichkeit überprüfen. Text komprimieren.

Geschwindigkeit = Übertragungsrate

Geschwindigkeit hat mit der Übertragungsrate zu tun! 3 Ingenieure n streuben sich die Haare.

---

wie hängen die beiden begriffe zusammen ? Tim

---

4000Base-sx fehlt auch--Mpeg 13:51, 16. Okt. 2009 (CEST)

---

Gedrehte Kabel (Crossover)

Wie ist das eigentlichnun bei 1000Base-T: Gibt es hierfür spezielle gedrehte Kabel zum direkten verbinden zweier Netzwerkkarten oder verwendet man ein achtadriges Patchkabel und die Karten schalten automatisch auf Kreuzbetrieb? Oder ist das bei 1000Base-T überhaupt nicht vorgesehen? (nicht signierter Beitrag von 217.95.99.218 (Diskussion | Beiträge) 02:24, 27. Nov. 2009 (CET))

Wieso Layer 1

Wieso soll Ethernet zu layer 1 dazu gehören? Hier ist die ISO/OSI L1 Beschreibung "7.7.2 Purpose The Physical Layer provides the mechanical, electrical, functional and procedural means to [[activate, maintain, and de-activate]] physical-connections for bit transmission between data-link-entities"

Ethernet macht nicht von den 3 genannten Punkten. Seine Aufgaben liegen klar in Schicht 2 mit HW-Adressierung, Synchronisation und Sicherung. (nicht signierter Beitrag von 93.128.28.39 (Diskussion | Beiträge) 06:24, 10. Feb. 2010 (CET))

Ethernet ist mehr als Layer 2, was aus den Spezifikationen klar hervorgeht. Als Tip, ein wenig in diese einlesen. --Kgfleischmann 10:23, 10. Feb. 2010 (CET)

Routing / Bridging

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...) (nicht signierter Beitrag von 62.104.117.73 (Diskussion | Beiträge) 14:17, 24. Jul. 2005 (CEST))

Stacked VLANs (QinQ)

Stacked VLANs sind in Text und Grafik nicht berücksichtigt. Sollte man das ändern? (nicht signierter Beitrag von 195.227.50.6 (Diskussion | Beiträge) 13:58, 9. Mai 2006 (CEST))

-- Gerald Klix (nicht signierter Beitrag von 195.227.50.6 (Diskussion | Beiträge) 13:59, 9. Mai 2006 (CEST))

indirekte Werbung

Also nach meiner Meinung befindet sich vor allem im Absatz "»WARP-Technologie«" und "10GBase-T" ziemlich viel unterschwellige Werbung von "Schweizer Unternehmen R&M (Reichle & De-Massari)", wenn ihr auch der Meinung seit könnt ihr ja gerne mithelfen das ein bisschen zu verbessern ... --TuxJoe 16:20, 20. Jan. 2007 (CET)

Bin gerade dabei, da mich dies auch störte, denn in der USA gibt es schon viel länger mehr als drei Systeme und zwei habe ich beriets dazugefügt ! Nebenbei gesagt ist R&M nur Teilhersteller des Systems und ein Vollständiges System besteht immer aus allen geprüften Komponenten, diese gibt es im moment nur von ADC und Belden, alle anderen sind, meines Wissens, im wahren Leben noch nicht auf 100m und 625Mhz hin geprüft und abgenommen worden oder basieren auf Spezialkomponenten und nicht den üblichen Standards ! Gruß M.O. (nicht signierter Beitrag von Markus Overath (Diskussion | Beiträge) 11:58, 23. Jan. 2007 (CET))

GigE

Gigabit-Ethernet wird in dem Artikel mit dem Kürzel GigE beschrieben. Bei GigE handelt es sich jedoch um ein Schnittstellenstandard für Industriekameras: GigE vision --217.95.159.127 21:37, 31. Mär. 2010 (CEST)

Aussprache

Wieso sprechen hier in D eigentlich viele das Lemma als ˈi:θənɛt aus? Gerade wenn man es deutsch aussprechen würde, wäre ein i am Anfang nicht korrekt. Und in den englischen Wörterbüchern ist von ē'thər-nět die Rede [5] [6] —gredsc Frage/Antwort 17:03, 10. Feb. 2010 (CET)

Ah, okay... bei Merriam-Webster steht zur Symbol-Erklärung: \ ē \ as y in easy. Siehe auch die Zeile zu iː in der Tabelle unter en:Pronunciation_respelling_for_English —gredsc Frage/Antwort 12:52, 3. Jun. 2010 (CEST)

Paketgröße

Warum gibt es eine maximale Paketgröße von 1,5kB? (nicht signierter Beitrag von 141.30.204.103 (Diskussion) 00:38, 6. Jul 2010 (CEST))

Verständlichkeit

Also, ich bin weiß Gott nicht blöd, aber ich verstehe nur Bahnhof, wenn ich diesen Artikel lese. Kann es nicht auch eine Version für Normalsterbliche geben? (nicht signierter Beitrag von 128.176.188.100 (Diskussion | Beiträge) 23:46, 27. Jul 2009 (CEST))

• Ich schliesse mich diesem Vorschlag an. Es ist schade, dass Leute, die wissen wollen, für was Ethernet gebraucht wird und sich nur allgemein darüber informieren wollen, bei einem solchen Artikel keine Chance haben. Zwecks Vollständigkeit eines solchen Artikels denke ich, sollte es einen kurzen Abschnitt geben, in dem grundsätzlich erklärt wird, um was es sich bei Ethernet handelt, frei von Fachbegriffen und derartiges. (nicht signierter Beitrag von Solopiece (Diskussion | Beiträge) 00:57, 29. Aug. 2009 (CEST))

Ich finde am Anfang de Artikels wird die Grundsätzliche idee recht gut beschrieben. jedoch ist der Rest eher Unverständlich! (nicht signierter Beitrag von 141.10.91.210 (Diskussion | Beiträge) 14:25, 5. Feb. 2010 (CET))

Dem schließe ich mich an. Ist, bis auf die ersten Absätze, für interessierte Laien wirklich komplett unverständlich --Terraner87 23:10, 30. Apr. 2010 (CEST)

Der Autor/die Autorin ist sichtbar vom Fach und gibt sich sehr viel Mühe präzise zu sein, wofür ihm/ihr auch Lob gebührt, aber mir geht es ähnlich wie den anderen hier, ich verstehe nur Bahnhof, obwohl auch ich nachweislich nicht blöd bin. Auch ich wäre dahr für eine für Laien verständliche Erklärung dankbar. (nicht signierter Beitrag von 193.29.52.219 (Diskussion) 09:56, 5. Nov. 2010 (CET))

100 Gigabit Ethernet

Kann man 100 Gigabit Ethernet jetzt schon in die Spezifikationen einbauen? Wenn ja mache ich dies gerne heute noch. Greets. -- Philleb 19:32, 4. Nov. 2010 (CET)

Schwebende Schirmung - Warp Technologie - Quellen

Gibt es dazu Quellen? Die Erklärung mit der niedrigeren Kapazität zu Ground erscheint mir unschlüssig, weil sich imho auch in der Schirmung die Elektronen verschieben und die Schirmung dann einfach eine Kapazität zu Ground aufbaut. Das senkt die (Gesamt)Kapazität aber nicht sonderlich? (nicht signierter Beitrag von 84.56.97.94 (Diskussion | Beiträge) 00:22, 2. Mai 2010 (CEST))

Der Warp Absatz sieht zumindest ein wenig nach Werbung aus, in jedem Fall scheint mir der Erkenntnisgewinn zu gering / zu speziell auf ein spezielles Produkt fokussiert. Max. Link auf Artikel der den Ansatz beschreibt, ansonsten löschen würde ich denken -- 84.189.17.140 00:49, 22. Nov. 2010 (CET)

Schaubild Datenframe

Die Darstellung der Präambel im Ethernet Datenframe ist falsch. Die Präambel lautet: "10101010" entspricht AA (Hex). Der SFD lautet: "10101011" entspricht AB (Hex). --89.245.94.5 17:39, 17. Nov. 2010 (CET)

Ebenso ist das Paket und der Frame vertauscht. Der Frame ist das "Ganze", das Paket alles ab MAC Adresse. (nicht signierter Beitrag von 131.234.87.156 (Diskussion) 12:55, 25. Jan. 2011 (CET))

Schaubild Datenframe

Die Darstellung der Präambel im Ethernet Datenframe ist falsch. Die Präambel lautet: "10101010" entspricht AA (Hex). Der SFD lautet: "10101011" entspricht AB (Hex). --89.245.94.5 17:39, 17. Nov. 2010 (CET)

Ebenso ist das Paket und der Frame vertauscht. Der Frame ist das "Ganze", das Paket alles ab MAC Adresse. (nicht signierter Beitrag von 131.234.87.156 (Diskussion) 12:55, 25. Jan. 2011 (CET))

MB statt Mbit in Tabelle?

Sollte in der "Längen für Multimode-Glasfaserkabel"-Tabelle ganz unten statt 10 bzw 100MB/sec (also MByte/sec) nicht 10 bzw 100Mbit/sec stehen? (nicht signierter Beitrag von 145.64.134.242 (Diskussion) 10:20, 27. Jan. 2011 (CET))

Warum AppleTalk?

Diese Protokoll ist doch absolut irrelevant im Vergleich mit TCP/IP, warum verwendet man es also hier als Beispiel? --Chricho ¹ 17:25, 20. Jul. 2011 (CEST)

Kein Längenfeld?

Wie erkennt das Ethernet-Device die Größe des Frames, wenn es kein Längenfeld gibt? -- 81.10.203.175 11:53, 27. Aug. 2011 (CEST)

Oah meine Güte, danke für den Denkanstoß, denn deine Frage ist absolut berechtigt – mir fiel das noch nie auf.

Im Artikel wird zumindest am Rande erwähnt: „Die Werte sind größer als 0x0600 (ansonsten ist das ein Ethernet-I-frame mit Längenfeld in dieser Position).“ Wer es genauer will, muss in der englischen Wikipedia nachgucken.

Aaaber dennoch bin ich selbst auch verwirrt, denn das Ganze bedeutet letztlich, dass ich im EtherType-Feld entweder den EtherType oder die Länge drinstehen haben kann, ich kann also in einem Frame niemals beide Informationen haben. Da aber beide wichtig sind (das Längenfeld, um das Frame vom Nachfolgerframe auseinanderhalten zu können; der EtherType, um festzulegen, was mit dem Frame geschieht), bin ich etwas verwundert darüber, wie Ethernet in dieser Form eigentlich funktionieren kann. Zumal es vor dem 1997-Revision des Standards auch noch Geräte gab, die nur eines der beiden Frameformen beherrschten (nur EtherType bzw. nur Längenfeld).

Ich habe daher mal kurz Wireshark angeschmissen und mal geguckt, was eigentlich in der Praxis über die Leitung geht:

• Die größte Masse wird als Ethernet-II-Frame (also EtherType statt Längenfeld) rumgeschickt. Die wenigen anderen waren:
  • 802.2-LLC-Frames, die bei mir immer ein NetBIOS- oder ein CDP-Paket enthielten (also IP-fremde Protokolle)
  • Raw-Frames, die immer ein IPX-Paket enthielten
  • Ich konnte kein einziges 802.3-Frame finden.
• Die Ethernet-II-Frames beinhalteten zumeist IPv4/v6-Traffic, aber auch ARP und ein paar IPX-Pakete.

Ich schließe daraus mal wagemutig, dass Netzwerkhardware so funktioniert:

• Bei 802.3-Frames mit bekannter Framelänge kann das Frame korrekt eingegrenzt werden, aber dessen Inhalt ist unklar, also wird es „dumm“ an die Empfänger-MAC weitergereicht, eine Verarbeitung durch das Netzwerkgerät ist (zumindest mit trivialen Mitteln) ausgeschlossen.
• Bei Ethernet-II-Frames mit bekanntem EtherType weiß das Gerät, was der Inhalt ist und kann bspw. auf das IPv4-Längenfeld zurückgreifen, um die Framelänge abzuleiten. Nette Nebenwirkung: L3-Switches, Router etc. können durch das Wissen über den EtherType gleich auch noch weitere Infos herausziehen (IP-Adressen, QoS-Parameter etc.).

Wenn das hier jemand liest, der etwas mehr Ahnung hat, bitte klar stellen… --Uncle Pain 15:45, 29. Aug. 2011 (CEST)

Und wo ist jetzt das Problem?

Bei Werten < 1500 ist es eine Längen-Angabe und bei Werten > 1500 ist es einfach ein Typ-Angabe.

Wenn es eine Typ-Angabe hat, dann wird es über das Format erkannt und an die nächste Schicht werden alle Daten übergeben, siehe 802.3 Section 1

--MisterTS 11:36, 1. Sep. 2011 (CEST)

Danke für den Links! Der Standard stellt zwar vieles klar, doch mir leuchtet immer noch nicht ein, wie das Ethernet-Protokoll das Ende eines Frames erkennt, wenn EtherType verwendet wird. Also die nächste Schicht übernimmt das Parsen des Paketinhaltes, das auf irgendeine Weise sagen kann, wie groß das Paket ist (z. B. die Länge steht drin oder das Protokoll kennt nur eine feste Paketgröße) und mit dieser Info kann Ethernet dann Pad und FCS auslesen und checken. Wenn der Netzwerkstack aber das darüber liegende Protokoll gar nicht kennt (weil bspw. IPX oder DDP nicht auf dem System installiert sind), wie kann er dann irgendetwas über die Framelänge in Erfahrung bringen? Ethernet weiß an der Stelle nur, dass das Frame eine Mindestgröße haben muss (wegen des Paddings), aber es muss eben nicht fix 1500 Byte groß sein. Wie kann sich an so einem Punkt Ethernet überhaupt wieder unter den ganzen Bits zurechtfinden? Der Inter-Frame Gap wäre zwar eine solche Möglichkeit, andererseits dürfte der auf der Leitung doch einfach wie eine Folge von Nullen aussehen und könnte somit mit einem gleich gearteten Paketinhalt verwechselt werden…? --Uncle Pain 14:23, 1. Sep. 2011 (CEST)

Im Artikel steht's eh kurz erwähnt - ich musse es übersehen haben. Bitgenaues Signalisieren des Übertragungsendes. Im Buch "Ethernet: the definitive guide" von Charles E. Spurgeon steht außerdem eine genauere Beschreibung: Carrier Loss. Da das möglicherweise nicht ganz exakt ist, werden außerdem sogenannte Dribble Bits abgeschnitten (im Prinzip wird auf das Ergebnis nächstniedrigere Vielfache von 8 Bits abgeschnitten). Damit ist die Sache erklärt (bis auf wie ein Carrier Loss hardwaretechnisch funktioniert, aber das ist mir jetzt dann zu detailliert). Die Sache mit dem höherliegenden Protokoll halt ich nicht für sehr plausibel. Das würde ja keinen Sinn machen, wenn eine untere OSI-Schicht auf eine obere angewiesen ist. Gibt's da irgendeine Quelle dazu? -- 81.10.203.175 11:57, 18. Sep. 2011 (CEST)

Zur Vereinheitlichung der Schreibweise der Abkürzung "Cat"

Ich würde ja "Cat.x" vorziehen, aber die vorherrschende Schreibweise war "Cat-x" gemixt mit "Cat x" oder "Cat.x", also habe ich auf "Cat-x" vereinheitlicht. --Viktor 03:42, 9. Dez. 2011 (CET)

Kabellängen für Cat6 und Cat5

http://www.daetwyler-cables.com/cms/userfiles/download/wp__10gbase-t__20-01-20091.pdf

Ich denke, die zulässige Länge für CAT6 S/FTP (55m) ist falsch, die Referenz ist aus den USA und bezieht sich deshalb sicherlich auf UTP.

Die 55m Beschränkung ergibt sich durch Fremdübersprechen (Alien Crosstalk, AXT) benachbarter Kabel bei enger Bündelung über längere Strecken. Geschirmte Kabel haben praktisch null AXT. Also dürften für geschirmtes CAT6 (fast) 100m möglich sein. "Fast" deshalb, weil bei CAT6 im Verleich zu CAT6A auch andere Werte etwas schlechter sind (z.B. Dämpfung). Die Werte wurden meineswissens aber vor allem zur Vergrößerung der "Reserve" verschärft.

Was ist "Cat 6e"? Das ist nicht genormt?!. Hat das jemand so verkauft? Der Heise Artikel ist eh keine gute Referenz. "CAT6a (625 MHz)" ?? Blödsinn!
Jjeka (Diskussion) 11:16, 11. Apr. 2012 (CEST)

Es ist wohl irgendwie so:

• Da war mal ein kurzlebiger DIN(?!)-Entwurf (DIN 44312-5 Draft) für ein DIN-Cat-6 Kabel bis 600(625?)MHz, Übertragungs-Klasse E. Das war praktisch identisch mit dem heutigen Cat7, Klasse E. Es wurden wohl in Deutschland auch einige (proprietäre) Kabel mit dieser Bezeichnung von seriösen Herstellern verkauft.
• Heute dürfte es sich meistens schlicht um eine Verwechslung handeln, entweder mit 5e oder 6A oder eben jener oben erwähnten Cat6 Klasse E.
• Außerdem findet man im Internet Berichte, nachdem die Bezeichnung "6e" dazu benutzt wird, Schrottkabel an Dumme zu verkaufen.

Insgesamt ist es eher besser, 6e unerwähnt zu lassen um die allgemeine Verwirrung zum Thema nicht noch zu vergrößern.Jjeka (Diskussion) 01:54, 15. Apr. 2012 (CEST)

Für 10GBASE-T über CAT5e habe ich was mit 37m in Erinnerung. Auf jeden Fall ist das wegen AXT schirmungsabhängig. Werde mal eine Referenz suchen. Falls keine Einwände kommen, werde ich das demnächst alles ändern.

Jjeka (Diskussion) 09:11, 11. Apr. 2012 (CEST)

Außerdem hat die zulässige Leitungslänge nichts zu tun mit der Schirmung, außer in Fällen, wo Leitungen von zu niedriger Kategorie für 10GBASE-T eingesetzt werden (also das AXT-Problem bei UTP Cat5e und Cat6) Jjeka (Diskussion) 11:16, 11. Apr. 2012 (CEST)

ok, 10GBase-t läuft über Cat5e 45m

• "10G operation should work up to 50-meters over Cat 5e cabling", gemeint ist UTP: http://www.ieee802.org/3/10GBT/public/nov03/minutes_1103.pdf
• http://www.ieee802.org/3/10GBT/public/sep03/diminico_1_0903.pdf
• "45m to 100m on four pair class D" http://www.ieee802.org/3/10GBT/public/sep03/minutes_0903.pdf
• Cat5e UTP 45m http://www.bicsi.org/pdf/conferences/europe/dublin2009/presentations/Ken%20Hodge.pdf
• http://www.intertek-etlsemko.com/portal/page/cust_portal/ITK_PGR/DOCUMENTS_PROD_PG/StandardsWatch_Iss104.pdf
• Etliche Datenblätter schreiben "Cat5e up to 45 meters"
  • http://www.smc.com/files/AY/DS_SMC10GPCIe-10BT.pdf
  • https://www.aquantia.com/workspace/uploads/aq1002_pb_ver1.2-4ebcd8d7067bd.pdf
• Leute, die es selbst probiert haben: http://hardforum.com/showthread.php?t=1465401

Jjeka (Diskussion) 17:29, 13. Apr. 2012 (CEST)

Datenframe: Präambel falsch?

Jemand hatte unter der Grafik folgenden Text dazugefügt:

„Anstelle von 55│55│55│usw (Preampel) muss a│a│a│ usw. (binär 10101010)“

Rückgängig gemacht. 01010101 binär = 55 hex Jjeka (Diskussion) 20:27, 18. Apr. 2012 (CEST)

WARP-Technologie, schwebender Schirm

Das ist ein Marketing-Gag. "Schwebender Schirm" ist nix neues. Das hat man, wenn man bei einem geschirmten Kabel den Schirm isoliert (und nicht beidseitig niederohmig erdet). Die Schirmwirkung ist schwächer. Der einzige Vorteil, den ich in dem WARP-blahblah erkennen kann, ist daß durch die Unterbrechungen im Fehlerfall oder bei nachlässiger Isolierung des Schirms an den Enden keine Spannungsverschleppung stattfinden kann.

Die technischen Erläuterungen beschreiben lediglich das Prinzip der verdrillten Doppelader:

„dass Störungen, die sich auf beide Adern gemeinsam auswirken (Gleichtaktstörungen), durch die Symmetrie der Signale eliminiert werden“

Was das mit der unterbrochenen Schirmung zu tun hat, bleibt der Phantasie des Lesers überlassen.

Ich werde mal einige Referenzen zum Thema raussuchen, den Abschnitt umbenennen in "Schwebender Schirm" und WARP nebenbei mit erwähnen. Einwände, Vorschläge?
Jjeka (Diskussion) 11:01, 18. Apr. 2012 (CEST)

10 Gbit über 70-90m geschirmtes Cat5e?

Leider wird das in de,at,ch sehr verbreitete geschirmte Cat5e international kaum verwendet und wurde von der IEEE 802.3 Arbeitsgruppe ziemlich ignoriert. Man hat sich einige Gedanken über die Verwendung von Cat5 UTP für 10 Gbit/s gemacht (45m im AXT worst-case, siehe oben). Aus den vorliegenden Daten läßt sich IMHO direkt ableiten, daß bei Schirmung 70-90m möglich sind.
Ich denk mal drüber nach wie man das belegen kann, befürchte aber, jemand schreit: Keine Theoriefindung!
Ist hier jemand, der das mal ausprobieren kann?
Jjeka (Diskussion) 12:38, 18. Apr. 2012 (CEST)

Timeline fehlt ein bischen

Es wird zum Beispiel nicht darauf eingegangen, wann die verschiedenen Ethernet Standards verabschiedet wurden. Sofern google Recht hat, wurde 1 GBit im Jahr 1998 standardisiert aber so ganz sicher bin ich nicht. (nicht signierter Beitrag von 79.249.122.94 (Diskussion) 23:28, 13. Nov. 2012 (CET))

"RJ-45" vs 8P8C

Auch wenn als landläufige Bezeichnung für die 8P8C-Modularstecker "RJ-45" verwendet wird, ist diese eine spezielle Beschaltung aus der Telekommunikation, die bei Ethernet nicht verwendet wird. Das ist auch schon hier im Artikel dargestellt. -- Zac67 (Diskussion) 19:20, 11. Nov. 2013 (CET)

RJ-45 ist zwar zu allgemein, aber trotzdem nicht falsch. RJ-45 bezeichnet den Stecker- oder genauer gesagt Buchsentyp. 8P8C spezifiziert das dann genauer. Trotzdem ist die gängige Bezeichnung RJ-45. In gängigen Fachbüchern steht das zumindest so drin. --NurDieHalbeWahrheit (Diskussion) 08:21, 4. Nov. 2014 (CET)

Tatsächlich war "RJ45" die Bezeichnung (Universal Service Ordering Code) für eine Schnittstellenbuchse von Bell System u.a. für ISDN und T1. Darin waren nur die Pins 4&5 belegt und ein Brückenwiderstand auf 7&8 (Quelle) − hat mit Ethernet so ziemlich gar nichts zu tun, außer dass 10BASE-T und 100BASE-TX genau diese Pins nicht verwenden. Der richtige Name 8P8C war einfach nicht bekannt und "RJ45" blieb als Bezeichnung hängen. Zac67 (Diskussion) 13:56, 4. Nov. 2014 (CET)

Hmmm, man lernt nie aus... Das Problem scheint eher umgekehrt zu sein, als ich vorher angenommen hatte: Die Bezeichnung 8P8C sagt nichts darüber aus, wie Stecker und Buchse beschaltet sind. Da gibt es anscheinend zig Varianten, teilweise auch im RJ-Standard. Würde man sich also ein "8P8C-Kabel" bestellen, könnte es sein dass man ein Ethernet-Verbindungskabel meint, aber ein ISDN-Kabel (RJ49C) bekommt... Lange Rede, kurzer Sinn, RJ-45 mag nicht RJ-standardkonform sein, hat sich aber eingebürgert, ist (relativ) eindeutig und so verbreitet, dass ich es in der Fachinformatiker-Ausbildung so gelernt habe, es in den einschlägigen Fachbüchern zum Thema so steht und RJ-45 sogar in den Standards TIA-568A/B zumindest als "informal designation" anerkannt ist. --NurDieHalbeWahrheit (Diskussion) 08:55, 6. Nov. 2014 (CET)

P.S. Deine Quelle sagt überhaupt nichts über RJ45 aus, nur über RJ45S. Dass DAS nicht für Ethernet benutzt wird, steht ausser Frage. Mit RJ45 hat das aber nichts zu tun... -- NurDieHalbeWahrheit (Diskussion) 08:24, 26. Nov. 2014 (CET)

Alohanet-Zeitangabe variiert um 10a

Die Zeitangabe für das CSMA/CD-Protokoll im ALOHA-net stimmt nicht mit der Angabe in ALOHA überein (1960er vs. 1970/71 erstmals eingesetzt). --139.30.145.225 10:56, 14. Jul. 2015 (CEST)

Danke für den Hinweis - ALOHAnet fing 1971 an. --Zac67 (Diskussion) 20:56, 14. Jul. 2015 (CEST)

Wenn man so absolut gar keine Ahnung vom Thema hat, dann sollte man hier nicht schreiben!

Hier steht: "Switches (manchmal auch laienhaft als Switching Hubs bezeichnet)". Was soll daran laienhaft sein?! Bei Switch steht: "Der Begriff Switch bezieht sich allgemein auf eine Multiport-Bridge – ein aktives Netzwerkgerät, das Frames anhand von Informationen aus dem Data Link Layer (Layer 2) des OSI-Modells weiterleitet. Manchmal werden auch die korrekteren Bezeichnungen Bridging Hub oder Switching Hub verwendet, im IEEE 802.3-Standard heißt die Funktion MAC Bridge. Der erste „EtherSwitch“ wurde im Jahr 1990 von Kalpana eingeführt. „Switch“ stammt eigentlich aus der leitungsvermittelnden Technik und gibt nicht die Funktion des Geräts wieder."

Korrigiert den Blödsinn mal! (nicht signierter Beitrag von 91.53.150.216 (Diskussion) 12:22, 15. Feb. 2016 (CET))

Vielen Dank für den Hinweis - "Hub" für einen Multiport-Repeater ist zwar weit verbreitet aber nicht wirklich präzise. --Zac67 (Diskussion) 18:59, 15. Feb. 2016 (CET)

Ader-Farben

Hier gibt es schöne Bilder für die Tabelle --Markus (Diskussion) 08:49, 25. Mai 2016 (CEST)

Stecker: RJ-45 vs. 8P8C

Physisch sind die Steckverbindungen als 8P8C-Modularstecker und -buchsen ausgeführt, 
die häufig auch falsch als „RJ-45“- bzw. „RJ45“-Stecker/-Buchsen bezeichnet werden. 

Was ist der Unterschied? woran zu erkennen? auch in den Artikeln Patchkabel, LAN, Kabelkonfektion, Twisted-Pair...

Es fehlt auch ein Abschnitt wie und mit welchen Werkzeugen Stecker und Kabel verbunden werden. Gruss, --Markus (Diskussion) 08:55, 25. Mai 2016 (CEST)

Es gibt keinen Unterschied – 8P8C wird üblicherweise "RJ-45" genannt, ohne dass diese Bezeichnung irgendwann einmal definiert worden wäre, vgl. en:Registered jack#Unofficial plug names – deshalb "falsch". In keinem offiziellen Standard werden Stecker oder Buchse so bezeichnet. RJ45S war mal die Übergabebuchse für T1 und ähnlich, es wurde dann wohl angenommen, der Stecker selbst heißt RJ-45.

Konfektionierung von TP usw. gehört eher zum Kabel, Ethernet verwendet außer TP ja auch noch diverse andere Kabeltypen (Coax, Twinax, Glasfaser, ...). --Zac67 (Diskussion) 11:53, 25. Mai 2016 (CEST)

Neue 2,5 gbit und 5 gbit Standards fehlen in Tabelle Kabellängen Kupfer twisted pair

2,5 gbit mit Stufe 5e sind 100 m sicher möglich. 5 gbit mit Stufe 6 sind 100 m ebenfalls sicher möglich.

Nur neue Karten und Switches nötig für real 2 bis 4 fache Performance mit bestehender Verkabelung. (nicht signierter Beitrag von 2A02:810B:C53F:B9E8:81:8BA1:49F5:5CFF (Diskussion | Beiträge) 15:49, 2. Dez. 2016 (CET))

CSMA/CD-Algorithmus unter Bitübertragungsschicht

Der Medienzugriff mittels CSMA/CD wird in der MAC Schicht geregelt, welcher gemäss Definition aber Teil der Sicherungsschicht ist. Die Einordnung des CSMA/CD Algorithmus ist unter der Überschift Bitübertragungsschicht ist also nicht korrekt bzw. irreführend.

CSMA/CD hat Komponenten im Physical Layer und im MAC Layer. Die wesentlichen Teile Carrier Sense und Collision Detection finden sich dabei im PLS, der noch zum Physical Layer zählt. Die Steuerung bzw. der Algorithmus ist tatsächlich im MAC Layer abgebildet, da dieser auch den Datenstrom steuert. M. E. ist es aber aus Gründen der besseren Verständlichkeit besser, das im PL zu lassen. Da auch der zweite Unterabschnitt Broadcast und Sicherheit nun gar nicht zum PL gehört: wie wäre es damit, den Abschnitt Bitübertragungsschicht in Übersicht umzubenennen? --Zac67 (Diskussion) 17:17, 21. Mai 2018 (CEST)

Der Algorithmus an sich ist IMHO im MAC Layer. Klar, die Statussignal kommen aus dem physical layer. Allgemein ist es wohl nicht umbedingt förderlich im Ethernet-Kontext zu fest auf ISO/OSI zu referenzieren, weil diese Einordnung ja Geschichtlich erst nachträglich geschah. Bitübertragungsschicht in Übersicht umzubenenne sehe ich als sinnvolle Lösung.

Der anschliessende Abschnitt Verbesserungen gehört imho auch eher in einen Abschnitt Übersicht, der Abschnitt Switching uberschneidet sich in grossen Teilen mit Broadcast und Sicherheit und könnte mit diesem zu einem Abschnitt verbunden werden.--Jarobrok (Diskussion) 11:09, 22. Mai 2018 (CEST)

Abschnitt über WARP Technologie sollte entfernt werden

Hier handelt es sich nicht um einen wesentlichen Aspekt der Ethernet-Technologie oder der Ethernet Historie. Auch andere Hersteller haben erfolgreich Kabel abgeschirmt. Sachlich könnte dieses Thema unter einem Stichwort "Signalübertragungskabel" oder so ähnlich einen Platz finden. ABer diese Information kann als irrelevant auch ruhig ganz verschwinden. Das Stichwort WARP findet sich auch folgerichtig nicht in der EN-Version von Ethernet. Dieser Abschnitt ist eindeutig eine Firmenwerbung. HH1946 (Diskussion) 12:51, 7. Aug. 2018 (CEST)

Zustimmung Sehe ich ähnlich – der Artikel hat ja nicht den Titel Kabeltechnologie, bei dem das evtl. relevant wäre. --Zac67 (Diskussion) 16:51, 7. Aug. 2018 (CEST)

Sehe ich genauso. Es entspricht keinem speziellen Standard und sollte deshalb raus. Ich würde es als nicht Relevant entfernen. --GodeNehler (Diskussion) 17:07, 7. Aug. 2018 (CEST)

Etymologie, unklare Formulierung

Dieser Satz ist leider nicht hilfreich. Was hat Aloha mit Ether zu tun?:"Er leitete das Protokoll von dem an der Universität von Hawaii entwickelten funkbasierten ALOHAnet ab. Daher auch der Name Ether-net (englisch für „Äther“, der nach historischen Annahmen das Medium zur Ausbreitung von (elektromagnetischen) Wellen wäre)." 2A02:3031:0:F988:1:2:EF84:3B4C 07:15, 11. Apr. 2022 (CEST)

Danke für den Hinweis, das erschließt sich wirklich nicht so leicht – ich habe es etwas klarer gemacht. --Zac67 (Diskussion) 08:26, 11. Apr. 2022 (CEST)

Aus dem Funk leitet sich der Name Ether-net ab (englisch für „Äther“, der nach historischen Annahmen das Medium zur Ausbreitung von (elektromagnetischen) Wellen wäre).

International ist Äther ein Synonym f. Funk wie Radio, doch leitet sich Ether nicht vom deutschen Wort Funk ab. Ich ändere das.

Details:

engl. Original(be)zechnungen mit Ethernet, Telephone Ether und Radio Ether.

.http://www.netzmafia.de/skripten/netze/netz4.html#4.1

http://www.ethermanage.com/ethernet/ethername.html

Das erste experimentelle Netzwerk von Metcalfe wurde Alto Aloha Network genannt. 1973 änderte Metcalfe den Namen in "Ethernet", um klarzustellen, dass das System jeden Computer unterstützen konnte - nicht nur Altos - und um darauf hinzuweisen, dass seine neuen Netzwerkmechanismen weit über das Aloha-System hinaus entwickelt worden waren. Er wählte den Namen in Anlehnung an das Wort "Äther", um ein wesentliches Merkmal des Systems zu beschreiben: Das physikalische Medium (d. h. ein Kabel) überträgt Bits zu allen Stationen, ähnlich wie der alte "Lichtäther", von dem man einst annahm, dass er elektromagnetische Wellen durch den Raum verbreitet. So wurde das Ethernet geboren. --217.229.56.39 02:54, 28. Nov. 2022 (CET)

Lasst doch das Äthergeschwurbel weg, das AlohaMet hatte eine Telephon- und einige Funkstrecken.

Auch amerikanische Funker meinen mit Ether einfach nur Radio, da ist absolut keine Wissenschaftsmystik dahunter. --217.229.56.39 03:46, 28. Nov. 2022 (CET)