Hallo Thomas, Am Dienstag, 4. Mai 2004 10:02 schrieb Thomas Vollmer:
Ich habe mal für einen ISP gearbeitet der mal mehr als 25% des weltweiten Internettraffics gehandhabt hat.
Mit einer derartigen praktischen Erfahrung kann ich nicht aufwarten. Ich stütze mich lediglich auf den Lehrbuchinhalt meines ICND-Buchs (Literaturangabe siehe meine letzte Mail). Da das von Cisco-Press als quasi offizielle Schulungsunterlage für den CCNA herausgebracht worden ist, nehme ich mal an, dass da kein Unsinn drinsteht...
Sowohl vom RIPE und dessen registrars, als auch anderen NICs werden schon seit Jahren keine Netzblöcke mehr in Klassen vergeben.
Wenn ich Dich richtig verstehe, meinst Du, es werden keine Netzwerke mehr vergeben, deren Subnetzmasken genau den 8-, 16- oder 24-Bit-Masken der A-, B- oder C-Netze entsprechen. Das hatte ich auch gar nicht bestritten. Wie aus meiner letzten Mail eigentlich hervorgegangen sein sollte, geht es mir überhaupt nicht darum, die (ziemlich absurde) Behauptung aufzustellen, es könnten nur A-, B- oder C-Netze mit ihren vordefinierten Subnetzmasken eingerichtet werden. Es ging mir in meiner ursprünglichen Mail ja gerade darum, zu erklären, wie Sub- und Supernetting eigentlich funktionieren. Der Punkt ist vielmehr der:
Mit anderen Worten: Das "klassenlose" Routing schafft die Klassen als solche nicht ab, sondern es bietet eine Möglichkeit - auf der Grundlage der über die Klassen vordefinierten Subnetzmasken - Dir eigene Netzwerkgrenzen zu definieren. (Aus meiner letzten Mail)
Wenn Du das anders siehst, also meinst, dass die Klassen für das Sub- und Supernetting überhaupt keine Rolle spielen, solltest Du mir schon erklären, wie das Deiner Meinung nach funktionieren soll. Insbesondere folgende Fragen müssten dann ja geklärt werden: 1. Wie stellt die Software (das verwendete Routing-Protokoll) fest, dass gesub- oder gesupernettet wurde? Zur Verdeutlichung: Sowohl bei Subnetzen als auch bei Supernetzen brauche ich _zwingend_ einen "dritten" Bereich: a) Supernetz | "normale" Netze | Hosts b) "normales" Netz | Subnetze | Hosts Da ich (nach irgendeiner RFC) keine Subnetzmasken mit "Löchern" definieren darf, ist es definitiv nicht möglich, die drei Bereiche mittels einer einzigen Subnetzmaske zu bestimmen, etwa so: 1111 1111.1111 1111.0000 0111.1111 1111 für 16 Bit "normales" Netz 5 Bit Subnetze 11 Bit Hosts Die Software, die so etwas versteht, müsstest Du Dir selber programmieren... ;-) Du _musst_ also, um den "dritten" Bereich zu bekommen, zwei Subnetzmasken übereinanderlegen. Durch deren Differenz entstehen dann Sub- oder Supernetze, zum Beispiel so: 1111 1111.1111 1111.0000 0000.0000 0000 1111 1111.1111 1111.1111 1000.0000 0000 für 16 Bit "normales" Netz 5 Bit Subnetze 11 Bit Hosts Du gibst aber (z.B. an der Schnittstelle eines Routers) immer nur _eine_ Subnetzmaske an, unter Cisco-IOS beispielsweise: Router(config-if)#ip address 172.20.16.145 255.255.248.0 Die Frage ist jetzt die: woher nimmt der Router (genauer: das Routing-Protokoll) nun die - zwingend notwendige - zweite Subnetzmaske, wenn nicht dadurch, dass er (es) die Klassen benutzt, um die jeweils vordefinierte Subnetzmaske als eben diese zweite Maske zu ermitteln? 2. Wo ziehst Du bei Deiner Subnetz- oder Supernetzberechnung (die Du beispielsweise mit Bleistift und Papier durchführen kannst) den "zweiten" Strich, mittels dessen Du den Subnetz- oder den Supernetzbereich vom "normalen" Netzwerkbereich abtrennst? Woher weißt Du, dass bei einem Netzwerk 172.20.0.0 Dir die Subnetzmaske 255.255.248.0 einen genau 5 Bit großen Subnetzbereich beschert, Du also 2^5 - 2 = 30 Subnetze einrichten kannst? 3. Auf der abstrakt-theoretischen Ebene: Um zu bestimmen, was ein Supernetz und was ein Subnetz ist, musst Du beides gegen "normale" Netzwerke abgrenzen. Ohne eine solche Abgrenzung ist ja wohl sowohl Subnetting als auch Supernetting (und damit das ganze "klassenlose" Routing) völlig unmöglich. Wie sind "normale" Netze definiert?
Ein weiterer Punkt ist, dass in vielen kleineren Netzen immer noch RIP werkelt. RIP kann bekanntermaßen mit klassenlosem Routing nicht umgehen. In diesen Fällen sind also nicht nur die Klassen existent (sonst würde RIP nicht funktionieren), sondern es wird auch immer noch klassenbasiertes Routing betrieben...
Dafür gibt es RIPv2 und ich kann immer noch eine /8, /16 oder /24 Maske nehmen um immer noch mit RIPv1 zu leben (Wenn man sich das denn antun möchte). Nur ist das halt technisch keine klassische Einteilung in Klassen mehr, sondern mehr in den Köpfen der Leute.
Dazu gibt es meiner Meinung nach mehrere Dinge zu sagen: Zum Einen ist es häufig nicht eine Frage, ob irgendjemand sich RIPv1 antun möchte oder nicht. Ich habe von _kleineren_ Netzwerken gesprochen. Wenn Du einen SOHO-Router im Computerladen um die Ecke kaufst (dazu gibt es oft aus finanziellen Gründen keine wirkliche Alternative), dann gehe ich jede Wette ein, dass auf so einem Gerät mit hoher Wahrscheinlichkeit 1. RIPv1 als Routing-Protokoll installiert ist; 2. Du RIPv1 weder entfernen noch durch ein anderes Routing-Protokoll ersetzen kannst; 3. Es Dir außer der Defaultroute (Standard-Gateway) auch nicht möglich ist, statische Routen zu setzen; 4. Es keine Möglichkeit gibt, Dir die Routing-Tabelle anzuschauen oder RIP-Updates zu beobachten... Zweitens: Wenn Du Dich darauf beschränkst, _ausschließlich_ 8-, 16- oder 24-Bit-Masken zu verwenden, dann betreibst Du faktisch klassenbasiertes Routing, und zwar deshalb, weil Dein Routing-Protokoll (RIPv1) mit etwas anderem nicht vernünftig umgehen kann. Drittens ist die ganze Frage meiner Meinung nach nicht primär technischer Natur. Sie hat erstens damit zu tun, wie Router (bzw. Routing-Protokolle) faktisch arbeiten, zweitens mit dem zugrunde liegenden abstrakt-theoretischen Modell (d.h mit dem, was in den Köpfen der Leute vorgeht) und drittens mit den "offiziellen" Definitionen in den verschiedenen RFCs. Für mein Verständnis ist es so, dass die Vorstellungen, die die Menschen entwickeln, eine entscheidende Rolle dafür spielen, was wirklich passiert...
Thomas
Viele Grüße, Marcus -- - Inhaltliche Antworten bitte nur an die Mailingliste. - Die Spielregeln: http://www.suse-etikette.de.vu/