Hallo zusammen, in der Berufsschule behandeln wir gerade das Thema Segmentierung von Netzen. Unser Lehrer gibt uns ein Arbeitsblatt, auf dem die Vorteile von Subnetting aufgelistet sind. Die wären: Übersichtlich (Netzwerkdokumentation) Sicherheit (Personalabteilung , Entwicklung) abgeschlossene Segmente (Produktion , Administration/Entwicklung) geringere Kollisionsgefahr (Geschwindigkeitsvorteil) Leider kann ich die Punkte nicht nachvollziehen. Ob ein Netzwerk übersichtlich oder sicher ist, hängt doch nicht davon ab, ob ich es segmentiere. Auch die anderen beiden Punkte sind m. E. aus der Luft gegriffen. Der Punkt Abgeschlossene Segmente gehört doch zur Übersicht und die Kollisionsgefahr kann doch innerhalb eines Segmentes trotzdem sehr hoch sein jenachdem, welche Standards dort verbaut sind. Was sind denn die tatsächlichen Gründe, warum man ein Netz segmentiert? Guten Tag.
Segmentierung ist auch ein Relikt aus Urzeiten wo noch mehr als zwei Hosts in einer Layer2 Broadcast Domäne waren. Seit dem man Switches in Ethernets einsetzt, hat man eh eine Segmentierung auf zwei Hosts pro Segment, da gibt es ja keine Kollisionen mehr. Sicherheitsgewinn hat man höchstens durch konsequente Firewall-Regeln. Als nächstes macht ihr wahrscheinlich IP-Adress-Klassen, CIDR... Steht IPv6 auch auf dem Lehrplan?
Torben schrieb: > Der > Punkt Abgeschlossene Segmente gehört doch zur Übersicht Nein. Du kannst ja an den Netzübergängen den Datenverkehr beeinflussen (Firewall), und damit verhindern, dass x-beliebige Teilnehmer Zugriff auf bestimmte Bereiche bekommen, oder aber verhindern, dass die Leute in der Produktion „surfen“, während die Entwicklung ganz gewiss vollen Zugriff auf das Internet braucht. Das würde ohne Unterteilung nicht machbar sein. Seit 802.1q muss das dabei nicht einmal mehr in allen Fällen physisch unterteilt werden: ein physisches Netzwerkinterface am Firewall kann da durchaus mehrere verschiedene Netze verwalten; die Aufteilung auf die Zugangspunkte („Steckdosen“) erfolgt dann im Switch. > und die > Kollisionsgefahr kann doch innerhalb eines Segmentes trotzdem sehr hoch > sein jenachdem, welche Standards dort verbaut sind. Natürlich kann man immer pathologische Fälle bauen – aber ohne Unterteilung ist sie zwangsweise auf jeden Fall höher. Seit Netze nicht mehr nur durch dumme Repeater verbunden werden sondern durch Switche, reduziert sich zwar die Kollisionsgefahr insgesamt, aber insbesondere in Umgebungen mit vielen Broadcasts reduziert eine Unterteilung das „Geblubber“.
Der Begriff "Segmentierung" bezieht sich heute oft auf durch Firewalls abgetrennte Netzbereiche. Was nicht zwangsläufig eine Trennung auf Layer 3+ bedeutet, also auf Routing-Ebene, denn man kann eine Firewall auch auf Layer 2 betreiben - auf beiden Seiten der Firewall hat man dann das gleiche IP-Netz.
:
Bearbeitet durch User
Torben schrieb: > Leider kann ich die Punkte nicht nachvollziehen. Ob ein Netzwerk > übersichtlich oder sicher ist, hängt doch nicht davon ab, ob ich es > segmentiere. Die Segmentierung macht aber die Dokumentation schon einfacher. Wenn Du weißt das dieses Netzsegment mit jenen IPs nur für die Entwicklung ist, dort nur folgende Server drin erreichbar sind etc. ist es klarer und eindeutiger, als wenn das mit anderen Abteilungen vermischt und hinterher nur auf der Firewall in vielen vielen Regeln erkennbar ist. Durch die Segmentierung wird die Dokumentation einfacher, übersichtlicher und schneller verständlich. Du musst dabei auch nicht nur Dich selbst oder Deine Kollegen im Blick haben, sondern auch z.B. andere Firmen und deren Mitarbeiter. Sagen wir mal eine andere Firma ist für die TK-Anlage, die Drucker, die Wawi oder wasauchimmer zuständig, Du musst denen erklären wie das Netz aufgebaut ist und wo und wie die ihren Kram einzurichten haben. Desto einfacher und schneller das verständlich ist, desto schneller verstehen die das, desto weniger Ärger hast Du mit denen und desto weniger Fehler passieren durch Unwissen oder Verständnisschwierigkeiten.
Habe ich das richtig verstanden? Man segmentiert u. a. ein Netz, damit die Teilnehmer des einen Netzes nicht auf die Netzwerkressourcen des anderen Netzes zugreifen können?
> Man segmentiert
Ja, da werden die Segmente dann aber zu (IP-)Subnetzen und man
platziert dann auch eine Firewall dazwischen.
Ich habe schon Netze mit 1700 Geräten in einer Broadcastdomäne
gesehen. Probleme bekommen da nur die, die noch mit 10 Mbit
da mitreden wollen. Wenn ein mit 10 Gbit angeschlossenes Gerät
mal etwas "länger" Broadcasts sendet, kommen die bei den
mit 10 Mbit angeschlossenen nicht mehr vollständig an.
Wie man sieht, muss man die Segmentierung also nicht übertreiben.
Unicastpakete werden von den Switchen Punkt-zu-Punkt geswitcht.
Ob mit vielen Segmenten oder ohne...
Fehlanzeige schrieb: > Ja, da werden die Segmente dann aber zu (IP-)Subnetzen und man > platziert dann auch eine Firewall dazwischen. Ich habe folgende These aufgestellt: Man segmentiert u. a. ein Netz, damit die Teilnehmer des einen Netzes nicht auf die Netzwerkressourcen des anderen Netzes zugreifen können. Mein Lehrer sagt nun außerdem, dass eine Subnetzbildung ohne Router nicht möglich ist. Ein Router ist doch aber dafür da, Pakete aus dem einen Netz in ein anderes weiterzuleiten. Demzufolge können doch Benutzer des einen Netzes Pakete in ein anderes Subnetz schicken, wenn man mal den Aspekt der Firewall vernachlässigt. Wo ist dann der Vorteil von Subnetting?
Torben schrieb: > Mein Lehrer sagt nun außerdem, dass eine Subnetzbildung ohne Router > nicht möglich ist. Wenn auf jegliche Kommunikation nach außerhalb des Subnetzes verzichtest geht das auch. > Ein Router ist doch aber dafür da, Pakete aus dem einen Netz in ein > anderes weiterzuleiten. Demzufolge können doch Benutzer des einen Netzes > Pakete in ein anderes Subnetz schicken, wenn man mal den Aspekt der > Firewall vernachlässigt. > > Wo ist dann der Vorteil von Subnetting? Eigene Broadcast-Domäne unter anderem
Torben schrieb: > Mein Lehrer sagt nun außerdem, dass eine Subnetzbildung ohne Router > nicht möglich ist. Wobei ein Layer 3 Switch in diesem Sinn ein Router ist. Allerdings muss Subnetzbildung nichts mit Segmentierung zu tun haben. > Wo ist dann der Vorteil von Subnetting? Wenn einem Unternehmen im Internet ein IP-Bereich 1.2.3.4/23 zugeordnet ist, dann kann dieses Unternehmen daraus mehrere Subnetze für verschiedene Aufgaben bauen, muss nicht alle 500 Server ins gleiche Netz packen. Ebenso müssen intern nicht alle 5000 PCs und Server ins gleiche 10.0.0.0/8, sondern es können viele 10.0.0.0/24 Netze genutzt werden. Abteilungen, Stockwerke, Standorte, Funktionen, ...
Torben schrieb: > Mein Lehrer sagt nun außerdem, dass eine Subnetzbildung ohne Router > nicht möglich ist. Richtig. > Ein Router ist doch aber dafür da, Pakete aus dem einen Netz in ein > anderes weiterzuleiten. Ja – da ist kein Unterschied zur vorherigen Aussage. Beides ist exakt das gleiche. > Demzufolge können doch Benutzer des einen Netzes > Pakete in ein anderes Subnetz schicken, wenn man mal den Aspekt der > Firewall vernachlässigt. Den kannst du 1.) nicht vernachlässigen, und 2.) ignorierst du nach wie vor das Detail der broadcast domain, die durch die Unterteilung eingeschränkt wird. > Wo ist dann der Vorteil von Subnetting? Du theoretisierst unnütz herum. Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne: es gibt einfach IP-Netzwerke, bestehend aus Netzerkadresse und Netzmaske. Das Wort "Sub" stammt aus der Zeit der klassenbehafteten Netze, als man das Internet noch so schön als Klasse A, B oder C eingeteilt hat. Innerhalb dieser Klassen war es dann vor allem bei A und B üblich, "Subnetze" einzuteilen, wobei im ursprünglichen Ansatz noch die Netzmaske aller Subnetze gleich war. Heutzutage reichen die öffentlichen IP(v4)-Adressen sowieso nicht mehr, um alle am Internet hängenden Geräte zu adressieren. Mit RFC1918 wurden spezielle Netzbereiche reserviert, die nur intern benutzt werden und im Internet nicht geroutet werden sollen. Wenn du also heute irgendein Netzwerk aufbaust, vergibst du in 99 % der Fälle sowieso nur Adressen aus diesen Bereichen. Dabei legst du die Netzwerke so an, wie sie administrativ oder organisatorisch zusammen gehören, überlegst dir, wer vorrangig mit wem kommunizieren soll. Wenn dabei mehrere Netze entstehen, laufen die in der Regel dann sowieso gemeinsam auf dem Firewall auf, der zugleich zwischen den Netzen routet.
Jörg W. schrieb: > Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne: Subnetting wäre beispielsweise, wenn ein Konzern die gesamte interne Netzstruktur vereinheitlicht und für jedes halbwegs autonom arbeitende Tochterunternehmen U ein Netz 10.U.x.x/16 definiert. Ein solches Tochterunternehmen 17 kann dann wiederum diverse Netze 10.17.N.x/24 verwenden. Die Realität ist wohl eher ein Sammelsurium überlappender Netze, weil zusammengekaufte Unternehmen das vorher jeweils nach Laune definierten und man damit erst einmal leben muss. Im Ergebnis ist konzernweite Kommunikation dann eine üble NAT-Orgie. > Internet noch so schön als Klasse A, B oder C eingeteilt hat. Wobei ich bei diesem Beispiel nur deshalb eine Klassen-artige Aufteilung verwende, weil es andernfalls in dezimaler IP-Schreibweise beschissen aussieht.
:
Bearbeitet durch User
Mitarbeiter schrieb: > Als nächstes macht ihr wahrscheinlich IP-Adress-Klassen, CIDR... > Steht IPv6 auch auf dem Lehrplan? Lol!!! Von CIDR oder Auto-MDIX hatten die bei uns noch nicht mal was gehört! Am Ende gab es noch einen Lehrgang zu ISDN, absolute Zukunftstechnologie! Glücklicherweise haben die den Dreck direkt in meine Prüfungswoche gelegt, sodass mir das erspart blieb.
So wie es aussieht machen wir auch kein ipv6 :)
Torben schrieb: > So wie es aussieht machen wir auch kein ipv6 :) Schlecht. Sowas sollte man in heutiger Zeit natürlich auf jeden Fall schon mal gehört haben. Ist eigentlich auch nicht wirklich schlimm: die Adressen sind halt 128 Bit statt 32 Bit breit, oder 16 statt 4 Byte. Damit die Adresse noch lesbar bleibt, wird sie nicht dezimal byteweise (wie bei IPv4) sondern hexadezimal 2-byte-weise aufgeschrieben, also 8 Gruppen zu je 2 Byte (4 Hexadezimalstellen), getrennt durch Doppelpunkte. Prinzipiell könnte man natürlich auch IPv4-Adressen hexadezimal schreiben, also statt 192.168.1.2 c0.a8.1.2. Das ist nur nicht üblich. Eine typische IPv6-Adresse sieht dann so aus:
1 | 2a01:db8:4a5:33f2:a021:3301:4a:2f03 |
Innerhalb der Viergruppen werden führende Nullen weggelassen, also db8 ist die Kurzform für 0db8, 4a steht für 004a. Blöcke, die komplett zusammenhängend aus Nullen bestehen, können weggelassen werden:
1 | 2a01:db8:4a5:33f2::1 |
Ist also die Kurzform für
1 | 2a01:db8:4a5:33f2:0:0:0:1 |
Das ist besonders bei fest vergebenen Serveradressen üblich. Die Netzmaske wird wie bei CIDR mit einem Schrägstrich angehängt, wobei ein /64 die kleinste übliche Maske ist (also 2^64 Bits für die Hosts im Netz). "Nach oben" können dann mehrere solche /64-Blöcke zusammengefasst werden, meist in 8er Schritten. Du bekommst also von deinem Provider typischerweise eine /56-Zuweisung, das sind 256 Netze zu je /64. Dein Provider wiederum fasst 256 solcher Blöcke zu einem /48 zusammen etc. Damit man die Doppelpunkte der Adresse von anderen Doppelpunkten (Portnummer) unterscheiden kann, werden in URLs die IPv6-Adressen in eckige Klammern gesetzt:
1 | http://[2a01:db8:4a5:33f2:0:0:0:1]:8080/ |
bezeichnet damit einen HTTP-Server, der auf der genannten Beispieladresse auf Port 8080 (der ist dann wieder dezimal) hört. Hier mal ein reales Beispiel. :-)
1 | http://[2a00:1450:4001:815::2003]/ |
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ist eigentlich auch nicht wirklich schlimm: die Adressen sind halt 128 > Bit statt 32 Bit breit, oder 16 statt 4 Byte. Wobei das nur der offensichtlichste Unterschied ist. Wenn man sowas Einrichten will, wird man merken, dass da mehr als eine Zahl hintersteckt :)
ip6tables -I OUTPUT -j DROP Und schon ist man das widerliche Zeug los.
Fehlanzeige schrieb: > Und schon ist man das widerliche Zeug los. Vogel-Strauß-Mentalität? Kann man machen. Wenn man kurz vor der Rente ist, und eine „Nach-mir-die-Sintflut“-Politik ansetzt. Der TE scheint jedoch in der Ausbildung zu sein, dann ist so eine Variante kaum zielführend.
> kurz vor der Rente ist
Das ist die Default-Policy aller Unternehmen die mir bis jetzt
untergekommen sind!
Denk mal drüber nach.
Fehlanzeige schrieb: >> kurz vor der Rente ist > > Das ist die Default-Policy aller Unternehmen die mir bis jetzt > untergekommen sind! Nur, weil alle Unternehmen, die dir bislang untergekommen sind, offenbar unfähige (oder unwillige) Admins haben, macht das die Sache kaum besser. Übrigens: angenehmer Nebeneffekt des großen Adressraums: Portscans gibt es praktisch nicht mehr. Auf meinen IPv6-only Servern vermisse ich (nicht :) die vielen dümmlichen Port-22-Scan-Versuche – obwohl diese Server mit ihrem Port 22 genauso am öffentlichen Netz hängen wie die, die auch eine IPv4-Adresse haben. Es ist schier unmöglich, über so viele Adressen erschöpfende Portscans zu fahren. Wenn man für alle Adressen eines üblichen /64-Netzes pro Adresse 30 ms braucht (das impliziert schon eine explizite Ablehnung des Verbindungsversuchs, statt dass der andere das Paket verwirft und man erst auf den Timeout warten muss), müsste man 18 Milliarden Jahre lang scannen – für ein solches Netz … :-)
:
Bearbeitet durch Moderator
Wieso verhindert Subnetting das Broadcast-Aufkommen? Angenommen man hat zwei Subnetze A und B, die mit einem Router verbunden sind. Teilnehmer A.1 möchte auf den Dienst von B.1 zugreifen. Teilnehmer A.1 wurde dem Netz neu hinzugefügt. Er muss also erstmal einen Broadcast absetzen, um die Adresse von B.1 ausfindig zu machen. Den Broadcast empfängt dann auch der Router und sendet ihn weiter an die Schnittstelle zu Netz B. In Netz B verbreitet sich der Broadcast dann weiter. Ich sehe hier keinen Vorteil gegenüber einem Netz ohne Subnetting.
Torben schrieb: > A.1 möchte auf den Dienst von B.1 zugreifen. Teilnehmer A.1 wurde dem > Netz neu hinzugefügt. Er muss also erstmal einen Broadcast absetzen, um > die Adresse von B.1 ausfindig zu machen. Broadcasts werden nicht geroutet. Alle Pakete ausserhalb des direkt angeschlossenen (Sub-)Netzes müssen über einen Router. Da sich B.1 offensichtlich nicht in A befindet, weiss A.1, dass geroutet werden muss. A.1 kennt aus der Konfiguration oder aus DHCP die IP-Adresse des Routers aka Default-Gateways, ermittelt per ARP Broadcast dessen MAC-Adresse und sendet das Paket dorthin. Dieser ARP Vorgang findet nur bei der ersten Kommunikation statt. Die Anzahl Broadcasts wächst linear mit der Anzahl der Geräte im Subnetz - auch bekannt als Broadcast-Domain.
:
Bearbeitet durch User
Vielen Dank erstmal für deinen Beitrag. Es wäre schön, wenn das auch mal Im Unterricht erklärt werden würde. Ich habe das Gefühl, dass in der Ausbildung die Begriffe wie Broadcast usw. vorausgesetzt werden. A. K. schrieb: > Da sich B.1 offensichtlich nicht in A befindet, weiss A.1, dass geroutet > werden muss. Warum weiß A.1, dass geraoutet werden muss. Hat A.1 vorher ein Broadcast abgesetzt und weil der Fehlgeschlagen ist, wird das Paket an den Router gesandt?
Torben schrieb: > Übersichtlich (Netzwerkdokumentation) > Sicherheit (Personalabteilung , Entwicklung) > abgeschlossene Segmente (Produktion , Administration/Entwicklung) > geringere Kollisionsgefahr (Geschwindigkeitsvorteil) Mit Switches gibt es keine Kollisionen mehr. Allerdings gibt es eine begriffliche Falle, weil "Segmentierung" in jener Zeit, als Ethernet noch Kollisionen produzierte, etwas anders bedeuten konnte als heute. Heute versteht man darunter meist eine Netzaufteilung auf Layer 3 aufwärts, früher konnte das auch eine Aufteilung auf Layer 2 sein. In diesen 4 Zeilen scheint beides vermischt zu werden, was für Konfusion sorgen kann.
Torben schrieb: > Warum weiß A.1, dass geraoutet werden muss. Wenn die Zieladresse nicht in die Netzdefinition aus eigener IP-Adresse und Netzmaske passt, muss geroutet werden. Eine Zieladresse 1.1.2.1 ist bei einer eigenen Adresse 1.1.1.1/24 nicht direkt ansprechbar.
Jörg W. schrieb: > Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne: Dock, doch. Es bezeichnet einfach den Prozess aus einem größeren Netz (IP Bereich) ein kleineres Netz herauszutrennen. Dazu gibt es gewisse Regeln. So kann ein Subnetz, entsprechend seiner Größe, nicht an einer beliebigen IP-Adresse beginnen oder enden. Dabei ist es egal, ob das zu unterteilende Netz einem alten Class A, B, C Netz entspricht oder einem CIDR Netz. > einfach IP-Netzwerke, bestehend aus Netzerkadresse und Netzmaske. Das > Wort "Sub" stammt aus der Zeit der klassenbehafteten Netze, als man das > Internet noch so schön als Klasse A, B oder C eingeteilt hat. Innerhalb > dieser Klassen war es dann vor allem bei A und B üblich, "Subnetze" > einzuteilen, wobei im ursprünglichen Ansatz noch die Netzmaske aller > Subnetze gleich war. Langsam. Class A, B, C funktionierten ohne Netzmaske, denn die Netzgröße war implizit durch die Klasse, und damit durch die IP-Adressen selber, gegeben. Netzmasken wurden erst bei Einführung von CIDR benötigt. Damit begann das intensive Subnetting, in dem man aus übergroßen Netzen (wie Class A), kleine Netze heraustrennte. Wenn ein herausgetrenntes Netz (Subnetz) selber noch groß genug sind, dann kann man es nach den gleichen Regeln weiter zerteilen. Allerdings verzichtet man darauf ein solches Netz Sub-Subnetz zu nennen. Es wird, wenn nötig, ebenfalls einfach als Subnetz bezeichnet. Allgemein gilt, ein Subnetz ist einfach ein Netz. Mann nennt es dann Subnetz, wenn man betonen will, dass es durch Heraustrennen aus einem größeren Netz entstanden ist. Das Heraustrennen ist bei ehemaligen Class A, B, C oder CIDR Netzen gleich.
Hannes J. schrieb: > Jörg W. schrieb: >> Es gibt ohnehin praktisch kein "Subnetting" mehr in dem Sinne: > > Dock, doch. Es bezeichnet einfach den Prozess aus einem größeren Netz > (IP Bereich) ein kleineres Netz herauszutrennen. Dann ist das ganze Internet letztlich eine Hierarchie von "Subnetzen". In der Hierarchie nach oben werden sie zusammengefasst (aggregation, Anzahl der Maskenbits wird kleiner), nach unten aufgegliedert (Anzahl der Maskenbits wird größer). Das macht das Wort "Sub" darin irgendwie überflüssig. > Dazu gibt es gewisse > Regeln. So kann ein Subnetz, entsprechend seiner Größe, nicht an einer > Langsam. Class A, B, C funktionierten ohne Netzmaske, Selbstverständlich gab es den Begriff einer Netzmaske auch dort schon (bpsw. im ifconfig oder route Kommando), es wird nur bei fehlender Angabe einer Netzmaske eine vordefinierte Anzahl von Bits angenommen. Aber gerade für das Subnetting wurde auch damals schon eine größere Netzmaske explizit angegeben. > Allgemein gilt, ein Subnetz ist einfach ein Netz. Eben. Seit CIDR gibt es keinen Unterschied mehr. Zwischendrin gab's dann auch noch die Kuriosität eines "Supernetting", aber dieser Begriff ist mit CIDR völlig wieder in der Versenkung verschwunden.
:
Bearbeitet durch Moderator
Ich habe nochmal eine allgemeine Verständnisfrage zu dieser Thematik. Ich gehe wieder davon aus, dass zwei Netzsegmente A und B mit einem Router verbunden sind und ein Client A.1 auf den Service test.de zugreifen möchte, den B.1 bereitstellt. Außerdem lege ich fest, dass alle Netzwerkgeräte innerhalb eines Segmentes über einen Switch miteinander verbunden sind, ein DHCP-Server vorhanden ist und ein DNS existiert. A.1 ist neu an das Netz A angeschlossen worden. Ich versuche nun den Weg des IP-Paketes nachzuvollziehen. 1. Zuerst erkundigt sich A.1 beim DNS nach der IP-Adresse von test.de. 2. A.1 erhält die IP-Adresse x.x.x.x. 3. A.1 bildet ein IP-Paket und trägt als Ziel-Adresse die IP-Adresse von B.1 ein (x.x.x.x) und als Quell-Adresse seine eigene. 4. A.1 stellt fest, dass die Ziel-Adresse nicht im eigenen Netz liegt. 5. A.1 muss deshalb das Paket an das Default-Gateway (DG) adressieren. 6. Um es zum DG transportieren zu können, muss A.1 einen Ethernet-Frame bilden. 7. Der Ethernet-Frame benötigt als Ziel-Adresse die MAC-Adresse des DGs. 8. A.1 bezieht zunächst die IP-Adresse des DGs vom DHCP-Server. Sie lautet y.y.y.y 9. A.1 sendet daraufhin ein ARP-Broadcast. 10. Das DG antwortet und sendet seine MAC-Adresse. 11. A.1 trägt im Ethernet-Frame als Ziel-Adresse die MAC-Adresse des DGs ein. 12. A.1 versendet den Ethernet-Frame. 13. Das DG nimmt den Ethernet-Frame entgegen und ersetzt im IP-Paket die Absender-Adresse durch seine eigene (NAT) 14. Das Default-Gateway sendet das Paket weiter. Frage: Haut das einigermaßen hin?
Torben schrieb: > 13. Das DG nimmt den Ethernet-Frame entgegen und ersetzt im IP-Paket die > Absender-Adresse durch seine eigene (NAT) Ohne NAT: Setzt die eigene MAC Adresse als Absender ein, lässt die IP-Adresse unverändert. > Frage: Haut das einigermaßen hin? Ziemlich. NAT solltest du weglassen. Das hattest du bisher nicht erwähnt und ist vmtl ein Missverständnis deinerseits.
:
Bearbeitet durch User
Torben schrieb: > 5. A.1 muss deshalb das Paket an das Default-Gateway (DG) adressieren. Genauer: er muss anhand seiner Routing-Tabelle ermitteln, wem er als next hop nun das Paket zustellen muss, da es nicht in seinem eigenen Ethernet-Adressbereich liegt. Der default gateway ist dabei nur die letzte Möglichkeit, auf die er zurückfällt. Es könnte auch gut und gern eine Netztopologie sein, bei der der default gateway halt tatsächlich nur den Weg ins Internet beschreibt, während andere Netzwerkbereiche der eigenen Organisation über separate(s) Gateway(s) zu erreichen sind. Daher listet die Routingtabelle Netzwerkbereiche (wiederum gekennzeichnet durch Netwerkadressse und zugehöriger Netzmaske) mit ihrem jeweils zugehörigen Gateway. Der default gateway hat die spezielle Netzwerkadresse 0.0.0.0 und auch als Netzmaske 0.0.0.0, wodurch er auf alles andere passt. Die Routing-Policy geht dabei von einer möglichst spezifischen Route (der sie die höchste Priorität zugesteht) hin zu einer möglichst allgemeinen (wenn es einen default gateway gibt, dann ist er immer der letzte in der Betrachtung. Stell dir folgende Routingtabelle vor (das eigene Netz hat die 192.168.1.0/24):
1 | Zielnetz Netzmaske Gateway |
2 | 192.168.3.0 255.255.255.0 192.168.1.99 |
3 | 192.168.0.0 255.255.128.0 192.168.1.233 |
4 | 0.0.0.0 0.0.0.0 192.168.1.254 |
Für die folgenden Zieladressen würde er jeweils den gezeigten Gateway auswählen:
1 | Ziel GW |
2 | 192.168.3.33 192.168.1.99 |
3 | 192.168.5.19 192.168.1.233 |
4 | 192.168.233.1 192.168.1.254 |
5 | 8.8.8.8 192.168.1.254 |
Denk über die einzelnen Beispiel bisschen nach, mal dir ggf. die Bits auf, damit du sehen kannst, welche Adresse in welchen Netzbereich fällt. > 6. Um es zum DG transportieren zu können, muss A.1 einen Ethernet-Frame > bilden. Das müsste er übrigens auch, um es zu einem anderen Knoten im eigenen Netzbereich zu senden – insofern unterscheidet sich der Gateway hier nicht von den anderen Adressen im eigenen Netz. > 8. A.1 bezieht zunächst die IP-Adresse des DGs vom DHCP-Server. Sie > lautet y.y.y.y Die bezieht er nicht erst jetzt, sondern die hat er bereits während seiner Netzwerk-Konfigurationsphase bekommen, zusammen mit seiner IP-Adresse. > 13. Das DG nimmt den Ethernet-Frame entgegen und ersetzt im IP-Paket die > Absender-Adresse durch seine eigene (NAT) Wie A.K. schon schrieb: nur, wenn NAT überhaupt eine Rolle spielt. In meinem obigen Beispiel würde wahrscheinlich die 192.168.233.1 nur in ein anderes internes Netz weitergeleitet werden (es handelt sich ja immer noch um eine RFC1918-Adresse, die also nicht im Internet geroutet werden kann), während das Paket in Richtung 8.8.8.8 dann sicherlich geNATet wird.
Angehängte Dateien:
-
Screenshot_Routing.PNG
19 KB
Vielen Dank für die Antworten. Die Beiträge waren mir eine große Hilfe. ich habe sie die letzten Tage erstmal studieren müssen und konnte deshalb nicht gleich antworten. Nun ist mir eine Sache leider nicht ganz klar. Ich gehe wieder davon aus, dass zwei LANs A und B über einen Router miteinander verbunden, alle Geräte innerhalb eines LANs mit einem Switch miteiannder verbunden sind und Teilnehmer A.1 an Teilnehmer B.1 IP-Pakete versendet. Ich habe das beschriebene Szenario als Bilddatei angehängt. Ich habe nicht herausfinden können, wie der Router die konkrete MAC-Adresse von B.1 ermittelt. Die benötigt er doch, oder? Schließlich muss das Paket nicht nur geroutet, sondern einem konkreten Empfänger zugestellt werden. Greift der Router dazu auf einen ARP-Cache zu?
Genau wie A.1 die MAC-Adresse des Routers herausfindet: ARP. Und genau wie der PC merkt er sich das eine Weile im ARP Cache.
:
Bearbeitet durch User
Danke A. K. Jörg W. schrieb: > (es handelt sich ja immer > noch um eine RFC1918-Adresse, die also nicht im Internet geroutet werden > kann) Sinngemäß meinte mein Lehrer, es gibt so etwas wie Netzklassen nicht mehr.
Torben schrieb: > Sinngemäß meinte mein Lehrer, es gibt so etwas wie Netzklassen nicht > mehr. Hat er Recht. Das einzige, was sie noch bewirken ist, dass sie die Netzmaske festlegen, falls keine andere angegeben ist. Also:
1 | ifconfig eth0 192.168.3.5 |
ist äquivalent zu
1 | ifconfig eth0 192.168.3.5 netmask 255.255.255.0 |
weil 192.*.*.* im Sinne der Netzklassen ein Class C wäre.
Ich habe in meinem Lehrbuch mal ein paar Seiten weitergeblättert. Da geht es jetzt um die Verkabelung von Netzen. Auf einer Seite sind Datenkabel mit ihrer Dämpfung abgebildet. Da steht dann sowas wie CAT 5 22 dB bei 100 MHz. Was kann man denn dieser Information entnehmen? Kann man jetzt irgendwas Berechnen? Eine maximale Enternung oder Ähnliches?
Torben schrieb: > Datenkabel mit ihrer Dämpfung abgebildet. Da steht dann sowas wie CAT 5 > 22 dB bei 100 MHz. Was kann man denn dieser Information entnehmen? > Kann man jetzt irgendwas Berechnen? Nach einem geeigneten Studium der E-Technik kann man das. Als Praktiker schlägt man nach, wieviele Meter man mit welchem Kabeltyp bei welchem Netztyp gehen kann, und glaubt es einfach. Ansonsten brauchen beispielsweise jene Fachleute solche Werte, die alte Netze durchmessen, um dem Kunden eine neue teure Verkabelung verkaufen zu können. Aber rechnen tun die auch nicht, die stellen nur fest, ob es noch passt.
:
Bearbeitet durch User
Welche IP-Adresse bekommt eigentlich ein DHCP-Server? Muss man ihm von Hand eine statische zuweisen?
Server muss man ihre Adressen immer fest einstellen. Geht natürlich auch teilweise über DHCP (MAC address fixing), aber irgendwer muss halt das Ei für die Henne sein. ;-)
Beitrag #6191770 wurde vom Autor gelöscht.
Jörg W. schrieb: > Server muss man ihre Adressen immer fest einstellen. > > Geht natürlich auch teilweise über DHCP (MAC address fixing), aber > irgendwer muss halt das Ei für die Henne sein. ;-) Man kann natürlich mehrere DHCP Server verwenden. Nur sollte man dann aufpassen, dass wirklich immer einer davon läuft. ;-) Irgendeine IP-Adresse im betreffenden Netz braucht man. Ist aber egal welche. Fest muss die nur sein, wenn ein Router die DHCP-Requests eines anderen Netzes forwarded. torben_25 schrieb: > Welche IP-Adresse bekommt eigentlich ein DHCP-Server? Muss man ihm von > Hand eine statische zuweisen? Sollte man. Alles andere ist für Leute gedacht, die Spass an Problemen zum unmöglichsten Zeitpunkt haben.
:
Bearbeitet durch User
A. K. schrieb: > Man kann natürlich mehrere DHCP Server verwenden. Nur sollte man dann > aufpassen, dass wirklich immer einer davon läuft. Jau. > Alles andere ist für Leute gedacht, die Spass an Problemen zum > unmöglichsten Zeitpunkt haben. :-) Grundsätzlich ist es natürlich richtig, der DHCP-Server wird über Broadcasts angesprochen (an die generische Broadcast-Adresse 255.255.255.255), aber ihn nicht auf eine feste IP-Adresse zu legen, wäre schon ausgesprochen unklug. Außerdem, woher sollte er seine Adresse denn nehmen, wenn sie ihm nicht fest vorgegeben worden ist? Es gibt ja dann niemanden, der ihm eine verteilen könnte.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Außerdem, woher sollte er seine Adresse > denn nehmen, wenn sie ihm nicht fest vorgegeben worden ist? Es gibt ja > dann niemanden, der ihm eine verteilen könnte. Man könnte dem Netz eine 169.254-er Range geben, wenn Microsoft. Die gibts, wenn dem System sonst nichts einfällt. ;-)
:
Bearbeitet durch User
A. K. schrieb: > Man kann natürlich mehrere DHCP Server verwenden. Nur sollte man dann > aufpassen, dass wirklich immer einer davon läuft. ;-) Du wolltest schreiben "immer nur einer davon läuft." Um die Verwirrung zu erhöhen: Ich hatte auch schon zwei DHCP im selben Netz, aber so konfiguriert, dass sie unterschiedliche Adressen vergeben.
Manfred schrieb: > Um die Verwirrung zu erhöhen: Ich hatte auch schon zwei DHCP im selben > Netz, aber so konfiguriert, dass sie unterschiedliche Adressen vergeben. Wolltest du den schnellsten DHCP-Server ermitteln? Wer ruft zuerst "hier!" auf einen DHCP-Request? ;-)
Ein Gruß an alle und besten Dank für eure Hilfe
Manfred schrieb: > Du wolltest schreiben "immer nur einer davon läuft." Nein. > Um die Verwirrung zu erhöhen: Ich hatte auch schon zwei DHCP im selben > Netz, aber so konfiguriert, dass sie unterschiedliche Adressen vergeben. Ebendies. Kein Hexenwerk.
Torben schrieb: > Der > Punkt Abgeschlossene Segmente gehört doch zur Übersicht Damit werden Netze u.a. physikalisch getrennt. Du musst Zugange zu der Abteilung haben um an den Datenverkehr innerhalb des Segmentes zu sehen.
Manfred schrieb: > A. K. schrieb: >> Man kann natürlich mehrere DHCP Server verwenden. Nur sollte man dann >> aufpassen, dass wirklich immer einer davon läuft. ;-) > > Du wolltest schreiben "immer nur einer davon läuft." > Das stimmt in dieser Absloutheit nicht. Wenn es mehrere DHCP-Server gibt, muss man lediglich darauf achten, dass sich deren IP-Pools und die fest vergebenen Adressen nicht überschneiden und dass die ausgereichten IP-Adressen (nebst Zusatzinfos wie Gateway, DNS usw.) korrekt sind. Ich war kürzlich gezwungen, genau sowas einzurichten. Ein etwas weiter ab gelegenes Gebäude einer Firma wurde über eine weitere Zwischenstation mit einer Richtfunkstrecke mit dem Hauptsitz verbunden. Offenbar ergaben sich für die DHCP-Anfrage einiger Laptops zu lange Laufzeiten, so dass die sich immer schon eine 169er APIPA zugelegt hatten, bevor die Antwort kam. Also wurde in der letzten WLAN-Bridge der (normalerweise ungenutzte) DHCP-Server entsprechend konfiguriert und aktiviert. Geht.
:
Bearbeitet durch User
Frank E. schrieb: > Das stimmt in dieser Absloutheit nicht. Gebe ich dir Recht, wenngleich das schon eher ein ziemlicher Sonderfall ist, wo das mal Sinn hat, das zu machen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.