:!: Der Inhalt dieses Abschnittes wird zur Zeit entwickelt! Er ist noch unvollständig und kann jederzeit ganz oder in Teilen gelöscht oder geändert werden! :!:

Entsprechend dem X.121 Dokument der ITU besitzt Deutschland die vier County-Codes 262 bis 265. Bezogen auf das internationale Proposal zur Vergabe von privaten 32-bit-AS-Nummern im 44/8 ampr.org Netz stehen für DL vier AS-Nummernblöcke mit je 100000 32-bit-AS-Nummern zur Verfügung. Verglichen mit den 64 für ganz DL reservierten 16-Bit-AS-Nummern ist das eine immense Zahl. Zur Zeit wird die Verwendung des ersten 32-bit-AS-Blockes im HAMNET untersucht.

AS-Block Verwendung
42262xxxxx HAMNET DL
42263xxxxx future use
42264xxxxx future use
42265xxxxx future use

Da es innerhalb eines Landes nicht zu Doppelvergaben kommen darf, ist eine länderspezifische Policy zur Verwendung der verfügbaren 5 Digits (das sind die x in obiger Tabelle) erforderlich. Das deutsche HAMNET besteht zur Zeit ausschließlich aus 16-bit-ASN. Bis auf Weiteres stehen auch noch neue 16-bit-ASN und IP-Netzblöcke für Neugründungen zur Verfügung. Von daher besteht derzeit noch keine zwingende Notwendigkeit, die bisherige Vergabepraxis zu ändern. 32-bit-AS-Nummern können allerdings auch jetzt schon innerhalb bestehender 16-bit-AS sinnvoll verwendet werden, etwa beim Aufsetzen interner BGP-Confederations oder bei der Organisation gesplitteter AS, deren einzelne Teile sich nur über Nachbar-AS gegenseitig erreichen können.

Es geht hier also zunächst um die Verwendung von 32-bit-AS-Nummern innerhalb bestehender (16-bit-)AS mit den ihnen fest zugewiesenen IP-Netzen. Dazu werden im folgenden zwei Varianten vorgestellt, die zueinander kompatibel sind und theoretisch parallel nebeneinander benutzt werden könnten. Sie „verbrauchen“ insgesamt nur einen kleinen Teil des für Deutschland verfügbaren 32-bit-ASN-Ranges. Der große Rest kann nach Aufbrauchen der noch bereitstehenden neuen 16-bit-ASN und IP-Netzblöcke zu einem späteren Zeitpunkt vergeben werden. Die dazu notwendige Vergabe-Policy wird entsprechend zu einem späteren Zeitpunkt erarbeitet und vorgestellt.

Nach intensiven Überlegungen, bei denen zahlreiche Alternativen diskutiert und teilweise wieder verworfen wurden, haben sich für das deutsche HAMNET zwei Varianten als geeignet erwiesen. Beide Varianten sind zueinander kompatibel:

Variante 1: AS-based ASN

Bei dieser Variante werden in einem AS die drei letzten Ziffern der bereits zugewiesenen 16-bit-AS-Nummer auf die ersten drei der fünf verfügbaren Digits des neuen 32-bit-AS-Blocks gelegt. Die letzten beiden Digits der 32-bit-AS-Nummer sind dann innerhalb des jeweiligen „alten“ 16-Bit-AS frei verfügbar. Über den Einsatz dieser Nummern entscheiden die Maintainer des jeweilige AS.
Diese Vorgehensweise ist im deutschen HAMNET sehr sinnvoll. In DL werden primär 16-bit-AS Regionen vergeben, denen IP-Netze für Backbone und User/Services bereits zugeordnet sind. Eine oder mehrere zusätzliche 32-bit-AS-Nummern können sich so einer übergeordneten 16-Bit-AS-Nummer eindeutig zuordnen lassen.

Beispiel AS64633

AS64633    die letzten drei Ziffern sind 633
möglicher 32-bit-AS-Nummern Bereich innerhalb AS64633:
42 262 633 xx --> von 4226263800 bis 4226263899 

Vorteile:

  • keine zentrale Vergabeinstanz (Registry) notwendig
  • derzeitiger Besitzer des 16-bit-AS kann sofort verfügen
  • keine Dopplungen mit Zuteilungen in anderen AS möglich
  • Zugehörigkeit zu bestehendem 16-Bit-AS sofort erkennbar
  • kein Admin-Aufwand bei Umzug von IP-Netzen
  • AS-Nummern bleiben bei Umzug eines IP-Netzes am bisherigen Ort
  • lässt sich problemlos sofort in HamnetDB abbilden

