6. Beispiel für neue Adresszuweisungen und Routing
- Beispiel für neue Adresszuweisungen und Routing
6.1. Adressdelegation
Betrachten wir den Block von 524288 (2^19) Adressen, beginnend bei 10.24.0.0 und endend bei 10.31.255.255, der einem einzigen Netzwerk-Dienstanbieter „PA“ zugewiesen wurde. Dies entspricht der Größe eines Blocks von 2048 geerbten „Klasse-C“-Netzwerknummern (oder /24). Eine classless Route zu diesem Block würde als 10.24.0.0 mit der Maske 255.248.0.0 und dem Präfix 10.24.0.0/13 beschrieben.
Nehmen wir an, dieser Dienstanbieter verbindet sechs Endstellen in folgender Reihenfolge (signifikant, da es zeigt, wie temporäre „Löcher“ im Adressraum des Dienstanbieters entstehen können):
o „C1“, benötigt weniger als 2048 Adressen (/21 oder 8 x /24)
o „C2“, benötigt weniger als 4096 Adressen (/20 oder 16 x /24)
o „C3“, benötigt weniger als 1024 Adressen (/22 oder 4 x /24)
o „C4“, benötigt weniger als 1024 Adressen (/22 oder 4 x /24)
o „C5“, benötigt weniger als 512 Adressen (/23 oder 2 x /24)
o „C6“, benötigt weniger als 512 Adressen (/23 oder 2 x /24)
In allen Fällen wird angenommen, dass die von jeder Endstelle „benötigte“ Anzahl an IPv4-Adressen ein signifikantes Wachstum ermöglicht. Der Dienstanbieter delegiert seinen Adressraum wie folgt:
o C1. Zuweisen 10.24.0 bis 10.24.7. Dieser Netzwerkblock wird durch die Route 10.24.0.0/21 (Maske 255.255.248.0) beschrieben.
o C2. Zuweisen 10.24.16 bis 10.24.31. Dieser Block wird durch die Route 10.24.16.0/20 (Maske 255.255.240.0) beschrieben.
o C3. Zuweisen 10.24.8 bis 10.24.11. Dieser Block wird durch die Route 10.24.8.0/22 (Maske 255.255.252.0) beschrieben.
o C4. Zuweisen 10.24.12 bis 10.24.15. Dieser Block wird durch die Route 10.24.12.0/22 (Maske 255.255.252.0) beschrieben.
o C5. Zuweisen 10.24.32 und 10.24.33. Dieser Block wird durch die Route 10.24.32.0/23 (Maske 255.255.254.0) beschrieben.
o C6. Zuweisen 10.24.34 und 10.24.35. Dieser Block wird durch die Route 10.24.34.0/23 (Maske 255.255.254.0) beschrieben.
Diese sechs Endstellen müssen innerhalb des IGP des Dienstanbieters als sechs Präfixe variabler Größe dargestellt werden. Wenn der Dienstanbieter aus irgendeinem Grund ein veraltetes IGP verwendet, das classless Routing oder variabel lange Subnetze nicht unterstützt, dann müssen explizite Routen für alle /24 transportiert werden.
Um dieses Beispiel realistischer zu machen, nehmen wir an, dass C4 und C5 multi-homed über einen anderen Dienstanbieter „PB“ sind. Nehmen wir ferner eine Endstelle „C7“ an, die ursprünglich mit „RB“ verbunden war, aber zu „PA“ gewechselt hat. Aus diesem Grund besitzt sie einen Block von Netzwerknummern, die aus dem (nächsten) Block von 2048 x /24 von PB zugewiesen wurden.
o C7. Zuweisen 10.32.0 bis 10.32.15. Dieser Block wird durch die Route 10.32.0.0/20 (Maske 255.255.240.0) beschrieben.
Für die multi-homed Endstellen nehmen wir an, dass C4 primär über „RA“ und sekundär über „RB“ angekündigt wird; und dass C5 primär über „RB“ und sekundär über „RA“ angekündigt wird. Nehmen wir ferner an, dass „RA“ und „RB“ beide mit demselben Transit-Dienstanbieter „BB“ verbunden sind.
Grafisch ähnelt diese Topologie Folgendem:
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ /
+----+ +----+
10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | 10.24.12.0 - 10.24.15.0_ | |
\| | / C4: 10.24.12.0/20 \ | |
| |/ \| |
10.24.8.0 - 10.24.11.0___/| PA |\ | PB |
C3: 10.24.8.0/22 | | _10.24.32.0 - 10.24.33.0__| |
| | C5: 10.24.32.0/23 | |
| | | |
10.24.34.0 - 10.24.35.0__/| | | |
C6: 10.24.34.0/23 | | | |
+----+ +----+
|| ||
routing advertisements: || ||
|| ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| ||
VV VV
+---------- BACKBONE NETWORK BB ----------+
6.2. Routing-Ankündigungen
Um Regel Nr. 1 zu befolgen, muss PA den ihm gegebenen Adressblock und C7 ankündigen. Da C4 multi-homed und primär über PA ist, muss es ebenfalls angekündigt werden. C5 ist multi-homed und primär über PB. Prinzipiell (und im obigen Beispiel) muss es nicht angekündigt werden, da die Longest-Match durch PB automatisch PB als primär auswählt und die Ankündigung des Aggregats von PA als sekundär verwendet wird. In der realen Praxis wird C5 normalerweise über beide Dienstanbieter angekündigt.
Die Ankündigungen von „PA“ an „BB“ lauten:
10.24.12.0/22 primary (kündigt C4 an)
10.32.0.0/20 primary (kündigt C7 an)
10.24.0.0/13 primary (kündigt Rest von PA an)
Für PB müssen die Ankündigungen ebenfalls C4 und C5 sowie seinen eigenen Adressblock einschließen.
Die Ankündigungen von „PB“ an „BB“ lauten:
10.24.12.0/22 secondary (kündigt C4 an)
10.24.32.0/23 primary (kündigt C5 an)
10.32.0.0/13 primary (kündigt Rest von RB an)
Um die in Abschnitt 5.1 erwähnte Problemdiagnosefrage zu veranschaulichen, betrachten wir, was passiert, wenn PA seine Erreichbarkeit zu C7 (der Endstelle, die aus dem Adressraum von PB zugewiesen ist) verliert. In einem zustandsbehafteten Protokoll (stateful protocol) wird PA an BB ankündigen, dass 10.32.0.0/20 unerreichbar geworden ist. Nun, wenn BB diese Information aus seiner Routing-Tabelle entfernt, wird zukünftiger Traffic, der durch es zu diesem Ziel gesendet wird, gemäß der weniger spezifischen Übereinstimmung von PB, 10.32.0.0/13, an PB weitergeleitet (wo er gemäß Regel Nr. 2 verworfen wird). Obwohl dies kein Betriebsproblem verursacht (C7 ist in jedem Fall unerreichbar), erzeugt es dennoch zusätzlichen Traffic durch „BB“ (und kann auch jemanden verwirren, der den Ausfall mit „traceroute“ debuggen will). Ein Mechanismus zum Zwischenspeichern eines solchen unerreichbaren Zustands wäre wünschenswert, liegt aber außerhalb des Rahmens dieses Dokuments.