wiki/Technik/Routing/IGP-Kopplung-Roadmap.page

---
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 der Planung und Kooperation zur praktischen Weiterentwicklung der IGP-Kopplung. Zur Herleitung dieses Routingkonzepts für Freifunk-Netze siehe den Text zum <ulink url="Fussgaengerzonenproblem">Fußgängerzonenproblem</ulink>.
</simpara>

<table>
  <tgroup cols="3">
    <colspec align="left" />
    <colspec align="left" />
    <colspec align="left" />
    <thead>
      <row>
        <entry>
         Bereich
        </entry>
        <entry>
         Status
        </entry>
        <entry>
         Aufgaben
        </entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>
         Routing
        </entry>
        <entry>
         -
        </entry>
        <entry>
          <para>
           Erstellung einer (mit den Teilnehmenden wachsenden) Einführung in das Thema dynamisches Routing:
            <itemizedlist>
              <listitem>
                <simpara>
                 als Text, mit repository für Text und config und src, sowie ggf. passende Laborfirmware (zB à la <ulink url="http://nicolasacco.diveni.re/~gioacchino/internship-report/main.html">Libre-Mesh</ulink>).
                </simpara>
              </listitem>
              <listitem>
                <simpara>
                 Unterthemen: Routing im Internet mit großem I (OSPF, BGP). Routing für den Freifunk, d.h. u.a. WLAN-adhoc-Meshes, leistungsschwache Router, communities (OLSR, Babel, B.A.T.M.A.N.). Mit Beispielen aus dem FF und insb. Übungen zum "Routing Selbermachen" mit üblicher Hardware.
                </simpara>
              </listitem>
              <listitem>
                <simpara>
                 Ziel der Einführung: Eigenhändiger Anschluss der Geräte der Routing-Adepten (m/w) 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.
                </simpara>
              </listitem>
            </itemizedlist>
          </para> 
        </entry>
      </row>
      <row>
        <entry>
         IGP-Kopplung
        </entry>
        <entry>
         Laborbetrieb (bewohnbar;)
        </entry>
        <entry>
          <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>
                  </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.
                    </simpara>
                  </listitem>
                </itemizedlist>
              </para>
            </listitem>
          </itemizedlist>
        </entry>
      </row>
      <row>
        <entry>
         dDHCP (verteiltes DHCP)
        </entry>
        <entry>
         Laborbetrieb (bewohnbar;)
        </entry>
        <entry>
          <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>
        </entry>
      </row>
      <row>
        <entry>
         Konfiguration
        </entry>
        <entry>
         Laborbetrieb (bewohnbar;)
        </entry>
        <entry>
          <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>
        </entry>
      </row>
    </tbody>
  </tgroup>
</table>

</article>