Nachteile:

  • „nur“ 100 32-bit-AS-Nummern im bestehenden 16-bit-AS verfügbar
  • ???

Anwendungsbeispiel:

Problembeschreibung
Das AS64633 besteht aus mehreren Standorten, die intern per iBGP/BGP-Confederation verbunden sind. Am Standort DB0IUZ in Bochum ist wegen unvermeidlicher Umbauarbeiten der einzige interne iBGP-Link nach DB0DS in Dortmund weggefallen. Ein interner iBGP-Ersatzlink ist nicht möglich. Das AS64633 ist damit in zwei Teile zerfallen (AS-Split!), die sich nur durch ihre Nachbar-AS gegenseitig noch erreichen können. Es kommt zwangsläufig zu Routingproblemen. Mit BGP-Confederation ist das nicht mehr zu lösen. eBGP-Routing über die Nachbar-AS mit gesetzter Option „Allow-AS-In“ funktionieren (zumindest mit Mikrotik-Routern) ebenfalls nicht fehlerfrei. Die Situation wird oft nur noch weiter verschlimmert. Es kommt im HAMNET zur Nichterreichbarkeit ganzer Teilnetze und Standorte. Je nach Region ist auch immer ein Teil des gesplitteten AS64633 nicht erreichbar.
Problemlösung:
Will man an der bisherigen iBGP/Confederation-Struktur möglichst wenig ändern, dann bietet es sich an, einer der beiden AS-Inseln nach außen hin (eBGP) eine 32-bit-AS-Nummer zu geben und im anderen Teil die alte Konfiguration weiter zu benutzen. Im konkreten Beispiel hat der Insel-Standort DB0IUZ jetzt entsprechend dem obigen Vorschlag für „AS-based ASN“ die 32-bit-AS-Nummer 4226263301 bekommen. Mit dieser neuen AS-Nummer macht er sich bei allen seinen Linkpartnern bekannt. Die Linkpartner tragen auf ihren BGP-Links zu DB0IUZ anstelle der bisherigen 16-bit-Nummer 64633 die neue 32-bit-Nummer 4226263301 ein. Jetzt wird auf allen BGP-Links von DB0IUZ das eBGP-Protokoll genutzt. Für das HAMNET sieht es so aus, als sei ein neues AS entstanden, das zu seiner bisherigen Rest-AS-Insel 64633 ganz normal per eBGP geroutet wird. Die zuvor geschilderten Routingprobleme treten dann normalerweise nicht auf.
Ausblick
Dieses Prinzip funktioniert auch, wenn in beiden oder noch mehr AS-Inseln jeweils mehrere Standorte enthalten sind. Vorher verwendete BGP-Confederation-Nummern können in allen AS-Inseln beibehalten werden. Eine Insel behält ebenfalls die bisherige 16-Bit-AS-Nummer nach außen. Die anderen Inseln bekommen nach außen jeweils eine 32-bit-AS-Nummer nach obigem Vergabemuster zugewiesen.

Beispiel AS64625

AS64625    die letzten drei Ziffern sind 625
möglicher 32-bit-AS-Nummern Bereich innerhalb AS64625:
42 262 625 xx --> von 4226262500 bis 4226262599 

Vorteile:

  • keine zentrale Vergabeinstanz (Registry) notwendig
  • derzeitiger Besitzer des 16-bit-AS kann sofort verfügen
  • keine Dopplungen mit Zuteilungen in anderen AS möglich
  • Zugehörigkeit zu bestehendem 16-Bit-AS sofort erkennbar
  • kein Admin-Aufwand bei Umzug von IP-Netzen
  • AS-Nummern bleiben bei Umzug eines IP-Netzes am bisherigen Ort
  • lässt sich problemlos sofort in HamnetDB abbilden

Nachteile:

  • „nur“ 100 32-bit-AS-Nummern im bestehenden 16-bit-AS verfügbar
  • ???


Anwendungsbeispiel:

