---
title: Roadmap für die Weiterentwicklung der IGP-Kopplung
categories: Projekte Routing VPN
format: DocBook
...

<article>
  <articleinfo>
    <title>Roadmap für die Weiterentwicklung der IGP-Kopplung</title>
  </articleinfo>

  <simpara>
  Dieses Dokument dient als Statusbericht und zur Planung und Kooperation bei der konkreten Implementierung und Weiterentwicklung der IGP-Kopplung. Zur Herleitung dieses Routingkonzepts für Freifunk-Netze siehe den Text zum Multi-Exit-Problem, auch genannt <ulink url="Fussgaengerzonenproblem">Fußgängerzonenproblem</ulink> (<ulink url="Fussgaengerzonenproblem-Zusammenfassung">Zusammenfassung</ulink>).
  </simpara>

  <section id="routing">
    <title>Routing</title>
    <simpara><emphasis role="strong">Status:</emphasis> - </simpara>
    <simpara><emphasis role="strong">Aufgaben:</emphasis> </simpara>
    <simpara>Erstellung einer (mit den Teilnehmenden wachsenden) Einführung in das Thema dynamisches Routing:</simpara>
    <itemizedlist>
      <listitem>
        <para>
        als Text, mit repository für Text und config und src, sowie ggf. passende Laborfirmware (zB à la <ulink url="https://libremesh.org/">Libre-Mesh</ulink>).
        </para>
      </listitem>
      <listitem>
        <para>
        Unterthemen: Routing im Internet mit großem I (OSPF, BGP). Routing für den Freifunk, d.h. u.a. WLAN-adhoc-Meshes (OLSR, Babel, B.A.T.M.A.N.), leistungsschwache Router, Communities. Mit Beispielen aus dem FF und insb. Übungen zum "Routing Selbermachen" mit üblicher Hardware.
        </para>
      </listitem>
      <listitem>
        <para>
        Ziel der Einführung: Eigenhändiger Anschluss der Geräte der Routing-Adepten (m/w/d) an das dynamische Routing der FF-(Übungs-)Netze. Dadurch leichteres Verstehen des eigenen (FF-)Netzes. Befähigung zum Analysieren und Lösen von Routingproblemen, und ggf. zum Verbessern und Weiterenwickeln des FF-Routings.
        </para>
      </listitem>
    </itemizedlist>
  </section>
 
  <section id="IGP-Kopplung">
    <title>IGP-Kopplung</title>
    <simpara><emphasis role="strong">Status:</emphasis> Laborbetrieb (bewohnbar;)</simpara>
    <simpara>Etwas Visualisierung dazu gibt's auf diesem Grafana-<ulink url="http://mesh-j-5.free.de:3000/dashboard/db/neuer-ff">Dashboard</ulink>. Hier ein Schnappschuss des zeitlichen Verlaufs von Metriken, die durch den Import von Babel nach OSPF entstehen:</simpara>
    <mediaobject>
     <imageobject role="html-png">
      <imagedata contentwidth="600px" align="center" fileref="http://mesh-j-5.free.de:3000/render/dashboard-solo/db/neuer-ff?orgId=1&amp;var-host=wrap15&amp;panelId=4&amp;width=600&amp;height=300&amp;theme=light" format="PNG"/>
     </imageobject>
     <textobject>
      <phrase>Bild, PNG: routes der IGP-Kopplung als Verlaufsgrafik</phrase>
     </textobject>
    </mediaobject>
    <simpara><emphasis role="strong">Aufgaben:</emphasis> </simpara>
      <itemizedlist>
        <listitem>
          <simpara>
          Aktualisierung des praktischen Teils des Textes "<ulink url="Fussgaengerzonenproblem">Fußgängerzonenproblem</ulink>": die zZ in Betrieb befindliche Konkretisierung der IGP-Kopplung enthält kleinere Korrekturen, Verbesserungen und insb. die für den realen Betrieb wichtige Integration von Babel-Metriken. Diese Fortschritte gegenüber der Version zu den FF-RL-Routing-Days sind noch nicht dokumentiert.
          </simpara>
        </listitem>
        <listitem>
          <para>
          Bird attitude readjustment:-) Notwendige und wünschenswerte patches sind nach bisheriger Erfahrung mit der IGP-Kopplung:
            <itemizedlist>
              <listitem>
                <simpara>
                OSPF &lt;-&gt; OSPF redistribution ermöglichen. Höchste Priorität, denn dies macht die Einfachheit der Idee "IGP-Kopplung" durch massive Vereinfachung gegenüber der jetzigen Bird-Konfiguration sichtbar und wirksam.
                </simpara>
                <simpara>
                [Update 2019-03] Seit Bird 2.0.3 ist redistribution nach OSPF theoretisch repariert. Damit das auch praktisch funktioniert und die Vereinfachung der Konfiguration möglich wird, braucht es zZ aber noch den folgenden kleinen patch gegen den aktuellen Bird Quelltext:
                </simpara>
                <literallayout>--- proto/ospf/topology.c.orig	2019-02-28 23:10:05 UTC
