mk16.de/blog/crxn-dn42-interconnection-de.md

---

layout: page title: Die CRXN/DN42 Interconnection ist up! permalink: /blog/die-crxn-dn42-interconnection-ist-up/ keywords: crxn,netzwerk,ipv6,routing,babel,dn42,interconnection,bgp,connection,bgp vs babel,default route vs full table,blog description: Endlich ist die CRXN/DN42 Interconnection up. In diesem Blog Eintrag schreibe ich, wie es zur der Idee gekommen ist, wie man die Zustimmung der dn42 Community fand und wie das ganze implementiert ist. lang: de feed: true

date: 2023-01-30 00:00:00 +0100

Nach etwa zwei Monaten gibt es nun endlich eine Interconnection zwischen dem CRXN-Netzwerk und dem dn42-Netzwerk.

• Anfang / Idee
• Konsens
• Synchronisierung
• Routen aus CRXN in dn42
• Routen aus dn42 in CRXN

Anfang

Die Idee kam im Matrix Raum von CRXN auf. Das CRXN Netzwerk ist recht klein und hat daher sowohl wenig Routen als auch wenig Inhalt. Das dn42 hat wiederum viel Inhalt zu bieten. Es wäre also schön, wenn man vom CRXN aus im dn42 surfen könnte. Des Weiteren könnte man so auch vom dn42 auf Inhalte im CRXN zugreifen. Darüber hinaus macht es Spaß :-)

Konsens

Ein recht nerviger, aber notwendiger Schritt. Um größere Dinge umzusetzen, braucht man die Zustimmung der Community. Die CRXN Community (bestehend aus ca. 5 Personen) hat zugestimmt, jedoch ist die dn42 Gemeinschaft viel größer. Daher wurde die Interconnection auf der dn42 Mailing Liste zur Diskussion vorgeschlagen. Des Weiteren gab es ein Meeting auf Mumble. Nach ca. einem Monat wurde ein Konsens erreicht: Die Interconnection darf stattfinden.

Synchronisierung

Das "Problem" an dieser Interconnection ist, das dn42 und CRXN unterschiedliche Routing Protokolle verwenden. dn42 benutzt das EGP BGP und CRXN das IGP babel. Eine ausführliche Beschreibung, wie die Interconnection funktioniert, kann man auf CRXN / dn42 gateway documentation in Englisch finden. Die Zusammenfassung ist, dass die CRXN Routen in dn42 unter der AS-Nummer 4242423182 announct werden.

Entsprechend werden die Präfixe in die dn42 Registry übernommen. Für jedes Präfix wird ein inet6num-Objekt und ein route6-Objekt erstellt. In das route6-Objekt wird - falls angegeben - auch die max-len mit übernommen. Des Weiteren werden - wenn vorhanden - auch Personen-Objekte übernommen. Darüber hinaus gibt es ein Community-Objekt (COMMUNITY-CRXN) in der dn42 registry. In dem Objekt stehen die verschiedenen Orte (Matrix und IRC) in denen man mit der CRXN Community in Kontakt treten kann.

Die ganze Synchronisierung wurde von jrb0001 implementiert. Vielen Dank dafür!

Routen aus CRXN in dn42

Um als Gateway zu fungieren, muss man in beiden Netzen präsent sein. Ich beispielsweise erfülle diese Voraussetzung. Dann nimmt man die CRXN Routen und "tut so, als ob sie von AS4242423182 kommen würden" und propagiert sie weiter zu seinen Peers. Wenn ich die CRXN Routen also an einem meiner Gateways empfange, nehme ich sie, hänge an den (noch leeren) AS-Pfad 4242423182 an und verbreite diese weiter in dn42. Damit hat es von außen den Anschein, dass alle CRXN Routen von einem AS kommen würden.

In bird kann man die ganz einfach mit folgendem Absatz im Export-Filter bewirken:

if ( is_crxn_net() ) then {
    bgp_path.prepend(CRXNAS);
}

Man kann dabei nicht nach Präfix unterscheiden, zu welchem Netz, welche Route gehört, da das dn42 und das CRXN Netzwerk sich den ULA-Raum fd00::/8 teilen. is_crxn_net ist dabei eine Funktion, die überprüft, ob ein Netz zum CRXN-Netzwerk gehört und wenn das der Fall ist, true zurückgibt.

Ich habe die Funktion um folgendes erweitert:

