Änderungen

[[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.  

Diese Grafik stellt eine Grobe Übersicht über ein Theoretisches Netzwerk da. Wir haben jeweils ein RZ Gateway (0 & 1) 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 (0 & 1) 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 (0 & 1) 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. Hier können ebenfalls z.B. via WLAN oder Kabel weitere mesh Router hängen. In dem oben gezeigten Beispiel gibt es noch die Router Rifu (0 & 1). Dir Rifu 1 hat über das batman-adv Netz eine Layer 3 Route mit Babel zu DSL Exit 1. Um Manipulationen des Layer 3 zu verhindern haben sich die Betreiber der Gateways DSL Exit 1 und Rifu 1 entschieden HMAC was für Hashed Message Authentication Code steht einzusetzen. Das ist ein Authentifizierungsverfahren welches dafür sorgt das die Router keine manipulierten Pakete erhalten. [https://tools.ietf.org/html/rfc7298 Das zugehörige RFC für Babel HMAC findet sich hier.] Die Betreiber haben somit weiteren overhead einsparen können da, die Netzwerk Pakete nicht nochmal in eine Tunnel verpackt werden müssen. Über die Richtfunkverbindung können die Client nun auch andere Geräte und ein anderes Subnetz aus der Nachbar Hood erreichen. Wir schauen uns die Hood OL jetzt mal ein wenig genauer an und gucken was theoretisch mit den Clients passiert.  

https://tools.ietf.org/html/rfc7298

Das heißt der Schwerpunkt der Adressenverteilung liegt somit auf den RZ Gateways. Um den Schwerpunkt nun sinnvollerweise mehr in das Lokale Netz zu verlagern, könnte man das Script zum announcen der Bandbreite so anpassen das ein maximaler Schwellwert eingehalten wird. Als Beispiel announcen die RZ Gateways nur noch eine Bandbreite von 5Mbit synchron. Das würde bedeuten das lokale Exits die eine höhere Bandbreite besitzen bevorzugt werden. Somit sind die RZ Gateways eine Art Fallback und dienen als vom Verein gestellte Basis stütze. Jetzt müssen wir und man genauer anschauen was passiert wenn die Gateways nur eine minimale Bandbreite annoucen. Fangen wir bei VPN Router 0, mesh Router 0 und Client 0 an. Wie man der Grafik entnehmen kann hat der VPN Router 0 eine VPN Verbindung zum RZ Gateway worüber der Router BATMAN-adv spricht. Der VPN Router 0 sieht selber nur das RZ Gateway als BATMAN-adv Gateway. Das liegt daran das andere BATMAN-adv Gateways vom RZ Gateway weg gefiltert werden, da die RZ Gateway eine Sonderrolle vertreten. Am VPN Router 0 hängt via Mesh über das 11s WLAN Netz der mesh Router 0 und dieser Router hat den Client 0 welcher eine Adresse aus dem 10.18.152er Netz bekommt. Für die Gruppe 0 ist also alle super so wie es sein soll. Schauen wir uns nun mal VPN Router 1 an so können wir feststellen das dieser 3 BATMAN-adv Gateways sehen kann: RZ Gateway, Gateway Router und Rifu Gateway. Gateway Router anounced 16Mbit und Rifu Gateway eine minimal schlechtere Bandbreite von 10Mbit und RZ Gateway announce wie oben gesagt eine künstlich geringe Bandbreite von 5Mbit. VPN Router 1 Wählt somit also Gateway Router mit einer Bandbreite von 13Mbit

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.

== Quellen ==

== Quellen ==