(die gateways haben immer die mac adressen de:ad:be:ff:ff:0{vpn Nummer}
Interpretiere ich das richtig? und wenn ja, ist doch eigentlich überflüssig. Man könnte doch einfach ein script schreiben, das schaut, ob eine fastd verbindung besteht und wenn ja, dann dieses gateway auch als gw wählen
manchmal pendelt sich das noch ein … die mesh-vpn verbindung hatnur 195 (von 255) und da die gw class in der regel 20 ist,müsste der besser sein als 218 + 20 …
ein gesunder DSL uplink ernicht saturiert ist, hat 255.
dieser Wert baut beim IF_up sich von unten nach oben auf … ganz grob 1-2 pro Sekunde.
batman ttvn
ich versteh nur bahnhof Wie kann ich jetzt die ausgabe interpretieren? was heisst die 195? hat das was mit hop_penalty zu tun? die ist auf unseren gateways auf 60 gestellt.
kannst du das vielleicht noch mal für einen Laien erklären?
Ja, so ein Script könnte man bauen.
Nur was sollte es denn in Deinem Beispiel tun?
Es gibt offensichtich in Deinem netz da derzeit kein batman-Gateway „ff:03“.
Wenn das Script nun „blind“ den Gateway auf ff:03 setzen würde, nachdem es erkannt hat, dass es an VPN3 hängt: Was wäre dann der „Erfolg“?
„Heute kein Internet“? Das klingt dann nach dem Effekt den einige Communities haben, die per DHCP gateways versteilen, die nichtmal anpingbar sind, geschweige denn etwas routen.
Sprich: Mit so einem Script würdest Du Dir die Rippen brechen.
Sei doch froh, dass Du wenigstens automatisch dann das Gateway nutzt, das von Deinem Knoten offensichtlich am besten erreichen kannst. Der Batman hat das doch für Dich herausgefunden!
hat er eben nicht! mein router bleibt mit einem gateway als standardgateway verbunden, obwohl es dieses nur durch ein anderes gateway hindurch erreichen kann. unser vpn3 funktioinert ja einwandfrei, trotzdem verbindet er sich weiter zu einem weiteren gateway um von da aus ins internet zu gehen. dieser inter-gateway traffic ist doch total überflüssig, wenn das erste gateway schon ins internet kann!
man müsste in das zu programmierende script natürlich die internetverbindung des gateways auch mit prüfen, und nur dann, wenn diese ok ist das gewählte gateway forcieren.
Oh Gott, wie adorfer schon gesagt hat schießt du dir damit selbst ins Knie.
Die Ausgabe oben zeigt das in eurem Netz oder mit der DSL Leitung ein Problem besteht.
Ein VPN Link sollte nach max.5min auf 255 stehen, wenn nicht gibt es Paket Verlust. Batman hat das gemerkt und den Weg mit dem geringsten Verlust gewählt. Bevor du ein völlig Schwachsinnigen Script schreibst solltest du das lieber debugen.
Gruß
@rubo77 … ich denk wenn du mehr einblick in das Batman ttvn Konzept hast, dann klärt sich vielvon selbst. Batman Pakete (also alles in diesem Fall) werden an die „Ziele“ (Gateway in diesem Fall) mit bester TTVN geschickt. TTVN kann bis zu 255 erreichen, dann ist Paketloss=0 und alles super
Paketloss verringert das ttvn (zumbeisiel weil die Leitung dicht ist,oder buggy) hop_penalty setzt bei jedem hop eine penalty, wenn ich also durch meinen Router (normal penalty 15) durch euren Server (penalty 60) auf vielleicht einen anderen server (nochmal 60) auf einen Router (15) der mesht (nochmal 15) gehe hab ich allein durch penalty 255 - 15 - 60 - 60 - 15 - 15 = 90 … das wäre (bei perfekter connection zu unseren Routern - die ttvn zwischen uns) gw_class 20 bedeutet das dein Router das GW nur wechselt wenn er ein anderes sieht, dasmind. 20 besser ist,ansonsten bleibt der da stecken. timing: wenn das if mesh-vpn hoch kommt steigt die ttvn langsam von null nach oben
und nochmal, eine gesunde DSL uplink mesh-vpn Verbindung hat 255 zu den servern.
hoffe das machts klarer, du muss rausfinden warum du miserablen mesh-vpnquality hast, anstatt das korrekt funktionierende Batman kaputt zu optimieren.
Wenn die Ausgabe im Startpost korrekt war (also Du nicht darin herumgelöscht hast), dann kennt Dein Batman-Netz schlicht kein BatmanGW auf dem Supernode VPN3 (mit dem Dein Fastd-Tunnel besteht).
Warum dem so ist: Solltet ihr Debuggen, wenn das nicht von Admin-Seite (oder einem intelligenten Script so absichtlich) eingestellt worden sein sollte.
Ich kenne z. B scripte die das Batman-Gw (aber auch den dhcp und den fastd) abschalten, wenn der Supernode „merkt“, dass seine Tunnel in den Backbone dauerhaft „weg“ sind
Das im einleitungspost ist original kopiert. Aber wie liesst man aus dem „zahlenkauderwelsch“ dass das vpn3 (de:ad:be:ff:ff:03) nicht als BatmanGW arbeitet? Hast du das reininterpretiert, weil erst in der zweiten Zeile der Pfeil kommt?
Wenn „batctl gwl“ es nicht als Gateway listet, dann ist es entweder keines oder Dein Knoten kennt keine Route dorthin.
Kannst Du Dir aussuchen. Beides führt jedoch dazu, dass Du es nicht als Gateway nutzen kannst, egal was da ein zukünftiges Script tun könnte.
(Es sei denn, es hätte telekinetische Kräfte.)
was mich wundert warum man in den Gluoncommunitys so „krumme“ Installationen verwendet.
2-3 Gateways pro Broadcastdomäne/Layer 2 Netz/Hood und jeder VPN Router baut zu jeden Gateway einen Tunnel auf. Die Lastverteilung übernimmt die Gatewayselection (je weniger ein Gateway ausgelastet ist, umso höher die Bandbreite die es announcen sollte, kann ein kleines Script gut machen).
Nachteil ist ein wenig der höhere Overhead. Wir verwenden das Setup so und mit Batman 2013.4 ist das ganze bis ca. 150 Router und 500 Clients noch gut nutzbar, ab dann fangen wir an die Broadcastdomänen aufzuteilen und dazwischen auf Layer 3 Basis zu routen.
Klappt bei uns sehr gut und wir haben nicht das Problem mit den „Umwegen im Batmannetz“
Oder man macht den Eulenfunk-Ansatz: Nur einen Supernode (Fastd-Server, Batman-Gateway) pro broadcast-Domain.
Aber das soll hier ja nicht das Thema sein.
Hier geht es darum, wie man einen Gluon-Knoten dazu bringt, einen Node als Gateway zu nutzen, der sich selbst nicht als Gateway announced oder aus anderen (mirakulösen?) Gründen nicht in der GWL aufgeführt wird.
@ChrisD und @adorfer (wobei du das vermutl weist) … es ist schon bekannt das eine Auswahl der GW über bandbreite in Batman nicht wirklich sinnvoll funktioniert (für den gluon Freifunk fall). Das geht hier nur mit gw class 1 und 2 und bedeutet das gleich starke gw die bandbreite mit in ihre bewertung einbeziehen, das gilt dann aber für alle clients … und ist so nicht wirklich brauchbar. AFAIK
Ein reines announcen von bandbreite mit gw class 20 bewirkt NICHTS. @rubo77 der „Pfeil“ => bedeutet nur welches GW gewählt wurde, also letztendlich das du ein gw client bist und das es mind. ein GW server im batman Netz gibt.
(da kommt dann layer violation ins spiel (dhcp) oder die frage, was macht einen batman gateway technisch eigtl zu einem batman gateway (ausser der eigendefinition batctl gw server class xyMbit) - aber das muss wer anders erklären)
In der Tat bekannt. Daher ja der Ansatz mit nur einem einzigen Gateway pro Domain.
(Dafür muss man dann eben auf Stabilität konstruieren und ein effektives Monitoring darüber schnallen)
Ich sehe in diesem Thread nach wie vor das Rätsel, wie man einem Batman-Knoten ein Gateway unterschieben könnte, das sich selbst nicht für ein Gateway hält.
meinst du diesen Overflow Bug der mittlerweile gefixt wurde? Als wir das vor gut nen halben Jahr eingeführt haben war das wirklich ziemlich random was da ausgewählt wurde, hat sich rausgestellt das sich da nur mehrfach verzählt wird
Ansonsten muss man halt bedenken, das nicht nur die announce Bandbreite mit reinfliest sondern auch die Metrik in die Berechnung.
Funktioniert hier bei uns mit den Fix wunderbar und es wird eigentlich immer das Gateway ausgewählt, das die höchste Bandbreite announced.
Nur ein GW pro L2 find ich unschön, bei Ausfall ist sie kaputt hmh?
Zum eigentlichen Problem:
Was passiert wenn man die Gatewayselection gar nicht verwendet und einfach DHCP in seiner Urform? Der schnellste Server gibt dir eine IP, das solte ja in den meisten Fällen der erste Hop sein (außer die Kiste ist hoffnungslos überlastet und der DHCP Server braucht ewig bis er es bearbeitet hat dann is aber eh was faul ;))
stimmt, die Throughput metrik (batman 2016xy - v15) hab ich vergessen, bzw noch nie ausprobieren können. Weil wir hier sehr stoisch worksformeauf batv14 verweilen. Wenn das funktioniert find ich das klasse.
und die paar Testinstinstanzen taugen nicht wirklich für nen belastbaren Test.
Wie ist dann eure Einstellung zu gw class und gw client <int>?
das will ja gar keiner, vielleicht war das gateway 3 ja wirklich gerade kaputt gestern, als ich den output kopiert hatte. Wir hatten da gestern ein Problem mit einem abgelaufenen vpn-anon konto in kiel, wodurch alle openvpn instanzen kaput waren und unser watchdog da ev. den gatewaymode ausgeschaltet hat. also bitte nicht weiter darüber reden jezt.
Normalerweise funktionieren unser gateways ja und da habe schon oft beobachtet, dass ein Knoten ein gw ausgewählt hat, das nicht das gw ist, mit dem er per fastd verbunden ist.
Wir wollen ja gar nicht das „schnellste“ gateway wählen, sondern eins für fastd per random wählen (um die Last im Netz zu verteilen) und dann auch genau über das gewählte auch ins internet.
keine weitere route zu einem vermeintlich schneleren gateway von da und dann von da aus erst ins Internet
Throughput Metrik bei Batman 2016? gw class? Wir haben auch nur Batman 2013.4 und das kann das auch schon:
Auf dem Gateway:
******:/home/christiand# batctl -m bat0 gw
server (announced bw: 32MBit/12MBit)
auf einem Router (in diesem Fall hat das L2 Netz nur 2 Gateways, in manchen haben wir auch 3 oder gar 4):
root@UplinkNeunhofNEW:~# batctl gwl
Gateway (#/255) Nexthop [outgoingIF]: gw_class … [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: eth0.3/f8:1a:67:a6:05:4f (bat0)]
=> fa:c2:de:52:6e:37 (255) 0a:72:12:33:14:38 [ l2tp0]: 76 - 32MBit/20MBit
be:db:3c:ab:5d:d7 (252) be:db:3c:ab:5d:d7 [ fffVPN]: 74 - 32MBit/12MBit
root@UplinkNeunhofNEW:~#
ist jetzt grad bisschen blöd, weil beide Gateways die gleiche Bandbreite announcen aber viele Tests haben ergeben, das meist (wenn nicht die Metrik dazwischen funkt was aber bisher nie wirklich der Fall war) immer das GW genutzt wird das die höhere Bandbreite announced. Auf den GWs läuft dieses Script:
Batman wandelt die Broadcastanfragen um und sendet die Discovery überhaupt nur zum nächsten Gateway, damit das Netz nicht so geflutet wird. DHCP in Batman ist Unicast.
Könnte man? Ich suche gerade die Option in batctl das Gateway zu setzen und sehe nix. Tante Google ist wohl auch noch in Weihnachtsmüdigkeit und gibt mir nix passendes.
Wie kann ich jetzt die ausgabe interpretieren? was heisst die 195? hat das was mit hop_penalty zu tun? die ist auf unseren gateways auf 60 gestellt.