Hi,
Ich wollte mal fragen wie es mit dem verschicken von Paketen von einem Rechner ins andere Funktioniert?Ich erkläre es mal wie ich es verstanden habe.
Jeder Rechner bzw. die Netzwekkarte hat eine Hadwareadresse.
Wenn ein Paket(z.b. eine Textdatei)verschickt werden soll,undzwar von einer Netztwerk-Karte zum anderen,bekommt sie einen Rahmen-Header wo die Quell- und Zieladresse geschrieben steht.Die ARP(bei TCP/IP) "übersetzt" die Hardwareadresse so das der Router weiß zuwelchen IP-Adresse dieses Paket gehört.Nachdem die IP-Adresse der Rechenanlage ausfündig gemacht wurde, fügt IP seinen Header and die Datei und sendet es zum Router der es zum Rechenanlage weiterleitet.
Ich weiß nicht ob ich den zusammenhang so richtig verstanden habe oder nicht.Ich habe problem die Hardwareadresse und IP-Adresse im bezug auf das verschicken von Dateien in verbindung zu bringen.Deswegen bitte ich um Hieeelllllllfe.
Danke im voraus.
ich würde es eher andersrum beschreiben,
(die Netzwerkkarte weiss sowieso von gar nix),
die Anwendung, die eine Datei verschicken möchte,
kennt vom Ziel höchstens die IP-Adresse (oder gleichwertig den symbolischen Namen
www.tralala.de")
und dazu noch Port usw.,
das ist die Zieladresse die im Header steht (IP-Schicht von mir aus)
diese IP-Adresse wird vor dem Senden herausgefunden mit dem AR-Protokoll
Hardwareadressen benötigt man auf jedem Teilstück,
zum Anfang also muss ein Paket an den nächsten Vermittlungsrechner geschickt werden,
dessen Hardwareadresse ist also im Sendesystem bekannt,
die Hardwareadresse des Zielrechners interessiert nur den letzten Vermittlungsrechner auf dem langen Weg
bei jedem Versenden des Pakets von einem Vermittlungsrechner zum nächsten
bleiben die Absende- und Zieladresse auf IP-Ebene gleich,
sie beziehen sich ja auch Start- und Zielrechner
die Hardwareadressen für die aktuelle Übertragung sind dagegen immer anders,
da jeweils ein anderer Vermittlungsrechner angesteuert wird
(soweit wie ich mir das denke, kann genauso falsch sein ;) )
das ist die Zieladresse die im Header steht (IP-Schicht von mir aus)
diese IP-Adresse wird vor dem Senden herausgefunden mit dem AR-Protokoll
Mit diesem Teil bin ich noch nicht so ganz einverstanden. Der Netzwerkkartentreiber weiss, dass hier IP auf Ethernet gefahren wird und schickt eine ARP-Anfrage raus, wer die Ziel-IP hat. Dies muss nicht die endgueltige Ziel-IP (destination) des Pakets sein, sondern ist in vielen Faellen ein Gateway-Rechner, der ja in der Netzwerkkonfiguration des Rechners hinterlegt ist und genau dann zum Einsatz kommt, wenn die endgueltige Ziel-IP nicht im selben Subnetz zu finden ist.
D.h. mein Rechner im Bursen-Subnetz (10.80.165.1) sieht, das Paket soll in ein anderes Subnetz (134.100.x.x), also laesst er die Netzwerkkarte ein ARP-request nach dem GATEWAY-RECHNER machen (who has 10.80.0.2 (unser Gateway)) und bekommt eine MAC-Adresse zurueck, so eine 48-bit-Adresse.
An die wird das Ethernet-Frame dann geschickt; wie es genau gebaut ist, um als Bitte-Weiterleiten-Paket erkennbar zu sein, weiss ich nicht – evtl weiss unser Gateway nur, dass das Paket weitergeleitet werden soll, weil es das Paket bekommt und sich seiner Routingaufgaben bewusst ist.
Wie schon Slater schrieb, hat erst das letzte Gateway (im selben Subnetz wie der Paketempfaenger) ueberhaupt etwas mit der Hardware-(MAC-)Adresse (edit: des Empfaengers!) zu tun.
(Auch alles nur AFAIR :-)
Jupp. Der Router packt den Ethernet-Rahmen aus, sieht: "Hey, ein IP-Packet!", übergibt es an den IP-Stack, der merkt das die Ziel-IP nicht der Router-IP entspricht, packt wieder einen Rahmen drumrum (ob Ethernet oder ppp oder sonstwas) und schickt es an den nächsten Hop.
Auch ohne Gewähr, sollte aber hinkommen wenn mein ProSeminars-Vortrag nicht völlig daneben war. [img]
http://www.fb18.de/gfx/25.gif[/img]
Jupp. Der Router packt den Ethernet-Rahmen aus, sieht: "Hey, ein IP-Packet!", übergibt es an den IP-Stack, der merkt das die Ziel-IP nicht der Router-IP entspricht, packt wieder einen Rahmen drumrum (ob Ethernet oder ppp oder sonstwas) und schickt es an den nächsten Hop.
Auch ohne Gewähr, sollte aber hinkommen wenn mein ProSeminars-Vortrag nicht völlig daneben war. [img]http://www.fb18.de/gfx/25.gif[/img]
add: Normalerweise wird der Rahmen noch weiter entkleidet, aber für eine generelle Funktinalität reicht der IP-Header aus. Da viele Router aber auch Packet-Screening (so heißt das glaub ich laut Brunni [img]
http://www.fb18.de/gfx/15.gif[/img] ) machen, wird auch gern die IP-Schale abgepult, um z.B. wie beim Masquerading die Ports zu ändern. Einige (Hardware-)Router arbeiten sogar auf Anwendungsebene, d.h. sie nehmen z.T. Aufgaben wahr, die in meinen Augen eigentlich Proxies erledigen (z.B. Authentification, Validierung auf Protokoll-Konformheit, …).
Routing mag zwar eine relativ unkomplexe Angelegenheit sein, aber sorgt dank der schieren Menge an weiterzuleitenden Paketen/Frames für eine nennenswerte Rechenlast. Bei voller Auslastung meiner 5MBit/s DSL ist mein Linuxrouter (900MHz AMD) durchschnittlich zu 8% ausgelastet.
IP Endstelle
1. Applikation stellt Anfrage an den IP-Stack eine Verbindung mit Ziel-IP aufzubauen.
2. IP-Stack ummantelt die Daten mit Absender und Zieladresse und verarbytet das Paket nach Routinginformationen weiter.
3. Die Ziel IP wird abgeglichen mit den einzelnen Subnetzen, hier gibt es 2 Moeglichkeiten:
3.1.: Das Paket wird aufs Interface geschoben, das zum passenden Subnetz gehoert. (Damit ist fuer den IP-Stack das Paket weg, und angekommen.)
3.2.: Das Subnetz laeuft ueber einen Gateway. Hier wird das Paket nochmal eingepackt in ein Paket, das an den Gateway geht, und dann gehts nochmal bei 3. los.
–
Diese Interfaces koennen verschiedenster Art sein.:
Es gibt IP-Interfaces: PPP, SLIP, IP-VPNs (tun-ifs), lo, etc.
Es gibt Ethernet-Interfaces.: ETH-VPNs(tap-ifs), Karten…
Weitere: PPPoE…
–
IP Routing (Gateway)
Bekommt ein Gateway ein "Gateway Paket", so wird das auseinandergebastelt, und entsprechend der originalen Absender und Empfaengerinformationen weitervermittelt. Dies geschieht wie bei einer IP Endstelle (s.o.).
Bei NAT werden dazu auch noch Informationen im Router selbst gehalten, und die Absenderadresse durch die Adresse des Routers ersetzt. Bei Paketen in die Rueckrichtung kann durch die gehaltenen Informationen die Verbindung zu einem bestimmten Rechner zugeordnet werden.
–
Ethernet Endstelle.
Sollte ein Interface, auf dem eine IP-Endstelle ein IP Paket rausgeben moechte, ein Ethernet-Device sein, so kommt folgendes zum Einsatz:
1. Es wird in der ARP-Tabelle des Netzwerksystems nachgesehen, ob die der IP entsprechenden MAC schon bekannt ist.
(Die MAC-Adresse ist die "Hardwareadresse" des Ethernet-Devices).
Wenn ja, dann geht es weiter bei 5.
2. Auf dem Ethernet Device wird ein ARP-WhoHas gebroadcastet.
Das ist ein Paket, das die Ziel-IP beinhaltet, und die Absender-MAC.
3. Dieses Paket muss (prinzipiell, nach Abstraktion) nicht geroutet werden, da das Ethernet ein Bussystem darstellt.
4. Der Rechner, dem die angefragte IP gehoert, schickt ein Ethernet-Antwort-Frame zurueck, indem er sich als eigner der entsprechenden IP kenntlich zeigt, und der Ziel-IP und Ziel-MAC miteinander Assoziiert. Wenn dieser Frame bei dem Rechner ankommt, der das IP-Paket senden will, so wird diese Assoziation in die ARP-Tabelle eingetragen (Unter Linux kann man sich diese Tabelle unter /proc/net/arp ansehen.)
5. Das zu sendende IP-Paket wird in einem Ethernet-Frame verpackt, dessen Ziel-MAC der Ziel-IP laut ARP-Tabelle entspricht. Dieser Ethernet-Frame wird dann auf das entsprechende Ethernet-Device rausgegeben. Damit ist das sendende System fertig.
–
Ethernet Routing.
Ethernet braucht, wie oben schon einmal kurz erwaehnt, aufgrund seiner Busstruktur nicht geroutet zu werden. Entweder hat ein Frame eine Ziel-MAC, die am Bus haengt, dann kommt das Paket an, oder die Ziel-MAC haengt nicht am Bus, dann kommt das Paket auch nicht an.
Bei 100MBit/s Netzwerken mit Twisted-Pair Kabeln werden allerdings normalerweise keine HUBs (Bus - Verteiler) mehr benutzt, sondern Switches.
Die Switches lesen bei vorbeikommenden Ethernet-Frames die Absender-Adressen aus, und merken sich, an welcher Buchse diese Adresse haengt.
Ein Frame, der weitergeleitet werden soll, wird nun nur an die Buchse weitergeleitet, an der auch die entsprechende MAC zu finden ist. Sollte die MAC noch nicht bekannt sein, so wird das Paket gebroadcastet (Der Switch agiert wie der HUB). Daher kommt die bekannte "Lernzeit" eines Switches.
Die angehaengten End-Systeme braucht es nicht zu interessieren, ob sie ueber HUBs oder Switches verbunden sind, da ihre Leitung auf dieselbe Art und Weise bedient wird.
So organisieren sich verswitchte Ethernet-Netzwerke selbst.
MoKrates
Besitzt ein Ethernet-Switch eigentlich eine eigene Ethernet-Adresse?
Besitzt ein Ethernet-Switch eigentlich eine eigene Ethernet-Adresse?
In der Regel nein, denn die Dinger sollen vollstaendig transparent arbeiten und nur jedem Anschluss zu einer eigenen Kollisionsdomaene verhelfen, aber selbst nicht in Erscheinung treten. Es sind ja keine Router, die selbst zwecks Paketvermittlung angesprochen werden sollen.
Ausnahme natuerlich die teuren/featurereichen Switches, die sogar eine IP haben (zum Administrieren per Webinterface und/oder Telnet) und damit dann wohl auch eine MAC-Adresse.
