Die Performance in Hennef ist aktuell gut bis sehr gut, die maximalen Datenraten im Download sind befriedigend. Aktuell ist wupper1 off und unsere Unitymedia-Knoten somit auch.
Kannst du schon abschätzen, wann du ein weiteres Gateway von außen per IPv6 erreichbar machst (so wie wupper1)?
Ich schätze, nachdem ich umgezogen bin kann ich mich Mitte Dezember damit befassen. Wupper ist zur Zeit heftig überlastet und ich muss da vorher dringende Baustellen abarbeiten, die ich immer wieder verschoben habe. Ich implementiere zur Zeit das L2TP BATbone. Sag mir bitte, lief IPv6 bei Euch bis zu deinem Posting?
Ja davor lief es (wupper 1 ist heute morgen irgendwann ausgefallen). Jetzt aktuell läuft wieder alles.
Noch ein mal zum Stand der Dinge. Derzeit wurden und werden Server in Wupper vereinzelt neu gestartet. Dies hat den Grund, dass sie dabei abstürzen, wenn ich L2TP einschalte, oder, dass ich den Server neu starten muss, um einen anderen Kernel zu fahren, ihn in den Debug-Modus versetze, die CPU-Anzahl ändern muss oder ihn aus anderen Gründen neu starten muss.
Alles außer einen Absturz wird den Wolken vorher „mitgeteilt“, d.h. die Nutzer wechseln das Gateway bei nächster Gelegenheit. Das machen sie in den nächsten 0-10 Minuten (IP mittels DHCP erneuern) und bekommen davon nichts mit. Ein neu zu startender Server ist auch nach 1 min wieder da. Je nach Betriebssystem kompensieren die Nutzer einen abgestürzten Server auch recht zugig. Am Smartphone kann man notfalls bei Dringlichkeit der Verbindung dies mit Aus- und Einschalten der WLAN-Verbindung erzwingen.
Derzeit, seit 10 h fahren w0 und w3 mit nur einem statt zwei CPU-Kernen und wollen einfach nicht abstürzen. Heute Nacht folgen Versuche mit CPU-Kern-Affinität einzelner fastd-Instanzen, was weiteres Licht ins Dunkel liefern kann.
Wie Ihr sieht hat entweder niemand fastd mit L2TP mit mehreren CPU-Kernen und mehreren Broadcast-Domänen gemischt oder hat beim Versuch aufgegeben oder schweigt zu diesem Thema.
Wir fahren eine Broadcast Domäne mit 4 GWs mit Dualkern CPU auf KVM, Debian 7, BATMAN_adv 2013.4, L2TP zwischen den Gateways in Vollvermaschung, FastD zu den Knoten. Außer unserer schwächsten VM die 2-3 mal die Woche mit Kernelpanic hängen bleibt, wackelt keines unserer Gateways mit diesem Setup.
Korrekt! Ich versuche auch mit Kerneldumps und Traces zu unterstützen.
Danke für die Antworten. Gut zu wissen, dass ich nicht allein bin … ich habe schon verzweifelt.
Wie kann ich die Traces aus einem SMP-Debian-Kernel-Dump extrahieren? Gibt es da einen Trick? Die unkomprimierte VMlinux liegt ja nicht als SMP vor. Fahre ich den Server nicht mit mehreren Prozessoren, stürzt dieser nicht ab. Ich lese mich da im Bugreport aber erst ein mal ein.
Fortsetzung der Diskussion von L2TP-BATbone 
:
Ich habe eure Kartenserver auf den Gateways eingetragen. Auf eurer Seite müssen sie sich zu allen vier Superknoten gleichzeitig verbinden.
Was muss ich denn auf den Rechnern nun ändern?
Derzeit kommt keiner der alten fastd-Verbidnungen zustande. (->Map und Karten derzeit offline für ffdus und ffgek)
Offline … ohje … einzutragen sind, wie im Wiki und in der fastd-Anleitung steht:
~ $ cat /etc/fastd/servers/wupper0
key "e52daa654abcf5c20c5b7a74b5145f70a7491435c6ef334ae352e4f19c00e8f5";
remote "0.wupper.ffrl.de" port 42;
~ $ cat /etc/fastd/servers/wupper1
key "6eae041199ee627689bfa026afbd8a9ab299eca8aed4144321d098cffd62668e";
remote "1.wupper.ffrl.de" port 42;
~ $ cat /etc/fastd/servers/wupper2
key "b7f319d59d8383ba813c3503416bca45f70852e4d207b1743bb6cdca1e30d9f5";
remote "2.wupper.ffrl.de" port 42
~ $ cat /etc/fastd/servers/wupper3
key "c8f3d1d10b0d6389e39c3c3cb08adfa3123e821fd5bfd6262d2161d80ee4b06c";
remote "3.wupper.ffrl.de" port 42042;
Port ist anzupassen, Adresse kann so bleiben. Ich deaktiviere das mal auf w3, damit die Verbindung schon mal da ist.
Mit den neuen Keys (stehen im Wiki) läufts seit kurz vor 12h wieder.
Nur was tue ich mit den Werten da oben? L2TP auf Port 42? Oder doch fastd? Ich bin da gerade etwas verwirrt ob des Topics weiter oben. Und welcher Port? bei w0-w2 auf Port 42, auf W3 Port 42042?
@phip Hier der aktuelle Stand aus Hennef
Wupper 0
Wupper 1
Wupper 2
Wupper 3
Wupper 2 wird gerade von fast allen Nodes favorisiert :-/
Kannst du Wupper 2 kurzfristig als Gateway rausnehmen? oder das Problem fixen?
Das Problem wurde Behoben: net.nf_conntrack_max bertägt nun 262144 auf jedem GW. Entschuldigt die Störung. Der Fehler war: ich habe gedacht. Bin erst jetzt nach Hause gekommen und habe das Problem selbst gemerkt.
Die ganze Woche lag die Zahl bei ca. 30 k aufsummiert über alle Server. Was auch immer im Netz los ist … 70 k … es ist wieder da … und ich hab ’s nicht kommen sehen.
sollte es in letzter Zeit zu Problemen mit Karten- und Graphdarstellungen gekommen sein: der angebundene und überlastete Service-Server wurde vorerst als die Ursache identifiziert. Dieser vom Verein gestellte vServer ist nicht in der Laage sich mit Wuppers fastd-Batbone zu verbinden … im Leerlauf und einer HopPenalty von 200 … von Meshviewern und Co auf diesem Rechner kann in der nächsten Zeit keine Rede sein. Dies muss weiterhin von den lokalen Freifunk-Gemeinschaften selbst erledigt werden.
Dieser vServer beherbergt das Wupper und Wuppertal-Ticketsystem, welches vorher bei Dustin lief, sowie einen Webserver für die Wuppertaler HP und die Firmware. Wenn jemand aus Wupper diesen vServer zum Hosten von Webseiten mitnutzen möchte: bitte Bescheid sagen.
Fortsetzung der Diskussion von Starkes Packet Loss FF-Emscherland:
im Tal kam zwischendurch nur die Hälfte durch
Ich hoffe, das stabilisiert sich jetzt
Die Gateways wurden vor einer Woche mit einer Hop Penalty von 100 versehen, um den Intersuperknotendatenverkehr auf ein Minimum zu bringen. Dieser kann nämlich nicht unverschlüsselt abgewickelt werden, da sich Batman dran verschluckt.
Derzeit ist bb-a.fra3.fra.de.ffrl.de abgeraucht. Dies betrifft w1 und w3. Alternative Routen funktionieren.
Es gibt Probleme, die ich nicht identifizieren kann:
Ich kann sie nicht reproduzieren und ich habe im Augenblick keine Zeit dafür. Ich bitte die Menschen vor Ort sich um Ihre Schützlinge zu kümmern. Ich bitte auch, dass Ihr eure Broadcast-Domänen auf Anomalien überwacht. Hier scheint es so, dass da jemand mit einem DHCP-Server experimentiert. Ich bitte solche Experimente vorher zu Kommunizieren.
die GL-Probleme sind nicht wieder aufgetreten (bislang).
