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>
    </tbody>
  </tgroup>
</table>

</article>