if ( is_crxn_net() ) then {
    bgp_path.prepend(CRXNAS);
    if (babel_metric > 200) then {
        bgp_path.prepend(CRXNAS);
    }
}

Falls die Babel Metrik größer als 200 ist - ich also eine recht schlechte Anbindung zum Präfix habe - mache ich ein Path Prepending. Durch den längeren AS-Pfad mache ich mich dadurch unattraktiver. Sollte ein anderes Gateway nun das Präfix mit einer Metrik von unter 200 empfangen, sollte man über das andere Gateway gehen. Durch den kürzeren AS-Pfad vom anderen Gateway wird das erzielt.

Routen aus dn42 in CRXN

Die offensichtliche Methode, dies zu tun, ist die Präfixe aus dem dn42 - welche via BGP übertragen wurden - zu nehmen und in das CRXN - welches babel verwendet - zu senden. Dies bedeutet, man propagiert dann auch die dn42 Präfixe und tut damit so als wären es die eigenen Routen. Über die Babel Metrik können dann CRXN Teilnehmer entscheiden, welches Gateway besser ist. Diese Methode habe ich auch zuerst versucht, jedoch hat sie einige Probleme mitgebracht:

1. Enorm, enorm große Tabellen. Groß ist natürlich releativ, aber die dn42 Routing Table über 700 IPv6 Einträge ist größer als die CRXN Routing Table mit ca. 20 Einträgen. Entsprechend ist die CRXN Routing Tabelle sinnbildlich "explodiert". babelweb2 - einer Monitoring und Debugging Software, welche über ein Webinterface erreichbar ist - hat mehrere Minuten gebraucht um die Tabelle zu laden. Dies ist auf Dauer sehr nervtötend. Im CRXN Matrix Raum wurde der Vorschlag genannt, die Software zu optimieren, jedoch fehlt es dafür an Wissen, Kapazitäten und dem Nutzen. Der Vorschlag wurde also verworfen.
2. Es ist enorm schwer, einfach Filter für dieses Szenario zu erstellen. Ohne dn42 hat man ca. 20 Präfixe man filtern kann. Mit dn42 hat man über 700 Präfixe. Möchte man nun einen Filter dafür erstellen, so braucht man sowohl die CRXN Präfixe als auch die dn42 Präfixe. Jedoch ist es wünschenswert, die dn42 Filterung an die Gateways auszulagern. Dies bedeutet, die CRXN Teilnehmer sollten CRXN Routen filtern und keine dn42 Routen. Dies bedeutet, man muss die Präfixe der beiden Netzwerke unterscheiden. Diese Information kann aufgrund der Natur von Babel nicht von den Gateways mitgeteilt werden. Um das zu lösen, brächten die CRXN Teilnehmer jedoch extra eine Liste aller dn42 Routen. Jedoch gilt es genau dies zu vermeiden. Komplexere nicht-Ja-Nein-Filter sind des Weiteren nicht in allen Implementierungen möglich. bird stellt umfangreiche Methoden bereit, um Filter zu erstellen. So kann man wie in der Programmierung andere Dateien inkludieren, if-else if-else Anweisungen und Variablen benutzen. In babeld sind dagegen nur Ja-Nein-Filter möglich. babeld arbeitet in dieser Hinsicht ähnlich wie eine Firewall. babeld liest die Regeln von oben nach unten und führt die entsprechende Aktion (allow/deny) aus. Das Speichern von Zwischenergebnissen ist dabei nicht möglich. Damit man also in babeld CRXN und dn42 Routen unterscheiden kann, müsste man alle dn42 Routen in die Konfigurationsdatei schreiben. Wenn man stattdessen einfach alle Routen akzeptiert, kann man keine (maxlen) Filterung der CRXN Routen mehr machen.
   • Die entitydb (das Registry von CRXN) ist frei im Internet zugänglich. Jeder kann die Informationen dort einsehen. Um die Daten aus der entitydb zu holen, kann man das Repository mit Git klonen und als ZIP-Datei herunterladen. Bei dem dn42 registry ist das leider etwas anders. Auch das dn42 Registry basiert auf Git, weshalb prinzipiell die gleichen Methoden zum Holen der Informationen zur Verfügung stehen. Jedoch steht das dn42 Registry hinter einer Account-Wall. Man muss sich also zuerst anmelden, um auf das Registry zugreifen zu können. Wenn man das Git Repository klonen möchte, muss man erst einen SSH-Schlüssel hinterlegen und kann dann mit diesem darauf zugreifen. Meiner Meinung nach, ist die ganze Maßnahme sinnlos, dass man über die APIs einen JSON Dump der Registry bekommen kann: hier oder hier

