Änderungen

[[Datei:L3Rounting_with_babel_zoom_v1.jpeg]]

[[Datei:L3Rounting_with_babel_zoom_v1.jpeg]]

In dem Oberen Beispiel Bild sieht man einen genaueren theoretischen aufbaut der Hood OL. Für eine gewisse Übersichtlichkeit gehe ich hier auf v6 nicht ein. Der Hood OL ist das v4 Subnetz 10.18.152.0/21 zugewiesen. Dieses ist unterteilt in 24er Subnetze, wie man der Grafik auch entnehmen kann. Über das 10.18.154er Netz ist nun auch eine Nachbar Hood erreichbar, welche über Richtfunk angebunden ist. Behalten wir die Metrik im BATMAN-adv wie opben besprochen bei würden alle Clients des Netzes einfach eine Adresse vom RZ Gateway 1 bekommen das dieser eine wesentlich höhere Bandbreite bereitstellt als andere Gateways. Das passiert solange bist alle 254 Adressen des RZ Gateway Netzes aufgebraucht sind und die Gateway anouncmend abgeschaltet wird.

In dem Oberen Beispiel Bild sieht man einen genaueren theoretischen aufbaut der Hood OL. Für eine gewisse Übersichtlichkeit gehe ich hier auf v6 nicht ein. Der Hood OL ist das v4 Subnetz 10.18.152.0/21 zugewiesen. Dieses ist unterteilt in 24er Subnetze, wie man der Grafik auch entnehmen kann. Über das 10.18.154er Netz ist nun auch eine Nachbar Hood erreichbar, welche über Richtfunk angebunden ist. Behalten wir die Metrik im BATMAN-adv wie oben besprochen bei, würden alle Clients des Netzes einfach eine Adresse vom '''RZ Gateway 1''' bekommen da dieser eine wesentlich höhere Bandbreite bereitstellt als andere Gateways. Das passiert solange bist alle 254 Adressen des '''RZ Gateway 1''' Netzes aufgebraucht sind und die Gateway anouncmend abgeschaltet wird oder die Bandbreite unter andere BATMAN-adv Gateways singt. Die Bandbreite der '''RZ Gateway 1''' ist nicht real da die Limitierung (Bottleneck) in der Regel am VPN Router und dessen DSL Anbindung liegt. Das heißt der Schwerpunkt der Adressenverteilung liegt somit allgemein bei den RZ Gateways.

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

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 BATMAN-adv Gateways 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.

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.

Jetzt schauen wir uns mal genauer an, was passiert wenn die RZ 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'''  selber sieht nur das '''RZ Gateway 1''' als BATMAN-adv Gateway. Das liegt daran das andere BATMAN-adv Gateways vom '''RZ Gateway 1''' weg gefiltert werden, da die RZ Gateways eine Sonderrolle vertreten. Das Resultat ist also Das der '''VPN Router 0''' immer das RZ Gateway nehmen wird egal was für eine Bandbreite dieses announce. Am '''VPN Router 0''' hängt via Mesh über das 11s WLAN 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 alles 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 1''', '''Gateway Router''' und '''Rifu Gateway'''. '''Gateway Router''' anounced 16Mbit und '''Rifu Gateway''' eine minimal schlechtere Bandbreite von 10Mbit und '''RZ Gateway 1''' 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. Der '''Client 1''' bekommt somit eine Adresse aus dem 10.18.153er Netz. Analog dazu die Betrachtung von '''mesh Router 1''' und '''mesh Router 2'''.

 

 

Allgemein merkt man nun das der Schwerpunkt nun mehr auf Lokaler ebene sitzt. Wir haben die Kommunikation also auf die Richtfunkstrecken und Lokalen Exit Gateways forcieren.

 

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 ==