134
Bearbeitungen
Änderungen
Zur Navigation springen
Zur Suche springen
Zeile 141:
Zeile 141: − + + − Diese Grafik stellt eine Grobe Übersicht über ein Theoretisches Netzwerk da. Wir haben jeweils ein RZ Gateway (1 & 2) pro hood. Diese Stelle auch einen Exit ins Internet bereit und haben zudem ein Routing untereinander mittels Babel Protokoll. Die RZ Gateways stellen die Möglichkeit das Router sich via VPN zu den Servern verbinden können um darüber BATMAN-adv zu sprechen. VPN Router (1 & 2) sind einfache Gluon Router, die einen VPN zu den RZ Gateway ihrer hood aufbauen und dort drüber BATMAN-adv sprechen. An den VPN Router (1 & 2) können via mesh weitere Router hängen. Sind in dem Bild aber nicht weiter dargestellt, da diese Grafik nur eine Grobe Übersicht stellen soll. DSL Exit (1 & 2) sind Lokale BATMAN-adv Gateways und funktionieren vom Prinzip her wie die RZ Gateways. + +
Technik/Netzkonzept (Quelltext anzeigen)
Version vom 8. November 2017, 12:54 Uhr
, 12:54, 8. Nov. 2017→Layer 3 Routing
=== Layer 3 Routing ===
=== Layer 3 Routing ===
Um Verbindungen zwischen den hoods und lokalen exit nodes zu ermöglichen müssen wir Routing Informationen zwischen den Teilnehmern austauschen. Als Protokoll welches double-stack (v6 & v4) kann eignet sich Babel. Zudem hat Babel flexible Metriken die Kabel oder Funk Verbindungen berücksichtigen. [https://tools.ietf.org/html/rfc6126 Das RFC zur Standardisierung findet ihr hier].
Um Verbindungen zwischen den hoods und lokalen exit nodes zu ermöglichen müssen wir Routing Informationen zwischen den Teilnehmern austauschen. Als Protokoll eignet sich Babel. Babel ist ein loop-avoiding distance-vector routing Protokoll welches double-stack (v6 & v4) kann. Das Protokoll basiert auf den Ideen von [https://en.wikipedia.org/wiki/Destination-Sequenced_Distance_Vector_routing DSDV], [https://de.wikipedia.org/wiki/Ad-hoc_On-demand_Distance_Vector AODV] und [https://de.wikipedia.org/wiki/Enhanced_Interior_Gateway_Routing_Protocol Cisco's EIGRP]. Das Design von Babel ist allerdings so flexiebel das es sowohl mit Kabelverbindungen als auch mit Funkverbindungen umgehen kann, was ein großer Vorteil für unsere Szenarios ist. Zudem kann Bable auch als Overlay-Netz eingesetzt werden. Zu guter Letzt bietet Babel eine menge Optionen für verschiedene Metriken. [https://tools.ietf.org/html/rfc6126 Das RFC zur Protokoll Standardisierung findet ihr hier] und über [https://www.irif.fr/~jch/software/babel/ Metriken könnt ihr hier was finden].
[[Datei:L3Rounting_with_babel_v1.jpeg]]
[[Datei:L3Rounting_with_babel_v1.jpeg]]
Diese Grafik stellt eine Grobe Übersicht über ein Theoretisches Netzwerk da. Wir haben jeweils ein RZ Gateway (1 & 2) pro hood. Diese Stelle auch einen Exit ins Internet bereit und haben zudem ein Routing untereinander mittels Babel Protokoll. Die RZ Gateways stellen die Möglichkeit das Router sich via VPN zu den Servern verbinden können um darüber BATMAN-adv zu sprechen. VPN Router (1 & 2) sind einfache Gluon Router, die einen VPN zu den RZ Gateway ihrer hood aufbauen und dort drüber BATMAN-adv sprechen. An den VPN Router (1 & 2) können via mesh weitere Router hängen, diese sind in dem Bild aber nicht weiter dargestellt, da diese Grafik nur eine Grobe Übersicht stellen soll. DSL Exit (1 & 2) sind Lokale BATMAN-adv Gateways und funktionieren vom Prinzip her wie die RZ Gateways.
https://tools.ietf.org/html/rfc7298
Um sicher zustellen das das Layer 3 Routing nicht manipuliert wird, müssen wir ein Verifikationsmedium einsetzen bsp. ein Tunnel Protokoll z.b. gre, tinc, usw.. Eine volle Verschlüsselung ist dabei nicht notwendig. Evtl. bietet Babel selbst auch eine Möglichkeit der Verifikation, somit könnte man den overhead des Tunnels kompensieren.
Um sicher zustellen das das Layer 3 Routing nicht manipuliert wird, müssen wir ein Verifikationsmedium einsetzen bsp. ein Tunnel Protokoll z.b. gre, tinc, usw.. Eine volle Verschlüsselung ist dabei nicht notwendig. Evtl. bietet Babel selbst auch eine Möglichkeit der Verifikation, somit könnte man den overhead des Tunnels kompensieren.