http://www.de.ampr.org/ 2026-05-04T20:53:03+00:00 http://www.de.ampr.org/ http://www.de.ampr.org/_media/logo.png text/html 2020-11-28T20:22:15+00:00 Anonymous (anonymous@undisclosed.example.com) http://www.de.ampr.org/hamnet/as-nummern/32-bit/policy-dl/as-split <h4 class="sectionedit1" id="beispiel_as64633">Beispiel AS64633</h4> <div class="level4"> <pre class="code">AS64633 die letzten drei Ziffern sind 633 möglicher 32-bit-AS-Nummern Bereich innerhalb AS64633: 42 262 633 xx --&gt; von 4226263800 bis 4226263899 </pre> <p> <strong>Vorteile:</strong><br/> </p> <ul> <li class="level1"><div class="li"> keine zentrale Vergabeinstanz (Registry) notwendig</div> </li> <li class="level1"><div class="li"> derzeitiger Besitzer des 16-bit-AS kann sofort verfügen</div> </li> <li class="level1"><div class="li"> keine Dopplungen mit Zuteilungen in anderen AS möglich</div> </li> <li class="level1"><div class="li"> Zugehörigkeit zu bestehendem 16-Bit-AS sofort erkennbar</div> </li> <li class="level1"><div class="li"> kein Admin-Aufwand bei Umzug von IP-Netzen</div> </li> <li class="level1"><div class="li"> AS-Nummern bleiben bei Umzug eines IP-Netzes am bisherigen Ort</div> </li> <li class="level1"><div class="li"> lässt sich problemlos sofort in HamnetDB abbilden</div> </li> </ul> <p> <strong>Nachteile</strong>:<br/> </p> <ul> <li class="level1"><div class="li"> „nur“ 100 32-bit-AS-Nummern im bestehenden 16-bit-AS verfügbar</div> </li> <li class="level1"><div class="li"> ???</div> </li> </ul> <p> <strong><em class="u">Anwendungsbeispiel:</em></strong> <br/> </p> <p> <strong>Problembeschreibung</strong> <br/> </p> <p> 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.<br/> <br/> <strong>Problemlösung:</strong> <br/> </p> <p> 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.<br/> </p> <p> <strong>Ausblick</strong><br/> </p> <p> 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 kann die bisherige 16-Bit-AS-Nummer nach außen behalten. Die anderen Inseln bekommen nach außen jeweils eine 32-bit-AS-Nummer nach obigem Vergabemuster zugewiesen. <br/> </p> </div>