Diskussion:Ethernet

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

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)

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)

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)

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.

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

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

• Das Bild ist IMO falsch, die Präambel zählt nicht mit in die Paketlänge. Der Pfeil sollte gekürzt werden.

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)

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)

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