Services/Organisation/Tunnelserver: Unterschied zwischen den Versionen
Erich (Diskussion | Beiträge) |
Erich (Diskussion | Beiträge) |
||
| Zeile 17: | Zeile 17: | ||
* Housing/VM | * Housing/VM | ||
Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt: | |||
Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren. | Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren. | ||
** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der VM-Tunnel6 zu vereinen. | ** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der VM-Tunnel6 zu vereinen. | ||
Version vom 26. Februar 2018, 00:40 Uhr
| Tunnelserver | |
|---|---|
| Starttermin |
20 Sep. 17 |
| Status | |
| Der Tunnelserver dient der Anbindung von sogenannten Funkinseln der Community an das Funkfeuer-Netz über eine nicht zu Funkfeuer gehörende Breitbandverbindung unter Nutzung von unterschiedlichen Techniken der Paketverkapselung. | |
Der Tunnelserver dient der Anbindung von sogenannten Funkinseln der Community an das Funkfeuer-Netz über eine nicht zu Funkfeuer gehörende Breitbandverbindung unter Nutzung von unterschiedlichen Techniken der Paketverkapselung.
Funkinseln sind entweder solche Knoten, deren einzige Verbindung zum Funkfeuer-Netz über eine nicht zum Funkfeuer-Netz gehörende Breitbandverbindung hergestellt wird, oder solche Knoten, die über eine externe Breitbandverbindung und ihre jeweilige Funkschnittstelle oder jeweiligen Funkschnittstellen entlegene Knoten, die sonst nicht mit dem restlichen Funkfeuer-Netz verbunden sind, verbinden, sowie jene Knoten, die aus Gründen der höheren Redundanz eine externe Breitbandverbindung als Backupverbindung nützen, um zwischen Nachbarknoten und dem Funkfeuer-Housing über eine Breitbandverbindung Daten weiterzuleiten, Routinginformationen auszutauschen oder selbst Daten zu übertragen.
Das Tunnelserverprojekt ist von folgenden Projektgruppen abhängig:
- Core-Team/Roofnode-Team
- v642-Projekt
- Housing/VM
Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt: Den gegenwärtigen Tunnelserver, der leider auch andere, systemrelevante Aufgaben erledigt, in mehreren Schritten zu migrieren.
- Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der VM-Tunnel6 zu vereinen.
- Von der VM auf eine physische Hardware zu migrieren. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.
- Anschließend die VM Tunnel 6 stilllegen.
- Die Routing-Funktionen der VM Tunnel auf die neuen Roofnodes oder andere Router so verteilen, wie es sinnvoll ist.
- Die VM Tunnel anschließend stilllegen.
Ziel ist es, einen redundant angebundenen Tunnelserver zu haben, der einerseits „echte Funkinseln“ mit mehreren Protokollen versorgen kann, andererseits auch versprengte IPv6-Maschinen durch das IPv4-Netz anbinden kann. Eine weitere Aufgabe kann die Anbindung der vereinzelt existenten OLSRv1-IPv6 Knoten sein. Letzteres ist durch Migrationsvorhaben an den davon betroffenen Knoten jedoch nur noch bedingt relevant.
Gegenwärtiger Status:
- Tunnel VM hat Aufgaben von Tunnel6 vorübergehend übernommen.
- Tunnel6 wurde aktualisiert und wird nun um neue Features erweitert. Hier sind wir in der Testphase. Nach deren Abschluss steht die Migration sämtlicher Tunneldienste auf diese VM unmittelbar bevor.