Als nächstes Beispiel soll eine von Jann, DG8NGN, zum Jahreswechsel durchgeführte Implementation von 32-bit-AS-Nummern im AS64625 (Distrikt-C) dienen. Jann hat am 2.1.2016 per Email seine Erfahrungen dazu mitgeteilt, die hier auszugsweise vorgestellt werden. Jann schreibt dazu:
„… Dazu zunächst die Karte:

http://hamnetdb.net/lsp_map.cgi?as=64625

Grund: DB0EBE ist QRT (auf der Karte der rote in der Mitte) und der Link DB0HOB ↔ DB0WAI geht nicht. Von DB0EBE liegt Teilnetz A links und Teilnetz B rechts. Es gibt also folgenden Netsplit innerhalb des AS:

Teilnetz A    Teilnetz B
DB0TVM        DB0AAT
DB0PUC        DB0MBG
DB0ZM         DB0INN
DB0WAI        DB0HOB
DB0DBA        DB0FHR
DB0QI

Beide Teile des AS haben keinen internen iBGP-Link mehr, das Routing ist gestört. Technisch hätte ich jetzt nur die Confederation AS-Nummer von Teilnetz A von 64625 auf 42 262 625 91 ändern müssen, aber ich habe zu Testzwecken (HamnetDB) auch gleich die internen AS-Nummern innerhalb der Confederation 42 262 625 91 geändert. Und zwar auf den Bereich 42 262 625 01 bis 42 262 625 29.

Die HamnetDB hat eine 1:1-Verknüpfung zwischen der 16-bit AS-Nummer und den zugewiesenen AS-Backbone bzw. AS-User/Services Subnetzen. D.h. in DL darf sich der Parent nicht ändern. Wir sehen das hier in der Tabelle „Subnets“ in der Spalte „Parent“:

http://hamnetdb.net/?m=as&q=&as=64625

Unter „OwnAS“ habe ich einfach die neue interne 32-bit AS-Nummer dokumentiert. Das ist kein Problem. Die entsprechende Confederation-AS habe ich zusätzlich an jedem betroffenem Sitenetwork in das Feld „Radio config parameters“ eingetragen, damit das so in der Liste auftaucht. Das „oldAS 655xx“ habe ich nur temporär so drinnen. Die Confederation-Teilnehmer habe ich direkt im Kommentarfeld vom AS64625 abgelegt.

Ich meine das ist ein guter Kompromiss, wenn man die HamnetDB nicht gleich vollständig umbauen möchte. Damit können auch alle Länder mit 16-bit AS-Nummer erstmal vollständig arbeiten.“
Soweit Beispiele, die zeigen, wie man bereits jetzt 32-bit-AS-NUmmern im deutschen HAMNET sinnvoll anwenden kann.

Variante 2: network-based ASN

Bei dieser Variante wird das jeweils 3. Oktett des dem AS zugewiesenen User-/Servicenetzwerk (nötigenfalls mit Nullen aufgefüllt) auf die ersten drei freien Digits gelegt. Die letzten beiden Digits sind dann frei verfügbar. Damit hätte dasjenige AS, welches das entsprechende User/Servicenetz zugewiesen bekommen hat, 400 der 32-bit-AS-Nummern (0-99) zur freien Verfügung.

Beispiel AS64638

AS64638    mit zugewiesenem User/Service-Block 44.225.72.0/22
           hat 44.225.72.0/24, 44.225.73.0/24, 44.225.74.0/24, 44.225.75.0/24
           Die 3.Oktett sind 072, 073, 074, 075
AS-Nummern (32-bit):        
42 262 072 xx  --> 4226207200 bis 4226207299
42 262 073 xx  --> 4226207300 bis 4226207399
42 262 074 xx  --> 4226207400 bis 4226207499
42 262 075 xx  --> 4226207500 bis 4226207599

Vorteile:

  • keine zentrale Vergabeinstanz (Registry) notwendig
  • derzeitiger „Besitzer“ des Netzes kann sofort verfügen
  • sehr hohe Zahl der in einem AS verfügbaren AS-Nummern

Nachteile:

  • bei Umzug des Netzwerkes in anderes AS hoher Admin-Aufwand bei alt und neu
  • lokale Zuordnung zu einem AS nicht direkt erkennbar
  • Integration in HamnetDB: derzeit schwierig bis garnicht abbildbar


Anwendungsbeispiele:

Zur Zeit sind keine Beispiele zu Variante 2 dokumentiert.