Services/Organisation/Tunnelserver: Unterschied zwischen den Versionen
Erich (Diskussion | Beiträge) |
Erich (Diskussion | Beiträge) |
||
| Zeile 19: | Zeile 19: | ||
Um die wechselseitigen Abhängigkeiten zu reduzieren, lautet der aktuelle Projektfahrplan wie folgt: | 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 | * Vorbereitungen: | ||
** Von der VM auf eine physische Hardware zu migrieren. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden. | ** Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen. | ||
*** Anschließend die VM | ** Tests neuer Funktionen. | ||
** Die Routing-Funktionen der | * Hauptphase: Von der VM auf eine physische Hardware zu migrieren. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden. | ||
* Nacharbeiten: | |||
** 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. | |||
* Dauerarbeiten: Wartung und Betreuung. | |||
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. | 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. | ||
Version vom 26. Februar 2018, 00:43 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.
- Vorbereitungen:
- Sämtliche Tunnelfunktionen von Tunnel6 und Tunnel auf der „VM-Tunnel6“ zu vereinen.
- Tests neuer Funktionen.
- Hauptphase: Von der VM auf eine physische Hardware zu migrieren. Diese Maschine wird wie ein Roofnode mit erhöhter Redundanz eingebunden werden.
- Nacharbeiten:
- 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.
- Dauerarbeiten: Wartung und Betreuung.
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.