Es gibt verschiedene Möglichkeiten, dieses Problem zu lösen:

1. Präfix-basierte Filterung: Das CRXN-Netzwerk sucht sich ein /32-Präfix im ULA-Bereich aus und allokiert nur noch aus diesem Bereich. Dies würde ein aufwendigen Renumbering zur Folge haben, weshalb diese Option von Teilen der CRXN Community abgelehnt wird.
2. Default-Route: Statt den einzelnen dn42-Präfixen kann man auch eine allgemeine Route - sogenannte Default Route - fd00::/8 in CRXN annoncen. Wenn kein genaueres Präfix bekannt ist, wird die Anfrage dann an diese Adresse gesendet. fd00::/8 wird dabei nur von den Gateways propagiert. Diese können die Anfrage dann entsprechend weiter in dn42 leiten.
   • Diese Methode hat zwei Nachteile: Einmal kann der Router von einem CRXN Teilnehmer nicht selbst entscheiden, ob es einen Weg gibt. Eine ICMP Unreachable Nachricht müsste also vom Gateway kommen. Wenn ein Router dann nicht konfiguriert ist, könnte er keine ICMP Nachricht generieren und die Anfrage würde auf ein Timeout hinauflaufen. Des Weiteren sollte es die Aufgabe von Routern sein, eine Übersicht über das gesamte Netzwerk zu haben und damit selbst entscheiden zu können, ob ein bestimmtes Präfix erreichbar ist oder nicht - das sollte nicht die Aufgabe der Gateways sein. Die Gateways sind eher als eine Art "Übersetzer" gedacht, welche zwischen den unterschiedlichen Routing Protokollen vermitteln.

Angenommen die Gateways speisen die dn42 in CRXN ein, so ist es einem CRXN Teilnehmer zwar aufgrund der Babel Metrik immer möglich den besten Weg zum nächsten Gateway zu finden, jedoch bedeutet dies nicht zwingend, dass das der beste Weg zum Ziel ist. So kann Gateway A beispielsweise mit dem Ziel AS in dn42 gepeert sein und Gateway B kann das Ziel AS erst über mehrere andere ASs erreichen, jedoch entscheidet sich der CRXN Teilnehmer aufgrund der Babel Metrik für das Gateway B. Dieses Problem könnte man lösen, indem man die Babel Metrik anhand der AS-Pfad-Länge berechnet, jedoch bin ich mir unsicher, ob dies technisch möglich ist, anderseits kann dies die Schleifenfreiheit von Babel gefährden. Dieses Problem, jedoch ohne potenzielle Lösung, tritt auch bei der Default Route auf.

Abwägung

Eine Abwägung zwischen Full Table und Default Route zu treffen, ist schwer. So haben beide Methoden Vor- und auch Nachteile. Prinzipiell wäre auch eine Mischung möglich - also Full Table + Default Route. Für die CRXN Teilnehmer, welches jedoch Default Route wählen und andere nicht-CRXN-Präfixe filtert, kann die Filterung zu einer höheren CPU Leistung führen. Des Weiteren würde ein solcher Knoten die nicht-CRXN-Präfixe nicht weiterpropagieren. Das Gleiche gilt für Full Table: Ein Knoten, welcher Full Table nimmt, aber die Default-Route ablehnt, würde die Default-Route nicht weiter verteilen.

Ich denke, dass eine optimale Interconnection aufgrund der unterschiedlichen Natur vom EGP BGP und vom IGP Babel nicht möglich ist. Daher sollte man sich fragen, wie die Interconnection dann aussehen könnte. Aufgrund des geringen Aufwandes, bin ich ein Freund der Lösung mit der Default Route - wie oben beschrieben, verschwinden dadurch aber nicht alle Probleme.

So oder so, sind das CRXN und dn42 Projekte zum Lernen und Spaß haben. Habt also schön viel Spaß mit der Interconnection!

Nachtrag 1: Tristan aka deavmi, der Initiator der CRXN, hat auch einen Blogeintrag geschrieben: Announcing the CRXNxDN42 inter-connect!