+++ proto/ospf/topology.c
@@ -1312,11 +1312,12 @@ ospf_rt_notify(struct proto *P, struct channel *ch UNU
     m2 = LSINFINITY;
   }
 
+  uint ebit = (m2a &amp;&amp; m2a->u.data > 0) || !m1;
+
   /* Ensure monotonicity of metric if both m1 and m2 are used */
-  if ((m1 &gt; 0) &amp;&amp; (m2 &lt; LSINFINITY))
+  if (ebit &amp;&amp; (m1 &gt; 0) &amp;&amp; (m2 &lt; LSINFINITY))
     m2++;
 
-  uint ebit = m2a || !m1a;
   uint metric = ebit ? m2 : m1;
   uint tag = ea_get_int(a->eattrs, EA_OSPF_TAG, 0);
 
</literallayout>
                <simpara>
                Mittlerweile sind alle Router in der IGP-Kopplung auf den aktuellen (gepatchten) Bird mit vereinfachter Konfiguration umgestellt, incl. derjenigen, die mit den BGP-uplink-Routern OSPF sprechen. Das hat bereits zu einem spürbar stabileren Routing beigetragen.
                </simpara>
              </listitem>
              <listitem>
                <formalpara id="Routenaggregation">
                  <title>Routenaggregation</title>
                  <simpara>
                  Bird hat keinen Mechanismus zur Routenaggregation. Dadurch wurden bisher die vielen host routes aus der IGP-Kopplung auch ins OSPF des anderen Teils des AS31371 verteilt.
                  </simpara>
                  <simpara>
                  [Update 2019-03] Hilfsweise gibt es jetzt eine gebaumarktete Routenaggregation. Dabei werden statische Routen für die zu aggregierenden Adressbereiche erzeugt. Diese werden zum einen in das "externe" OSPF und zum anderen als unreachable routes in die primäre FIB des kernels exportiert (als Senke für Pakete mit aggregierter aber unerreichbarer Zieladresse). Die nach "extern" exportierte Metrik einer Aggregatroute wird von einem cron script in eine Bird-Konfigurationsdatei geschrieben. Dabei werden die Metriken aller Routen aus dem aggregierten Adressbereich aus Bird ausgelesen liest und der Mittelwert berechnet. Dies hat zu einem stabileren Routing zwischen den beiden Teilen des AS31371 beigetragen.
                  </simpara>
                  <simpara>
                  Wünschenswert bleibt ein im Bird selbst implementierter Mechanismus zur Routenaggregation, etwa als erweitertes pipe protocol. [Update 2023-10] Neuerdings gibt es im Bird ein Aggregator protocol, aber das aggregiert nur Routen, die sich auf denselben Präfix beziehen. Was wir hier aber brauchen, sind Aggregatrouten, in die verschiedene (Sub-)Präfixe einfließen.
                  </simpara>
                </formalpara>
              </listitem>
              <listitem>
                <simpara>
                Einführung eines Routenattributes "common_metric", das als tie-braker bei Routen gleicher preference fungiert, wenn es vorhanden ist. Dadurch können auch Routen aus verschiedenen IGPs gemäß einer gemeinsamen (globalen) Metrik verglichen werden. Dies stellt eine Voraussetzung für eine hererogene IGP-Kopplung dar, also dass verschiedene IGPs gleichzeitig genutzt und gekoppelt werden.
                </simpara>
              </listitem>
              <listitem>
                <simpara>
                Ggf. Optimierung der Interaktion von Bird und Kernel: bei den häufigen Routenänderungen in einer IGP-Kopplung mit dynamischen Metriken sollten die von Bird durchgeführten Änderungen an der FIB des Kernels minimiert werden, also insb. sollte nur dann eine Routenänderung erfolgen, wenn sich das gateway geändert hat, nicht nur der Metrikwert. Eine FIB-Änderung sollten in einem Schritt erfolgen (change) statt in zweien (delete + add).
                </simpara>
              </listitem>
              <listitem>
                <simpara>
                Die für die "Schleifenbits" der IGP-Kopplung benötigte Bitarithmetik könnte direkt in die filter language von Bird als elementare Operationen eingebaut werden.
                </simpara>
              </listitem>
            </itemizedlist>
          </para>
        </listitem>
        <listitem>
          <para>
          Babel attitude readjustment:-) Notwendige und wünschenswerte patches des babeld sind nach bisheriger Erfahrung:
            <itemizedlist>
              <listitem>
                <simpara>
                IP-Adressen, die auf einem Interface liegen, auf dem babeld läuft, sollten von babeld auch auf diesem Interface geroutet werden. (Der jetzige Zustand erscheint eher als bug denn als feature.)
                </simpara>
              </listitem>
              <listitem>
                <simpara>
                Erweiterung von Babel um die "Schleifenbits", oder Verallgemeinerungen davon. (S. <ulink url="https://tools.ietf.org/html/rfc7557">Extension Mechanism for the Babel Routing Protocol</ulink>.)
                </simpara>
              </listitem>
            </itemizedlist>
         </para>
        </listitem>
    </itemizedlist>
  </section>
  <section id="dDHCP">
    <title>dDHCP (verteiltes DHCP)</title>
    <simpara><emphasis role="strong">Status:</emphasis> Laborbetrieb (bewohnbar;)</simpara>
    <simpara><emphasis role="strong">Aufgaben:</emphasis> </simpara>
    <itemizedlist>
      <listitem>
        <simpara>
        In der jetzigen (extrem gebaumarkteten) Implementierung eines <ulink url="/Technik/Routing/Fragen#verteiltes-dhcp-durch-routing">durch Routinginformationen vermittelten dDHCP</ulink> fehlt noch die Konfliktauflösung nach Partitionierungen einer IGP-Kopplung. Dafür sollte zunächst ein geeigneter, d.h. insb. verteilter Entscheidungsalgorithmus formuliert werden, der (zB durch ein totale Ordnungsrelation auf den dDHCP-Routen der IGP-Kopplung) regelt, welche lease gültig bleibt und welche lease(s) von den entsprechenden dDHCP-Servern (Routern) autonom verworfen werden müssen. Das resultierende Verfahren könnte mit der Konvergenzgeschwindigkeit des Routings nach dem Wegfall einer Partitionierung den dDHCP-Adressbereich wieder konfliktfrei machen - wenn da nicht die Gültigkeitsspanne der ausgebenen leases wäre. Falls also globale Partitionierungen in einer konkreten IGP-Kopplung ein reales Problem darstellen, sollte die lease time möglichst klein gewählt werden, um die Auswirkungen auf die von IP-Adresskonflikten betroffenen clients zu minimieren, wg. "betroffen" = "keine Connectivity über den AP hinaus", also der GAU für den client.
        </simpara>
      </listitem>
      <listitem>
        <para>
        ISC-dhcpd attitude readjustment:-) Für die zZ implementierte Nutzung des ISC-dhcpd für dDHCP waren unschöne Workarounds nötig, die durch vmtl. kleine Eingriffe (patches) vermieden werden könnten, was auch seriöseren Implementierungen eines dDHCP-mit-ISC-dhcpd nutzen könnte.
          <itemizedlist>
            <listitem>
              <simpara>
              Mehr Informationen über eine lease an die getriggerten (on commit/on expiry) Skripte oder Daemons übergeben, die sich dann um das "d" in "dDHCP" kümmern.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
              Bessere Abfragemöglichkeiten für leases und host entries in der lease DB.
              </simpara>
            </listitem>
          </itemizedlist>
        </para>
      </listitem>
      <listitem>
        <simpara>
        Entwicklung eines Daemons, der zwischen Bird und ISC-dhcpd vermittelt und die jetzigen Shell-Skripte (sic!) für das dDHCP ablöst. Dann könnten auch Caching (gegen Wackelkontakte im Routing) und Konfliktauflösung (gegen die Auswirkungen von globalen Partitionierungen, s.o.) leichter implementiert werden.
        </simpara>
      </listitem>
      <listitem>
        <simpara>
        Alternativ zu allem obigen könnte man auch einen eigenständigen dDHCPd versuchen (zB <ulink url="/Technik/Routing/Fragen#verteiltes-dhcp-im-mesh">pyddhcpd</ulink>, <ulink url="https://git.toppoint.de/sargon/ddhcpd/">ddhcpd</ulink>) oder selbst entwickeln. Gegen Letzteres spricht der Aufwand, das Rad neu zu erfinden, und für dDHCP mit ISC-dhcpd spricht die Verbreitung des ISC-dhcpd, die eine oft leichte Integrierbarkeit des dDHCP in bestehende Umgebungen verspricht. Außerdem kann der ISC-dhcpd auch Einiges, was es FF-Routernutzerinnen (m/w) erleichtert, DHCP-bezogene Spezialaufgaben vor Ort mit einem Standard-FF-Router und ohne Installation eines weiteren DHCPd zu lösen.
        </simpara>
      </listitem>
    </itemizedlist>
  </section>
  <section id="Konfiguration">
    <title>Konfiguration</title>
    <simpara><emphasis role="strong">Status:</emphasis> Laborbetrieb (bewohnbar;)</simpara>
    <simpara><emphasis role="strong">Aufgaben:</emphasis> </simpara>
    <itemizedlist>
      <listitem>  
        <para>
        Format(e) für Konfigurationen.
          <itemizedlist>
            <listitem>
              <simpara>
              Die jetzige Implementierung (im Stil der Oldowan-Kultur) mit awk und sed reicht für das Aufsetzen von Standardroutern, die sich nur bzgl. RouterID und den resultierenden Adressen (IP und MAC) unterscheiden. Die Konfiguration für einen Router generiert dieser Router selbst mit Hilfe der o.g. Faustkeile aus einem generischen tarball, welcher Konfigurationstemplates und Shell-Skripte für diesen Zweck enthält. Die Konfigurationstemplates sind statisch und enthalten konstante Makrostrings, woraus das Generieren der konkreten Konfiguration mit sed und einem generierten sed-Skript erfolgt. Einige lokale Anpassungen der Routerkonfiguration können per rc.conf erfolgen, andere über eigene Konfigurationsdateien, welche die generierten default Konfigurationen ersetzen können, ohne erstere zu löschen (dank einer Oldowan-symlink-Methode). Das ist zwar etwas mühsam, aber für die endlich vielen Router eines Laborbetriebs ausreichend. Was auf dieser Ebene initialer Konfiguration zZ noch fehlt, ist die Generierung von Tinc-Nachbarschaften über Connect-To Einträge in allen tinc.conf Dateien der zZ drei Tinc-Instanzen eines Routers.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
              Diese primitive Mechanik ist dahin weiterzuentwickeln, dass die Konfigurationstemplates selbst aus semantischen Konstanten (Hardware-Kennungen, Benutzerinput, ...) erzeugt werden. Dazu dürfen nur Bordmittel des Router-Images benutzt werden und die Entwicklung muss mindestens ermöglichen, dass der Router ans Netz kommt, seinen Job als Router macht, wartbar bleibt, und "höhere" Konfigurations- und Installationsmechaniken bootstrappen kann.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
              Ein Verteilungssystem für die Konfigurationsmechanik ist zu entwickeln. Nur Bordmittel, aber incl. einer minimalen Versionsbehandlung, die für automatische oder ferngetriggerte Aktualisierungen der Basiskonfiguration(smechanik) ausreicht. Das Verteilungssystem sollte im Geiste der IGP-Kopplung auch selbst ein verteiltes System sein.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
              Für die o.g. "höhere" Konfigurations- und Installationsmechanik sollte ein möglichst abstraktes Konfigurationsformat entwickelt werden, das mächtig genug ist, alle relevanten Schemata bedienen zu können. Eine gelungene Abstraktion erleichtert die Integration neuer Konfigurationen und die Portierung auf weitere Betriebssysteme. Um diese Abstraktheit zu erreichen wird vmtl. eine DSL (domain specific language) gebraucht.
              </simpara>
            </listitem>
          </itemizedlist>
        </para>
      </listitem>
      <listitem>
        <simpara>
        UI (Benutzerinterface) für die o.g. Konfigurationen. D.h. sowohl für Basiskonfigurationen als auch für "höhere" Konfigurationen, zunächst als Konsolentool, später zusätzlich als Webinterface. Das Konsolentool sollte im initialen Router-Image enthalten sein (Bordmittel). Im fortgeschrittenen Stadium sollte die UI selbst passend zu den Konfigurationen generierbar sein.
        </simpara>
      </listitem>
      <listitem>
        <simpara>
        Dokumentation der Konfigurationen und ihrer Bedeutungen, sowie des UI. Die Doku für die Basiskonfigurationen sollte im initialen Router-Image enthalten sein (Bordmittel:). Modulares und generierungsfreundliches Dokumentationsformat, zur leichteren Erweiterung (neue Konfigurationen) und Portierung.
        </simpara>
      </listitem>
    </itemizedlist>
  </section>

  <section id="Automatisierung">
    <title>Automatisierung</title>
    <simpara><emphasis role="strong">Status:</emphasis> -</simpara>
    <simpara><emphasis role="strong">Aufgaben:</emphasis> </simpara>
    <para>
    Zum Verlassen des Labors, d.h. für eine Verwendung der IGP-Kopplung in der Breite (incl. Plasterouter), werden automatisierte Konfigurationsmethoden unverzichtbar sein. Diese sollten selbst als "höhere" Konfiguration von der o.g. "höheren" Konfigurationsmechanik verwaltbar sein. Die folgenden Ziele können als Orientierung für dieses Teilprojekt dienen:
      <itemizedlist>
        <listitem>
          <simpara>
          Ein Router mit installierter und konfigurierter Automatisierungsmechanik kann sich selbst mit dieser Mechanik konfigurieren und updaten, incl. der Automatisierungsmechanik. Einen solchen Router nennen wir Automatisierungsrouter. Die Mechanik kann dabei auch auf andere "höhere" Konfigurationen und zugehörigen Installationen (packages) zurückgreifen, sodass zB Konstanten der IGP-Kopplung aus dem lokalen clone eines verteilten repository's geholt werden können.
          </simpara>
        </listitem>
        <listitem>
          <simpara>
          Ein Automatisierungsrouter kann einen anderen Router (auf entsprechende Anfrage oder Anweisung) installieren, konfigurieren und updaten. Dazu sollten auf dem zu wartenden Router nur die unbedingt nötigen Hilfsmittel vorausgesetzt werden.
          </simpara>
        </listitem>
        <listitem>
          <simpara>
          Konfigurations- und die darauf aufbauende Automatisierungsmechanik müssen so strukturiert sein, dass Autonomie auf allen Ebenen (Router, IGP-Instanz (Mesh), IGP-Kopplung (Intermesh)) ohne Nervenzusammenbrüche gelebt (konfiguriert;) werden kann. D.h. einfache, dokumentierte Schnittstellen zwischen Maschinerie und lokalem Bediener, ebenso zwischen den Ebenen. Die (Konfigurations- und Automatisierungs-)Maschinerien sollten sich für die Bedienerin "anfühlen" wie ein solides Werkzeug, mit dem man seine Vorstellungen über das Netz und seinen Betrieb umsetzen kann.
          </simpara>
        </listitem> 
      </itemizedlist>
    </para>
  </section>

  <section id="Portierung">
    <title>Portierung</title>
    <simpara><emphasis role="strong">Status:</emphasis> -</simpara>
    <simpara><emphasis role="strong">Aufgaben:</emphasis> </simpara>
    <itemizedlist>
      <listitem>
        <para>
        Die bisherige Implementierung der IGP-Kopplung läuft auf FreeBSD als Werkstatt, mit i386 und amd64 als Hardware. Die Implementierung wird bei Bedarf und als Teil des laufenden Betriebes weiterentwickelt. Damit das Konzept Verbreitung und damit auch die Hoffnung auf Verbesserung findet, wird es auch auf andere Plattformen portiert werden müssen:
          <itemizedlist>
            <listitem>
              <simpara>
              Zunächst könnte man versuchen, einfach FreeBSD für ARM Prozessoren (zB RasPi) unter die bisherige Implementierung zu schieben. Das wäre vmtl. die einfachste Variante, um die Hardware-Basis für eine IGP-Kopplung zu erweitern.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
              Linux-Distributionen, insb. Debian und OpenWRT. Hier sind vmtl. vor allem zwei Hürden zu nehmen: Erstens verschiedene Installations- und Konfigurationsmethoden, wobei die o.g. Konfigurations-DSL o.dgl. helfen sollte. Zweitens die Unterschiede zwischen FreeBSD und Linux hinsichtlich der forwarding tables im jeweiligen Kernel. Auch wenn sich die Details unterscheiden, so haben die beiden Kernelarten doch das Wesentliche gemeinsam: longest prefix matching und mehrere forwarding tables. Die dadurch ermöglichten Komponenten (mehrere Tinc-Instanzen, mehrere Babel-Instanzen (und -Metriken), Bird mit mehreren Instanzen seines kernel protocol, dDHCP) reichen für die bisherige Implementierung der IGP-Kopplung. Diese sollte sich also mit übersichtlichem Aufwand auf eine Linux-Distribution portieren lassen.
              </simpara>
            </listitem>
          </itemizedlist>
        </para>
      </listitem>
      <listitem>
        <simpara>
        IPv6. Ist in der bisherigen Implementierung nur deshalb vertreten, weil Babel auf IPv6 zum Austausch seiner Routinginformationen besteht. Dem Routingkonzept ist es egal, ob es auf IPv4 oder IPv6 implementiert wird. Der vmtl. wesentliche Unterschied dürfte sein, dass wie man hört viele Konsumentengeräte kein DHCPv6 implementieren, sodass man statt DHCP für IPv6 spezifische Mechanismen verwenden muss:-(
        </simpara>
      </listitem>
    </itemizedlist>
  </section>

  <section id="Betrieb">
    <title>Betrieb</title>
    <simpara><emphasis role="strong">Status:</emphasis> Laborbetrieb (bewohnbar;)</simpara>
    <para>
    Das Versuchsnetz zur IGP-Kopplung umfasst <emphasis role="strong">23 Router</emphasis> (Stand 2023-10). Davon sind
      <itemizedlist>
        <listitem>
          <simpara>7 ALIX, 12 APU, 1 VM, 2 Futro, 1 Laptop.</simpara>
        </listitem>
        <listitem>
          <para>
            16 im Dauerbetrieb, davon wiederum sind
            <itemizedlist>
              <listitem>
                <simpara>12 im VPN-Mesh (IGP 3),</simpara>
              </listitem>
              <listitem>
                <simpara>11 in einem LAN-Mesh (IGP 1),</simpara>
              </listitem>
              <listitem>
                <simpara>6 in einem WLAN-Mesh (IGP 2).</simpara>
              </listitem>
              <listitem>
                <simpara>3 OSPF-Nachbarn von BGP-uplink Routern (IGP 4 und 6). S. dazu oben <link linkend="Routenaggregation">Routenaggregation</link>.</simpara>
              </listitem>
            </itemizedlist>
           </para>
        </listitem>
        <listitem>
          <simpara>7 Router dienen auch als Host für jails (u.a. für <ulink url="/DiesesWiki/Instanzen/Liste">Instanzen des FF-DO-Wiki</ulink>).</simpara>
        </listitem>
        <listitem>
          <simpara>7 Router sind mit Monitoring beschäftigt (insb. für das Richtfunknetz, s. die Grafiken auf den <ulink url="/Technik/Richtfunk/Standorte/">Standortseiten</ulink>).</simpara>
        </listitem>
      </itemizedlist>
    </para>
    <simpara><emphasis role="strong">Aufgaben:</emphasis> </simpara>	  
    <itemizedlist>
        <listitem>
          <simpara>
          Tinc attitude readjustment:-) Gelegentlich "verklemmt" sich ein tincd, was zZ per cron erkannt und behandelt wird (= Restart des entsprechenden tincd). Das Verklemmen sollte erforscht und behoben werden. Ebenso gibt es Abstürze von tincd, wobei ein sofortiger Restart mittlerweile durch daemon(1) erfolgt, was die Stabilität des Routings verbessert hat.
          </simpara>
        </listitem>
      <listitem>
        <para>
        IP-Ressourcen und Routing. ZZ werden nur IPv4-Adressen genutzt, und zwar ein /24 des AS31371, und davon ein /26 für dDHCP clients. Das jetzige Implementierungskonzept erlaubt max. 30 Router und wurde primär für den Entwicklungsbetrieb = Testbetrieb gewählt.
          <itemizedlist>
            <listitem>
              <simpara>
              Spätestens bei einem durch Automatisierung ermöglichten Wachstum der realen IGP-Kopplung müssen weitere IPv4-Ressourcen her. (Die übliche Alternative NAT will man nicht im Kontext eines ausufernd horizontalen und autonomiebetonten Routings wie der IGP-Kopplung.) Dafür stünde direkt verfügbar noch ein /23 des AS35675 zur Verfügung. Da dieses Erbstück das AS31371 zum uplink hat, wäre diese Konstellation eine stressfreie Gelegenheit, erste IGP-Kopplungskonfigurationen zu entwickeln und erproben, die sich über mehr als ein AS erstrecken. Dazu muss man sich mit dem konsistenten Filtern und Aggregieren von Routen an IGP-Grenzen beschäftigen. Perspektivisch wird man sich auch mit der RIPE-DB und der Bürokratie beschäftigen müssen, um ausreichend IPv4-Ressourcen für die dereinst wuchernden IPG-Kopplungen zu erheischen:-) [Update 2023-10] Das AS35675 wird mittlerweile produktiv vom Freifunk Dortmund und dessen Lernprojekt <ulink url="/Community/Bildung/FF@home/">FF@home</ulink> genutzt. Die IPG-Kopplung tauscht mit beiden (teils aggregierte) Routen aus und fungiert auch als verbindender Transit zwischen ihnen.
              </simpara>
            </listitem>
            <listitem>
              <simpara>
              Genug IPv6 Adressen könnten direkt vom FF-DO kommen, der sie vom FF-RL hat, [Update 2023-10] aber mittlerweile als AS35675 auch ein eigenes /48. Perspektivisch braucht es mindestens einen global routebaren IPv6-Präfix (PI oder LIR).
              </simpara>
            </listitem>
          </itemizedlist>
        </para>
      </listitem>
      <listitem>
        <simpara>
        Es werden auch Werkzeuge (und Menschen:) gebraucht, die beim verantwortlichen Betrieb eines Routers/meshes/Intermeshes/AS helfen, incl. Absprachen, Dokumentationen, (interne + externe) Kommunikationskanäle, Monitoring etc. Dabei das Rad nicht neu erfinden, sondern Bewährtes auf die verteilte Infrastruktur einer IGP-Kopplung verteilen.
        </simpara>
      </listitem>
      <listitem>
        <simpara>
        Firmware. Für die Entwicklungsrouter (zZ ALIX/APU) gibt es das implizit (dd:-), dank der Virtualisierungsbemühungen für APU mittlerweile auch explizit. Für Plasterouter könnte eine ausreichend mächtige (und für generisches OpenWRT portierte) Automatisierungsmechanik erstmal reichen. Wenn die Mechanik auch die Generierung von Gluon oder LibreMesh Images per (generierter:) Konfiguration steuern kann, lässt sich auch Firmware für die üblichen Plasterouter erzeugen. 
        </simpara>
      </listitem>
    </itemizedlist>
  </section>
</article>