infrastruktur:gateway:babel-gateway

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
infrastruktur:gateway:babel-gateway [22.11.2017 12:57] – [Einrichtung der Frankfurter Gatways] christfinfrastruktur:gateway:babel-gateway [10.06.2021 12:25] (aktuell) – igor
Zeile 1: Zeile 1:
 +====== Gateway für das Freifunk-Babel Netz ======
 +<WRAP center round todo 60%>
 +Diese Seite ist veraltet da FFFFM aktuell kein Babel Netz betreibt.
 +</WRAP>
 +
 +
 Gateways für das Freifunk-Babel-Netz orientieren sich am Setup für Batman-Gateways.  Gateways für das Freifunk-Babel-Netz orientieren sich am Setup für Batman-Gateways. 
 Der Server nimmt fastd-Verbindungen von Freifunk-Routern mit der Babel-Firmware an und verteilt Informationen zur Infrastruktur des Netzes (früher: IP-Adressen & Routen, mittlerweile lediglich Routen, wobei das streng genommen optional ist), damit das Gesamtnetz funktionieren kann. Der Server nimmt fastd-Verbindungen von Freifunk-Routern mit der Babel-Firmware an und verteilt Informationen zur Infrastruktur des Netzes (früher: IP-Adressen & Routen, mittlerweile lediglich Routen, wobei das streng genommen optional ist), damit das Gesamtnetz funktionieren kann.
  
 Es gibt ein paar Unterschiede zu Batman-Gateways: Es gibt ein paar Unterschiede zu Batman-Gateways:
-  * es ist kein dhcp-Server erforderlich +  * es ist kein dhcp-Server erforderlich - IPv4-Adressen werden im Netz und an Clients nicht mehr verteilt. 
-  * es ist kein radvd erforderlich+  * es ist kein radvd auf den Gateways erforderlich - IPv6-Adressen werden von Nodes an Clients vergeben, nicht von Gateways. IPv6-Adressen auf Nodes werden anhand der Node-MAC berechnet und hart eingestellt. Routen werden via babel an Nodes verteilt. 
   * Batman wird nicht installiert   * Batman wird nicht installiert
   * Es müssen zusätzliche Komponenten (mmfd, l3roamd) ausgeführt werden   * Es müssen zusätzliche Komponenten (mmfd, l3roamd) ausgeführt werden
   * Über fastd wird das babel mesh-Protokoll gesprochen. Dadurch ist eine theoretische minimale MTU von 1288 möglich (1280 minimale IPv6-Größe + ein UDP-Header für mmfd-Pakete, die weiterhin Encapsulation-Technologie nutzen)   * Über fastd wird das babel mesh-Protokoll gesprochen. Dadurch ist eine theoretische minimale MTU von 1288 möglich (1280 minimale IPv6-Größe + ein UDP-Header für mmfd-Pakete, die weiterhin Encapsulation-Technologie nutzen)
 +
 +
 +Das Setup ist bereits in salt abgebildet: https://chaos.expert/FFFFM/salt-state-ffrl-exit/
 +
  
  
Zeile 50: Zeile 60:
   [Service]   [Service]
   Type=simple   Type=simple
-  ExecStart=/usr/local/bin/l3roamd -p 2a06:8187:fbab:2::/64 -m gre_gw01 -m mesh-vpn-1374 -m babel-vpn-1374  -i dummyl3roamd -t 11 -a 2a06:8187:fbab:1::9000:2 -4 0:0:0:0:0:ffff::/96 -b br-client+  ExecStart=/usr/local/bin/l3roamd -p 2a06:8187:fbab:2::/64 -m gre_gw01 -m mesh-vpn-1374 -m babel-vpn-1374  -t 11 -a 2a06:8187:fbab:1::9000:2 -4 0:0:0:0:0:ffff::/96 
   KillMode=process   KillMode=process
   ExecStartPost=/sbin/ip link set dev l3roam0 up   ExecStartPost=/sbin/ip link set dev l3roam0 up
Zeile 60: Zeile 70:
   WantedBy=multi-user.target   WantedBy=multi-user.target
  
-Die Bridge br-client muss per /etc/network/interfaces eingerichtet sein. Was da drin hängt ist egal, sie muss nur automatisch da sein beim Start. Ich mach das aktuell mit /etc/network/interfaces.d/br-client mit dem Inhalt 
-  iface br-client inet static 
-  address 192.0.2.1 
-  netmask 255.255.255.0 
-  bridge_ports none 
  
 Die hinzugefügte Route macht, dass Pakete mit einem Ziel im Freifunk-Client-Netz aber mit unbekannter echter Route an den l3roamd übergeben werden. Dieser kann dann die Route ermitteln. Die hinzugefügte Route macht, dass Pakete mit einem Ziel im Freifunk-Client-Netz aber mit unbekannter echter Route an den l3roamd übergeben werden. Dieser kann dann die Route ermitteln.
-Der l3roamd wird angepasst, sodass br-client nicht mehr zwingend erforderlich sein wird, denn auf Gateways ist sie nicht vorhanden und auch nicht sinnvoll. 
- 
 ===== Routing ===== ===== Routing =====
 Tabelle 10 wird fürs Routing genutzt. Wir haben auf dne GAteways folgende ip -6  rules: Tabelle 10 wird fürs Routing genutzt. Wir haben auf dne GAteways folgende ip -6  rules:
