Re: Batman Link alternating (Bonding) (Was: [Freifunk Franken] Speedtest Hardhöhe.)

Do Jan 7 13:56:26 CET 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo zusammen

ich hab mal wieder etwas herumgegoogelt und bin auf folgenden
(interessanten) Beitrag gestoßen:

https://forum.freifunk.net/t/load-balancing-per-batman-adv-bonding/9754

Die ASCII Grafik von PetaByteBoy ist dort ganz interessant (und war
für mich sehr verständlich, ich glaub damit hab ich jetzt bonding erst
mal richtig kapiert):

Ich hab sie mal ein klein wenig überarbeitet und auf die Hardhöhe
angepasst, siehe Anhang (die Pfeilfarben sind links unten beschriftet
was sie bedeuten). Hier haben wir auch die Ethernetleitung die
PetaByteBoy in seinem Beispiel wohl fehlt.

Dabei gilt jetzt in diesem Beispiel, wir wollten den Traffic von
Höffner auf ChristianD und delphiN aufteilen, nicht unbedingt weil
Internet langsam ist sondern der begrenzte Faktor dürfte hier eher das
WLAN über fue0x und fue0y zu den jeweiligen Gegenüber spielen.

Wenn nun auf fue0x bonding aktiviert wird sollte doch gelten:

- - Daten kommen über Ethernet (full-duplex) rein auf fue0x.
- - fue0x hat nun die Auswahl über Ethernet oder WLAN weiterzugehen.

theoretisch könnte nun fue0x bonding machen oder? WLAN müssen die
Daten nur raus und Ethernet ist ja full-duplex fähig so das hier
gleichzeitig rein und raus geht?

(Pfeile sind wohl gerade verkehrtherum gezeichnet, weil die meisten
Daten wohl eher genau in die andere Richtung fließen aber ich denke
zum Verständnis reicht es)

Meinungen?

mfg

Christian

Am 06.01.2016 um 11:11 schrieb Tim Niemeyer:
> Moin Ralf
> 
> Am Dienstag, den 05.01.2016, 21:03 +0100 schrieb R.funkt:
>> Am 05.01.2016 um 12:30 schrieb Tim Niemeyer:
>>> Guten Morgen Ralf
>>> 
>>> Ich hab mal die -dev Liste inc CC gepackt.
>>> 
>>> Am Dienstag, den 05.01.2016, 08:37 +0100 schrieb R.funkt:
>>>> Am 04.01.2016 um 23:51 schrieb Tim Niemeyer:
>>>>> Moin Ralf
>>>>> 
>>>>> Am Montag, den 04.01.2016, 23:06 +0100 schrieb R.funkt:
>>>>>> Ich habe in den Ferien mal anfangen, mich in batman-adv
>>>>>> einzulesen, bin aber auch noch weit weg von 100%. (Hab
>>>>>> auch schon was zusammengeschrieben fürs Technik-Portal,
>>>>>> kommt demnächst.) Jedenfalls stimmt deine letzte Aussage
>>>>>> (= batman ist dumm). Zur Zeit macht batman kein
>>>>>> Load-Balancing. Batman sucht sich den Weg basierend auf
>>>>>> Anzahl der Hops (Parameter hop_penalty) und
>>>>>> Leitungsqualität (= Anzahl verlorener Pakete). Dabei wird
>>>>>> NICHT die Gesamtqualität bis zum Ziel berechnet, sondern
>>>>>> immer nur Hop für Hop betrachtet. In bestimmten Szenarien
>>>>>> (ein Hop) kann man sich mit Interface Bonding in Richtung
>>>>>> Load-Balancing bewegen, aber das trifft nicht auf das 
>>>>>> komplexe Hardhöhe Setup zu.
>>>>> 
>>>>> Ich hab das hier eher anders raus gelesen: 
>>>>> https://www.open-mesh.org/projects/batman-adv/wiki/Multi-link-opti
mize
>>>>>
>>>>>
>>>>> 
Tim
>>>> 
>>>> Hi Tim,
>>>> 
>>>> ich vermute, Du beziehst Dich konkret auf Interface Bonding? 
>>>> Wahrscheinlich müsste man das einfach mal selbst ausprobieren
>>>> und Erfahrung damit sammeln.
>>> Ne, ich hab nur die batman-adv Doku gelesen.
>>> 
>>>> Mein Verständnis ist, das Interface Bonding (ebenso wie
>>>> Ethernet Link Aggregation) ein Layer-2 Feature ist und
>>>> zwischen zwei Stations aufgesetzt wird. Falls man das ganze
>>>> von einem auf mehrere Hops erweitert, sind auf den
>>>> open-mesh.org Seiten Throughput Probleme dokumentiert, z.B.
>>>> hier (es gibt aber auch aktuellere Links):
>>>> 
>>>> "However, our tests have shown that bonding mode achieves
>>>> maximum throughput over single hops only. For multi-hop paths
>>>> interface alternating (see the next section) provides better
>>>> performance results."
>>> Richtig, das steht so auch in meinem Link oben drin. Daher
>>> setzen wir ja auch seit Jahren das "alternating" (was default
>>> ist) ein.
>>> 
>>>> https://www.open-mesh.org/projects/open-mesh/wiki/2010-12-12-batman
- -v-status-update
>>>>
>>>>
>>>> 
Ich denke, das liegt im Wesentlichen daran, dass keine Traffic Flows
>>>> verteilt werden (so wie bei Layer-4 Load-Balancing), sondern
>>>> (da wir ja nur auf Layer-2 sind) ein simples Round-Robin
>>>> Schema eingesetzt wird. Die Pfade dürfen sich daher in
>>>> Throughput und Buffering Latency nicht zu stark
>>>> unterscheiden, sonst gibt es Packet Re-ordering. Je mehr
>>>> Hops involviert sind und je komplexer das Setup ist, desto
>>>> schwieriger wird es, dies zu erreichen.
>>> Vermutlich ja. Aber in wie fern diese Entscheidung in die 
>>> Routing-Entscheidung eingeht weiß ich nicht. Ich kann mich da
>>> aktuell auch nur an der Doku orientieren, die sagt nämlich dass
>>> ein halb-duplex Interface eine penalty für die Weiterleitung
>>> bekommt. Daher würden bei der Hardhöhe die Weiterleitungen auch
>>> vermutlich immer über das Ethernet gehen. Paket über Wifi wird
>>> emfpangen, weiterleiten über Wifi (halb-duplex) is schlecht,
>>> also wird der zweite Weg (Ethernet) genommen.
>> 
>> 
>> Vorsicht! Die von Dir erwähnte "Network Wide Multi Link
>> Optimization" und auch die half-duplex Penalties kamen erst im
>> neuen (2014) batman-adv und sind somit für uns noch nicht
>> relevant:
> 
> Das Thema Alternating ist von 2010. Das müsste also in unserem 
> Batman-adv auf jeden Fall drin sein. Die Half-Duplex Penalty ist 
> offenbar erst seit 2014.1.0 benutzbar.
> 
> So oder so.. Irgendwann sollten wir mMn mal das batman-adv
> upgraden.
> 
> Tim
> 
>> 
>> Release batman-adv 2013.4.0 (= unser batman): 16-OCT-2013
>> 
>> Release patches für neues OGM handling: 21-NOV-2013 und später,
>> z.B. 
>> https://git.open-mesh.org/batman-adv.git/commit/46e44fdb96ef75e22134c
29de5a1191240b6ca1f
>>
>>
>> 
Release batman-adv 2014.1.0 (= batman mit hdx patch): 13-MAR-2014
>> https://www.open-mesh.org/projects/open-mesh/wiki/2014-03-13-batman-a
dv-2014-1-0-release
>>
>>
>> 
Weiteres Indiz: Unsere hop_penalty steht noch auf 30. Erst mit dem Fix
>> wurde sie auf den default Wert 15 halbiert, um die half-duplex
>> Penalty auszugleichen.
>> 
>> Grüße, R.funkt
>> 
>>> 
>>>> Ich bin mir zudem nicht sicher, ob das
>>>> Christian/delphiN-->Höffner Setup aufgrund seiner Y Struktur
>>>> überhaupt Bonding fähig ist. Auf jeden Fall bräuchte man
>>>> schon mal denselben Gateway Server.
>>> Wenn da nicht irgendwas grundlegend kaputt ist, sind beide
>>> Enden mit den selben VPN Servern verbunden. Also dort könnte
>>> (zumindest theoretisch) das alternierende Signal vom Batman
>>> wieder zusammen gefriemelt werden.
>>> 
>>> Tim
>>> 
>> 
> 
> 
> 

