Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
infrastruktur:gateway:babel-gateway [22.11.2017 13:50] – [Babeld] christf | infrastruktur: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. | ||
+ | </ | ||
+ | |||
+ | |||
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 |
- | * es ist kein radvd erforderlich | + | * es ist kein radvd auf den Gateways |
* 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, | * Ü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, | ||
+ | |||
+ | |||
+ | Das Setup ist bereits in salt abgebildet: https:// | ||
+ | |||
Zeile 50: | Zeile 60: | ||
[Service] | [Service] | ||
Type=simple | Type=simple | ||
- | ExecStart=/ | + | ExecStart=/ |
KillMode=process | KillMode=process | ||
ExecStartPost=/ | ExecStartPost=/ | ||
Zeile 60: | Zeile 70: | ||
WantedBy=multi-user.target | WantedBy=multi-user.target | ||
- | Die Bridge br-client muss per / | ||
- | iface br-client inet static | ||
- | address 192.0.2.1 | ||
- | netmask 255.255.255.0 | ||
- | bridge_ports none | ||
- | |||
- | Das dummyl3roam0 interface muss nicht existieren. Der l3roamd erfordert aktuell, dass man client-interfaces angibt und mag ohne diese nicht starten. Das wird mal noch behoben. | ||
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 90: | 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 | + | 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 |
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 151: | Zeile 152: | ||
# 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: | + | 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: |
===== Yanic ===== | ===== Yanic ===== | ||
Zeile 158: | Zeile 159: | ||
===== Was braucht man noch ringsrum? ===== | ===== 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. | + | * 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. |