Oli72 1 Geschrieben 8. Juni 2020 Autor Melden Teilen Geschrieben 8. Juni 2020 vor 2 Stunden schrieb Dukel: Der Prefix ist die Subnetmaske. Man kann /24, 255.255.255.0 oder 11111111.11111111.11111111.00000000 austauschen. Das ist das selbe. EDIT: Zur Unterstützung https://www.heise.de/netze/tools/netzwerkrechner/ Hier mal ein Beispiel: 192.168.56.1 11000000.10101000.00111000.00000001 255.255.240.0 11111111.11111111.11110000.00000000 AND 11000000.10101000.00110000.00000000 192.168.47.1 11000000.10101000.00101111.00000001 255.255.240.0 11111111.11111111.11110000.00000000 AND 11000000.10101000.00100000.00000000 Hier siehst du das der Rot Markierte Bereich unterschiedlich ist und die beiden IP Adressen somit in Unterschiedlichen Netzen sind. Hm, daß der Prefix /x der Subnetzmaske entsprechen muß, widerspricht aber so manchen Darstellungen. Beispiel sind die nicht öffentlich gerouteten Adressen, also die Adressen für die lokalen Netzwerke (siehe angehängtes Bild). Wenn man sich hier die Klasse C Netzwerke mit 192.168.0.0 ansieht, so ist der Prefix /16, also die 192 und die 168 müssen so bleiben. Die Subnetzmaske ist aber nach wie vor 255.255.255.0. Bei der Klasse B ist der Prefix /12. Nur so bekomme ich den Raum 16-31 hin. Wäre der Prefix ebenfalls 16, so müsste die zweite Zahl ebenfalls gleich bleiben. Die Subnetzmaske in der Klasse B bleibt aber bei 255.255.0.0 solange ich keine Subnetze entwerfe. Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 8. Juni 2020 Melden Teilen Geschrieben 8. Juni 2020 (bearbeitet) Moin, du wirfst da Dinge durcheinander. Die Zeile mit 192.168.0.0 meint, dass alle Subnets, die mit 192.168. beginnen, zur "Class C" gehören - bzw. gehörten, denn die Class-Aufteilung ist seit vielen, vielen Jahren obsolet. Jedes einzelne Netz in diesem Bereich nutzt typischerweise (bzw. nutzte eben zur damaligen Class-Zeit) 24 Bits als Subnetzmaske. Von diesen Netzen gab es aber 256 Stück, die eben alle unterhalb von 192.168. lagen. Die Grafik beschreibt nicht die einzeln verwendbaren Subnets der "Klassen", sondern die Bereiche, die die Klassen zur Verfügung standen. Deine Interpretation dieser Grafik ist ein Missverständnis, das aber durch die (irreführende) Grafik provoziert ist. Da du offenbar gerade dabei bist, dir Grundlagen anzueignen: Verabschiede dich von dem "Klassen"-Konzept. Das ist Stand der Achtzigerjahre. "Klassen" waren festgelegte Netzwerkbereiche, in denen man eben keine Subnetzmasken hatte bzw. brauchte - weil die Größe des Subnets eindeutig durch die Klasse vorgegeben war. Gruß, Nils bearbeitet 8. Juni 2020 von NilsK Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 8. Juni 2020 Melden Teilen Geschrieben 8. Juni 2020 (bearbeitet) Beim Beispiel 192.168.0.0/16 ist immer nur das "Problem", dass jeder ein 192.168.x.0/24 daraus macht. Lt. RFC ist es ein /16 -> 255.255.0.0 Und bei "Klasse B" darfst du das nicht in der Dezimalschreibweise sondern Binär anschauen. /12 ist 255.240.0.0. EDIT: Hier die offizielle Quelle: https://tools.ietf.org/html/rfc1918 Quote We will refer to the first block as "24-bit block", the second as "20-bit block", and to the third as "16-bit" block. Note that (in pre-CIDR notation) the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and third block is a set of 256 contiguous class C network numbers. bearbeitet 8. Juni 2020 von Dukel Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 8. Juni 2020 Melden Teilen Geschrieben 8. Juni 2020 Moin, das ist jetzt eine Frage der Betrachtung. Zitat Lt. RFC ist es ein /16 Dein Zitat sagt was anderes. Demnach sind es 256-mal /24. Wenn man es denn so schreiben will. Die 16 Bit beziehen sich auf den gesamten Bereich privater Netze, aber der unterteilt sich nun mal in 256 Blöcke zu je 8 Bit. Führt aber irgendwie nicht weiter. Außer dass es die Verwirrung zwischen "Classes" und CIDR fortsetzt. Zu der Zeit, als die "Klassen" festgelegt wurden, gab es aber nun mal CIDR und die Subnetzmasken noch nicht. Und seit mit CIDR gearbeitet wird (über 25 Jahre!), sind die Klassen faktisch obsolet. Gruß, Nils 2 Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 8. Juni 2020 Melden Teilen Geschrieben 8. Juni 2020 Freigegeben ist ein /16 Netz (siehe RFC). Dieses Netz kann man mittels Subnetting aufteilen und bekommt z.B. so 256 /24 Netze. Da widerspricht sich nichts. Vermutlich ist die Verwirrung des TO, dass eben 172.16-31.0-255.0-255 kein Class B und 192.168.... kein Class C Netz ist, aber idr als diese Klassen genutzt werden. Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 9. Juni 2020 Melden Teilen Geschrieben 9. Juni 2020 Moin, auch auf die Gefahr hin, mich als Erbsenzähler zu betätigen, aber ... nein. "Subnetting" gab es zu der Zeit, als die Klassenbereiche definiert wurden, noch nicht. Damals gab es eine statische Aufteilung des gesamten IP-Adressbereichs. Subnetzmasken brauchte man damals noch nicht. Für private Adressierung vorgesehen ist unterhalb von 192.168. nicht ein 16-Bit-Netz, sondern es sind 256 8-Bit-Netze, die jeweils direkt aneinandergrenzen. Je nach Perspektive mag das ähnlich aussehen, es ist aber ein grundlegender Unterschied. In der Zeit vor CIDR war damit das Netz 192.168.1.x ein in sich abgeschlossenes Netz mit 256 Adressen, das von dem Netz 192.168.2.x abgetrennt war. Die ganze Betrachtung mit /16, /24, Subnetting und sogar Subnetzmasken ist "jünger" und hat mit den damaligen Klassen eben nichts zu tun. Ein Klasse-C-Netz hat zwar 8 Bit zur Host-Adressierung, aber ein 8-Bit-Netz ist nicht einfach ein Klasse-C-Netz. Dass diese Begriffe auch 27 Jahre nach der Einführung von CIDR noch immer munter durcheinander geworfen werden, trägt eben zur Verwirrung bei. Und, wie gesagt, die Grafik, die der TO gefunden hat, verstärkt die Unklarheit noch. Sie ist zwar - aus einer Perspektive - sachlich korrekt, stellt die Zusammenhänge aber irreführend dar. Gruß, Nils 2 Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 9. Juni 2020 Melden Teilen Geschrieben 9. Juni 2020 (bearbeitet) Die Grafik ist das selbe, was der RFC sagt, wurde vom TO aber falsch interpretiert: Quote 3. Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) Die Privaten Netze (RFC1918 aus 1996) ist nach dem RFC für CIDR (1519 aus 1993) entstanden (oder wurde geändert)! bearbeitet 9. Juni 2020 von Dukel Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 9. Juni 2020 Melden Teilen Geschrieben 9. Juni 2020 Moin, ja, du hast ja Recht ... ich will auch gar nicht in Zweifel ziehen, was du sagst, oder mich mit dir um Details kabbeln. Hör ich jetzt mal auf mit. Worum es mir geht: Der TO hat sich von Klassen, Subnetting usw. auf unwegsames Gelände locken lassen. Das macht die Sache für ihn unnötig kompliziert. Zugegebenermaßen hilft es allerdings auch nicht, wenn man (wie ich) an der Stelle versucht, die Details technisch aufzudröseln. (Lass ich jetzt auch bleiben.) Für das Verständnis ist es nach meiner Erfahrung hilfreicher, wenn man erst mal von dem "wie es gehen sollte" her kommt und sich nicht zu früh mit Grenzen oder Fehlern beschäftigt. Dass zwei Netze sich überlappen, wenn man die Subnetzmasken unpassend setzt (wie es in den Beiträgen des TO ja teils dargestellt ist), ist technisch in IP möglich. Dabei kann die Kommunikation, wie auch schon angemerkt wurde, teilweise auch funktionieren - nur eben nicht mehr zuverlässig oder "immer". Am Ende sind solche Dinge dann meist Fehlkonfigurationen. Gruß, Nils 2 Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 9. Juni 2020 Melden Teilen Geschrieben 9. Juni 2020 Jetzt wäre noch interresant, ob der TO das ganze jetzt verstanden hat oder noch Fragen hat. Ansonsten kann man das alles so stehen lassen. 1 Zitieren Link zu diesem Kommentar
Oli72 1 Geschrieben 9. Juni 2020 Autor Melden Teilen Geschrieben 9. Juni 2020 Hallo Dukel. Ich lese das hier interessiert mit und bin echt dankbar, daß es so eine Hilfe gibt. Und ja, NilsK, ich bin noch mit den Grundlagen beschäftigt (Fernstudium 3.Monat) . Das ist jetzt alles gar nicht sooo schwer bisher, aber hier stehe ich anscheinend total auf dem Schlauch. Der Hintergrund war eine Aufgabe, in der ich die beiden im ersten Post genannten IP´s mithilfe AND analysieren und so feststellen sollte, ob beide IP´s im selben Netz miteinander kommunizieren können. Also alles binär umgerechnet und AND angewendet. Auf dem ersten Blick hatte ich gesagt, da geht auf keinen Fall, da die Subnetzmasken eine unterschiedliche Größe haben /20 und /22. Somit ist der Netzanteil der IP unterschiedlich. PUNKT. Das Ergebnis der Berechnung allerdings ergibt 2 x ein identisches Ergebniss und gem. Definition im meinem Lehrheft bedeutet dies,daß beide IP´s im selben Netz liegen. Ich denke so langsam, daß dort der Fehler liegt. Mich hat im Grunde nur dieses Berechnungsergebniss völlig verwirrt :-))) (unten nochmal die Berechnung) Und Dukel, vielen Dank. Wie Du oben schreibst habe ich mich wohl tatsächlich daran festgefressen, daß die Definition der privaten Netzwerke nicht mit den "Klassen übereinstimmt" Also wenn ich das so richtig verstanden habe (was ich jetzt echt hoffe sonst springe ich aus dem Kellerfenster :-)) ) ist z.B: 192.168.0.0/16 nur die Definition eines privaten Netzes und ich habe hier aber trotzdem die Möglichkeit das mit Subnetting z.B. in 256 Netze aufzuteilen, indem ich die Subnetzmaske 255.255.255.0 , also /24 verwende. Oder ich verwende eben ein einziges Netz mit entsprechend höhere Anzahl an HOSTAdressen mit Subnetz 255.255.0.0. IP 192.168.56.1 /20 1100 0000 1010 1000 0011 1000 0000 0001 1111 1111 1111 1111 1111 0000 0000 0000 (Subnetz) 1100 0000 1010 1000 0011 0000 0000 0000 IP 192.168.50.1 /22 1100 0000 1010 1000 0011 0010 0000 0001 1111 1111 1111 1111 1111 1100 0000 0000 (Subnetz) 1100 0000 1010 1000 0011 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 Vergleich XOR der beiden Ergebnisse (hier liegt irgendwo der Denkfehler. Ich lese das in meinen Unterlagen ganz klar so, daß beide Adressen im selben Netz liegen, wenn dieses Ergebniss durchgegen 0 ist) Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 9. Juni 2020 Melden Teilen Geschrieben 9. Juni 2020 XOR zeigt dir Unterschiede zwischen 1100 0000 1010 1000 0011 0000 0000 0000 und 1100 0000 1010 1000 0011 0000 0000 0000 an. Da es keine Unterschiede gibt kommt überall "0" heraus und die beiden IP's sind im selben Netz. Berechne das mal als zweite IP mit 192.168.20.1/22 Zitieren Link zu diesem Kommentar
Beste Lösung NilsK 2.940 Geschrieben 9. Juni 2020 Beste Lösung Melden Teilen Geschrieben 9. Juni 2020 Moin, solche Subnet-Betrachtungen kann man deutlich vereinfachen, wenn man die bitweisen Operationen weglässt und einfach "nach Optik" vergleicht. Subnet-Masken haben (in binärer Schreibweise) immer zusammenhängende 1-Ketten, die ganz links beginnen immer, wenn in der Subnet-Maske eine 1 steht, gehört die entsprechende Stelle in der IP-Adresse (in binärer Schreibweise) zur Netzwerk-Adresse. Immer, wenn in der Subnet-Maske eine 0 steht, gehört die entsprechende Stelle in der IP-Adresse (in binärer Schreibweise) zur Host-Adresse. Man schreibt beides untereinander und vergleicht optisch. Kein Bedarf, im Kopf oder per Tool AND, XOR oder sonstwas durchzugehen, was für Menschen wenig intuitiv ist. Hier mal verdeutlicht mit "x" für 1 und "-" für 0: IP 192.168.56.1 /20 1100 0000 1010 1000 0011 1000 0000 0001 xxxx xxxx xxxx xxxx xxxx ---- ---- ---- IP 192.168.50.1 /22 1100 0000 1010 1000 0011 0010 0000 0001 xxxx xxxx xxxx xxxx xxxx xx-- ---- ---- Aus Sicht des ersten Hosts (mit der IP-Adresse 192.168.56.1 /20) ist der zweite Host also im selben Netz. Er wird versuchen, ihn direkt ohne Router anzusprechen. Aus Sicht des zweiten Hosts (mit der IP-Adresse 192.168.50.1 /22) ist der erste Host nicht im selben Netz. Er kann diesen also nicht direkt ansprechen, sondern müsste seinen Router dafür ansprechen. Je nachdem, wie dieser konfiguriert ist, klappt das dann oder auch nicht. (Dieses Ergebnis kam oben in diesem Thread bereits vor.) Deine XOR-Betrachtung verstehe ich nicht - sie ist, soweit ich sehe, fehlerhaft. Das liegt nach meinem Dafürhalten daran, dass Menschen nun mal mit XOR nicht intuitiv umgehen können. Mach es dir einfacher. Gruß, Nils Zitieren Link zu diesem Kommentar
Oli72 1 Geschrieben 9. Juni 2020 Autor Melden Teilen Geschrieben 9. Juni 2020 Nu aber. Jetzt ist der Groschen gefallen. Das erklärt mir jetzt auch, weshalb im Test (habe das Scenario nachgebaut) ein Ping von der 56.1 auf die 50.1 einen Timeout bekommt und anders herum "Zieladresse ist nicht erreichbar". Klar, die 56.1 kann direkt senden, bekommt aber keine Antwort . Ich werde das mal an das Fernstudium Institut schreiben. Das ist dort echt saublöd erklärt. Ich danke euch für die "Erleuchtung" .-) Zitieren Link zu diesem Kommentar
daabm 1.358 Geschrieben 9. Juni 2020 Melden Teilen Geschrieben 9. Juni 2020 Ich könnte jetzt noch einwerfen, daß alle Host-Bits = 0 -> Netzadresse und alle Host-Bits = 1 -> Broadcast, aber das führt glaub zu weit Und dann könnte man noch auf die abstruse (und auch nicht vorgesehene) Idee kommen, daß eine Netmask ja - rein technisch - nicht mal zwingend links beginnen und fortlaufend sein muß. Da kommen dann Konstrukte raus, die für Computer total einfach, für Menschen aber absolut nicht nachvollziehbar sind Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.