wiki/Technik/Netzinfrastruktur/Infrastruktur-ToDos.page

---
format: markdown
categories: Netz-Infrastruktur, Backbone, Supernodes, Firmware, Hintergrundinfos, ToDos, Treffen
title: ToDos der Infrastruktur Gruppe
...

# Infrastruktur-Treffen

Nächstes Treffen: 

Themen:

* IPv4 Adressen des FF-DO (AS35675) für die NG-Supernodes
    * Routing in Berlin (zum AS201701) (beim FF-RL nachhaken?)
    * NAT-Konfigration uplink-neutral machen
    * snng-ber02 analog zu snng-dor01/2 produktiv machen
    * MTU optimieren (brauchen wir noch MSS clamping?)
* DNS
    * reverse mapping
        * RIPE maintainer?
* ...

# Firmware

* Automatisches Bauen der Firmware für 11 Domänen mit l2tp basierend auf gluon 2017.1.x (lede)
    * Aktueller Stand: [ffdp-l2tp](https://github.com/ffdo/site-ffdo-l2tp)
    * Autoupdate testen, testen, testen
    * Kopie der FW Bauanleitungen mit Skripten und settings ins dortmunder git packen: Kopie von github.com
    * optionale opkg Pakete (modules) erzeugen, bereitstellen, verwalten

# Server

## Anforderungsliste Hardware Supernodes/blech02  

* Serverplatz 1HE mit Management-Board
* ip für Rechner und Management-Board vom Hoster  
* BGP für IPV4 für 193.43.220.0/23 und IPV6 2001:678:980::/48 ???  

# Funktion und Beschreibung Supernodes

Legende: (Ax) sind Aufgaben zur Erstellung des Supernodes

Supernodes sind Knoten unseres Mesh-Netzwerks, die Server im Rechenzentrum sind und an die ausschließlich per Netzwerktunnel verbunden wird. Sie basieren zumeist nicht auf OpenWRT, sondern werden mit anderen Linux-Distributionen wie Debian oder Arch Linux aufgebaut. Üblich ist es, virtuelle Maschinen zu mieten und nicht echte Hardware-Server. Virtuelle Server sind kostengünstig zu mieten, so dass wir in die Breite skalieren können (mehr Maschinen für mehr Verbindungen).     

Supernodes haben zwei Aufgaben:   
Vermitteln des lokalen Netzwerks als Tunnelendpunkt    
Supernodes belegen jeweils eine öffentliche IPv6- und per IPv4-Adresse und sind daher von jedem Internet-Anschluss erreichbar. Die Erreichbarkeit ist für die Administration notwendig. (A1)
Einfache Nodes, also Freifunk-Router oder Freifunk-Offloader(?), verbinden sich über den VPN-Dienst fastd (A2)z u ihnen. Damit fastd funktioniert, wurden sie für die Hostnamen und Public Keys der Supernodes (der jeweiligen Community) bereits vorbereitet. fastd ist etwas ähnliches wie OpenVPN, aber wesentlich kleiner und mit einem anderen Satz an Funktionalitäten.   
Alternativ kann zur Verbindung l2tp verwendet werden. Hier werden nur die Protokolldaten verschlüsselt, die Nutzdaten müssen über Layer 3 verschlüsselt werden. (https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol) 
Auf den Supernodes läuft, genau wie auf den einfachen Nodes, eine Batman-Bridge (A3). Batman ist eine Art verteilte Bridge, die verschiedene Computer so mit einander verschaltet, dass sie wie eine einzige transparente Multiport-Bridge funktioniert. Batman kennt die MAC-Adressen auf allen „Switch(Bridge)-Ports“.  Endgeräte, die man mit ihr verbindet, werden so untereinander verbunden, als hätte man sie an einen regulären Netzwerk-Switch oder eine transparente Bridge angeschlossen. 
Definition
Eine Bridge verbindet 2 Netzwerksegmente, hat also 2 Ports.
Eine Multiport-Bridge verbindet mehrere Netzwerksegmente.
Ein Switch entspricht einer transparenten Multiport-Bridge auf MAC-Ebene
Eine Alternative zu Batman ist OLSR (optimized link state routing protocol).(?)
Außerdem sind die Supernodes natürlich auch untereinander durch Tunnel (A4) verbunden. Es ergibt sich dadurch ein kleiner Backbone, der die LAN-Segmente der Community(?), also z.B. Dortmund, Ennepetal, Fichtenfunk usw. miteinander verbindet. Dadurch ergibt sich ein Netzwerk-Link, also die Summe der Bridges auf Layer 2, über den die Internetprotokolle IPv6 und IPv4 und prinzipiell auch alle anderen Netzwerkprotokolle transportiert werden. Ein solches LAN-Segment kann auch von mehreren Communities gemeinsam betrieben werden. Wir sprechen dann von einer Domäne aus verschiedenen Communities, im Gegensatz zu Domänen innerhalb einer Community auf Router-Ebene.  

Routing in andere Freifunk-Netzwerke und zu Edge-Routern/exit nodes   
Eine Supernode ist außerdem für Internet-Routing zu den exit-nodes (A5) konfiguriert, verteilt IP-Adressen per DHCP (A6), dient als DNS-Resolver (A7) und ist darum bei Batman als sogenannter Gateway-Server (A8) konfiguriert. Dies bewirkt, dass Nodes, also Freifunk-Router, ihre Clients an den Supernode „vermitteln“.   

Die DHCP-Anfragen der Clients werden nämlich nicht als Broadcast-Frame durch das Netzwerk verbreitet, sondern wie ein Unicast-Frame an den jeweils zuständigen Gateway-Server, also Supernode, zugestellt. Welcher das ist, entscheidet jeder Node, der in der Regel als Gateway-Cient konfiguriert ist, für sich und im vorhinein. Das gilt übrigens für jede Verbindung durch das Mesh-Netz. Daher spricht man hier auch von einem proaktiven (im vorhinein), quellbasierten (der Absender entscheidet) Mesh-Protokoll. 
(Welche Rolle spielen OSPF(internes Routing) und BGP(externes Routing) bei Supernodes? )   
Die Supernodes im Rheinland hängen alle zusammen im Rheinland Backbone. Dieser befindet sich derzeit noch im Umbau, übernimmt aber bereits jetzt die Funktion, alle Supernodes und die Edge-Router unseres Netzwerks mit einander zu verbinden. Die Routen werden hier derzeit per OSPF, zukünftig per BGP verteilt. Jede Domäne erhält ein öffentliches IPv6-Subnetz und öffentliche IP-Adressen für IPv4/NAT. 
Die Supernodes verteilen Adressen und routen den Traffic zu den exit-nodes. Die exit-nodes leiten den Traffic in das Internet, über den Freifunk Rheinland als Provider.

## memo Mich.: Git Adresse wiki ffdo

* neue Ansible-Skripte ins Git hochladen
* 'node_exporter' auf neue Supernodes installieren
* Korrigieren: batman build schlägt fehl wenn bereits ein batman per ansible übersetzt wurde
* Link zu Map-Server

### Routing

* Batman zwischen den neuen Supernodes einrichten  
  (weiterer etherstub? VLAN auf dem bestehenden?)
* Dynamisches Routing (L3)
    * ~~alle Supernodes auf den etherstub konfigurieren~~ [done]
    * IPv4 Subnetze für
        * Router-IDs (loopback-Interface) für alle Supernodes
        * ~~Transfer-Netz zwischen den Supernodes auf dem etherstub~~ [done]
    * ~~OSPF auf dem eth1 Interface konfigurieren (s. sn-dev1 <-> vm23)~~ [done]
    * ~~Routing IPv6 der neuen Nodes~~ [done]
* Migration ins AS35675
    * ~~IPv6 PI-Adressen besorgen~~ [done: 2001:678:980::/48]
    * ~~die eigenen IPv6-Adressen benutzen~~ [done für den FF-DO-NG]
    * ~~die eigenen IPv4-Adressen benutzen~~ [done für den FF-DO-NG]
    * ditto für die Supernodes in Berlin

## Weitere Server

* grafana service per ansible installieren
* images.ffdo.de per ansible einrichten: bisher wird nur ein reiner webserver installiert. Der Download Bereich fehlt noch. 
* build.ffdo.de per ansible einrichten funktioniert wohl nicht auf "nacktem" System bzw. nicht im ersten Anlauf
* www.ffdo.de Regelmässige Backups machen (falls der Server mal mitgenommen wird...)
* Aktualisierung auf prometheus 2 auf services.ffdo.de: soll effizienter laufen. [upgrade guide](https://www.digitalocean.com/community/tutorials/how-to-upgrade-prometheus-1-x-to-prometheus-2-0-on-ubuntu-16-04)
* grafana/nodes2grafana: Umgang mit mehreren Routern mit gleichen Namen korrigieren.
* DNS-Konfigurationsoberfläche für freifunk-dortmund.de erforschen und Useraccounts mit eingeschränkten Rechten anlegen