- -- 
Kontaktmöglichkeiten ChristianD (Christian Dresel):
Jabber: ChristianD at jabber.community
E-Mail: fff at chrisi01.de
Facebook: https://www.facebook.com/christian.chili
Handy/Whatsapp & Festnetz: auf Nachfrage
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWjmB6AAoJEOID5jPgWNLi61sQAKwIA1HJb9KBPhA3Fsm/EJ9m
gxD92nQ1SruL3mzTOpCM+P09KDlm4CZrYB2BNN5oz6xxck8iB7t2y2s0+Y7nE/hz
T88kzWW7lFpB7+6rP/X76e1FIPJ/WVp39bfaUMqvFLsNN/19rdjzoSJghmR0B5O6
gxwbZStuxqKiXvObLlbUTSzOpv6/jVads+tGfXOx/rF1SpB4S2SXTqkLgyglfU7c
6OnY8lzI6gwVd0K/kk/EKhBpioQvcub/MIsJJ3Vu4ex4exwIplB4FyNJ2u9szYzn
Xwk9QtNjbqSqTwR8sH3/A85dT68xunpPEnraWnMHhFcpA9QmEXMQJkXJGwoBv9Fz
ryJZZavoJbRQJ8oaE+n55YKVpsc4SxfIOW+gSxwbyrPYINRN0+ej4jvF6IETSui0
oxRD+t1fmFWfhcvGlivsgNWPsZ2XlYmJNZA9qRYxTyF0yqUvhuY7gPCQDovwBInJ
YZrFBtwfhIU4DDb6ElQhqSDL3meAsUw9jbUoz9Fp7L+L4sX2n2f+MhVPaSqgQDW0
TsiNspHA2pP+D4uTVqd0zoU+w4nfdbkFaK+usbyAny76hf0I6NwuJoO6SvefrT58
it3WqAjqSapBWIDCl01vF2lbNpvJj/B9QcCw5kvXrEYnH4fekw1GFeRRvl98Ri7v
9+HrbUohUpoJMXiCpRSX
=RhTE
-----END PGP SIGNATURE-----
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : bonding.png
Dateityp    : image/png
Dateigröße  : 20188 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160107/8d764f3e/attachment-0002.png>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : bonding.png.sig
Dateityp    : application/octet-stream
Dateigröße  : 543 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160107/8d764f3e/attachment-0002.obj>