134
Bearbeitungen
Änderungen
Zur Navigation springen
Zur Suche springen
Zeile 141:
Zeile 141: − + + + +
Technik/Netzkonzept (Quelltext anzeigen)
Version vom 6. November 2017, 00:42 Uhr
, 00:42, 6. 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. 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 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].
[[Datei:L3Rounting_with_babel_v1.jpeg]]
[[Datei:L3Rounting_with_babel_v1.jpeg]]
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.
In diesem Diagramm wird Babel auch zwischen den Gateways im RZ gesprochen. Clients haben generell die Möglichkeit via Richtfunk strecke oder über die RZ Gateways zu kommunizieren. Wenn wir jetzt z.B. die Kommunikation auf die Richtfunkstrecken forcieren wollen könnte man die Babel Verbindung zwischen den RZ Gateways auch durch unsere aktuelle BGP oder OSPF Lösung ersetzen. Somit müsste Theoretisch Babel die Lokale bekannte Route über die Richtfunkverbindung nehmen und erst wenn Babel keine Route findet und die default wählt, kann der RZ Gateway über BGP OSPF weiter an seine Anderen RZ Gateways vermitteln.
In diesem Diagramm wird Babel auch zwischen den Gateways im RZ gesprochen. Clients haben generell die Möglichkeit via Richtfunk strecke oder über die RZ Gateways zu kommunizieren. Wenn wir jetzt z.B. die Kommunikation auf die Richtfunkstrecken forcieren wollen könnte man die Babel Verbindung zwischen den RZ Gateways auch durch unsere aktuelle BGP oder OSPF Lösung ersetzen. Somit müsste Theoretisch Babel die Lokale bekannte Route über die Richtfunkverbindung nehmen und erst wenn Babel keine Route findet und die default wählt, kann der RZ Gateway über BGP OSPF weiter an seine Anderen RZ Gateways vermitteln.