Zeile 88: Zeile 91:
  
  
-in Tabelle 12 kann man routen rein schreiben, von denen man möchte, dass sie von babeld noch verteilt werden sollen, Tabelle 10 enthält die Routen, die für das Freifunk-Netz gelten, in TAbelle 11 schreibt l3roamd seine neu gefundenen Routen rein. Das lässt sich alles zusammenfassen und in Tabelle 254 machen, wie auf den Nodes. Dann käme man ohne ip rules und separate routingtabellen aus. Wir haben es auf den Gateways aktuell getrennt. So schreibt nicht jeder in der main routing table herum.+in Tabelle 12 kann man routen rein schreiben, von denen man möchte, dass sie von babeld noch verteilt werden sollen, Tabelle 10 enthält die Routen, die für das Freifunk-Netz gelten, in Tabelle 11 schreibt l3roamd seine neu gefundenen Routen rein. Das lässt sich alles zusammenfassen und in Tabelle 254 machen, wie auf den Nodes. Dann käme man ohne ip rules und separate routingtabellen aus. Wir haben es auf den Gateways aktuell getrennt. So schreibt nicht jeder in der main routing table herum.
  
 Die default-route für den uplink muss in Tabelle 10 und 12 eingetragen werden (ggf reicht Tabelle 10). Diese Route muss, damit sie mit dem prefixd kompatibel als src-filter das client-Netz gesetzt haben. Die default-route für den uplink muss in Tabelle 10 und 12 eingetragen werden (ggf reicht Tabelle 10). Diese Route muss, damit sie mit dem prefixd kompatibel als src-filter das client-Netz gesetzt haben.
Zeile 129: Zeile 132:
   WantedBy=multi-user.target   WantedBy=multi-user.target
  
-Und so wird er konfiguriert:+Und so wird er in /etc/babeld.conf konfiguriert:
   ipv6-subtrees true   ipv6-subtrees true
   reflect-kernel-metric true   reflect-kernel-metric true
Zeile 146: Zeile 149:
   redistribute ip 2a06:8187:fbab:2::/64 eq 128  allow   redistribute ip 2a06:8187:fbab:2::/64 eq 128  allow
   redistribute ip 2a06:8187:fbab:1::/64 eq 128  allow   redistribute ip 2a06:8187:fbab:1::/64 eq 128  allow
-  redistribute src-ip 2a06:8187:fb00::/40 ip ::/0 allow +  redistribute src-ip 2a06:8187:fb00::/40 ip 2000::/3 allow 
-  redistribute ip ::/0 allow +  # redistribute ip ::/0 allow
- +
-Die Interfaces sind natürlich an die Gegebenheiten so anzupassen, dass alle mesh-interfaces dabei sind. Das beinhaltet ausschließlich dann den Uplink, sofern auf dem babel gesprochen wird. Routen für die next-node-IP (bei unserem Netz 2a06:8187:fbab:2::1/128) werden nicht verteilt, während Routen aus dem node-prefix (2a06:8187:fbab:1::/64) und client-prefix (2a06:8187:fbab:2::/64)  verteilt werden. Die nächste Zeile fügt src-filter für den default-prefix hinzu - wieder für prefixd-Kompatibilität:   redistribute src-ip 2a06:8187:fb00::/40 ip ::/0 allow  -- dadurch wird das default-gateway des Gateways im Netz verteilt. +
- +
- +
-TODO: In dem Moment in dem ich das schreibe, habe ich den Eindruck, dass   redistribute ip ::/0 allow nicht erforderlich sein sollte. Prüfen und ggf anpassen....+
  
 +Die Interfaces sind natürlich an die Gegebenheiten so anzupassen, dass alle mesh-interfaces dabei sind. Das beinhaltet ausschließlich dann den Uplink, sofern auf dem babel gesprochen wird. Routen für die next-node-IP (bei unserem Netz 2a06:8187:fbab:2::1/128) werden nicht verteilt, während Routen aus dem node-prefix (2a06:8187:fbab:1::/64) und client-prefix (2a06:8187:fbab:2::/64)  verteilt werden. Die nächste Zeile fügt src-filter für den default-prefix hinzu - wieder für prefixd-Kompatibilität:   redistribute src-ip 2a06:8187:fb00::/40 ip 2000::/3 allow  -- dadurch wird das default-gateway des Gateways im Netz verteilt.
  
 ===== Yanic ===== ===== Yanic =====
 Yanic kann unabhängig von den Gateways auf einer anderen Box ausgeführt werden. Auf dem Host mit dem yanic, muss der mmfd laufen, der eine Verbindung zu anderen Nodes im Netz halten muss, weshalb babeld ebenfalls erforderlich ist.  Yanic kann unabhängig von den Gateways auf einer anderen Box ausgeführt werden. Auf dem Host mit dem yanic, muss der mmfd laufen, der eine Verbindung zu anderen Nodes im Netz halten muss, weshalb babeld ebenfalls erforderlich ist. 
 Dessen mmfd0-Interface ist als Interface für die queries anzugeben, wobei eine broadcast-Adresse eingesetzt werden muss: ff05::was-auch-immer-respondd-hier-verlangt. Dessen mmfd0-Interface ist als Interface für die queries anzugeben, wobei eine broadcast-Adresse eingesetzt werden muss: ff05::was-auch-immer-respondd-hier-verlangt.
 +
 +===== Was braucht man noch ringsrum? =====
 +  * Das Netz ist IPv6-Only, also benötigt man einen NAT64 und entsprechenden DNS für den Zugriff auf das IPv4-Internet. Jool kann man dafür nutzen.
  • infrastruktur/gateway/babel-gateway.1511355457.txt.gz
  • Zuletzt geändert: 22.11.2017 12:57
  • von christf