|
|
@@ -0,0 +1,130 @@
|
|
|
+---
|
|
|
+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 für die praktische 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 <-> 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>
|
|
|
+ </tbody>
|
|
|
+ </tgroup>
|
|
|
+</table>
|
|
|
+
|
|
|
+</article>
|
