hohe Last

[tmk]

Hallöchen!

Ich beobachte seit ein paar Tagen eine hohe Last auf huygens, dem Uplink in der kleinen Wolke hier. Geht mir der Router langsam durch? Oder muss ich eine Konfiguration anpassen? Habe lange nicht draufgeguckt...

Der Verursacher der Last ist anscheinend ksoftirqd, ein Kernelthread. Performance bricht dann ein von 12 auf 3 MBit/s.

Nach einem Reboot dauert es nicht lang, bis die hohe Last wieder auftritt.

Viele Grüße
Tim

[y02hal]

Hi everyone (Hallo zusammen )

diese Beobachtungen kann ich bestätigen. Es betrifft Router, die als HNA fungieren und es gibt zwei Szenarien, die dieses Problem hervorrufen können bzw. provuzieren:

Szenario 1: "zu viele" Nachbarn auf dem VPN-Server
Szenario 2: Computer am LAN-Port ("böses Windows")

Zunächst dachte ich ja, dieses Phenomen tritt an diesen Routern auf, die ich für die Verwendung im Freifunk "entdeckt" hatte (TP-Link TL-WR940N v6) und für die es ursprünglich keine Unterstützung gab und die bis heute nicht auf der Liste der Empfehlungen stehen. Daß es auch (insbeondere im Szenario 1) GL AR150 betrifft, die ich ja als sehr viel leistungsfähiger kennengelernt habe und durchaus als so eine Art "Geheimwaffe" gelten können, (schon mal auch auf Grund ihres _sehr moderaten_ Stromverbrauches, aber auch wegen ihrer Kompaktheit und Funktionalität) überraschte mich dann doch schon etwas...

Damit nichts durcheinanderkommt, möchte ich meine Beobachtungen aus beiden Szenarien in gesonderten Posts darlegen....

Geht los....

[y02hal]

Szenario 1: "zu viele" Nachbarn auf dem VPN-Server

Router, die als HNA fungieren, leiten den Internetverkehr bekanntermaßen über VPN-Tunnel um. Uns stehen derzeit 3 VPN-Server-Zugänge für diesen Zweck zur Verfügung. Die Auswahl, welcher es denn nun wird, ist wohl zufällig.

Abhängig von der Anzahl der HNAs, die zeitgleich mit einunddemselben VPN-Server verbunden sind stellt sich ein "Dauer-Traffic" am WAN-Port jedes einzelnen Routers ein, der Bandbreite bindet, auch wenn keine User verbunden sind. Je größer diese Liste ist, desto höher ist auch der Durchschnittswert dieser so gebundenen Bandbreite. In meinem Fall betrug dieser Wert auch schon mal bis zu 3 MBit/s.

Aber um wieder zum eigentlichen Thema zu kommen: für die Größe dieser Liste scheint es eine Grenze zu geben, ab der die Systemlast im Router ganz gehörig ansteigt und dann zum beobachteten Phenomen führt.

Da die Auswahl wohl vorrangig auf diesen Server fiel, betraf das in der Vergangenheit immer alle HNAs, die an VPN3a hingen. Der Zustand normalisiert sich nach Neustart natürlich dann NICHT, wenn der Router entschieden hat, wieder den selben stark frequentierten VPN-Server auszuwählen, mit dem er zuvor schon verbunden war.

Der aktuelle Zustand ist wohl so, daß an VPN3a sehr viele Router hängen, dagegen an VPN3b und VPN3c sehr viel weniger.

Mögliche Lösung kurzfristig: eine gleichmäßigere Verteilung aller HNAs auf die VPN-Server?
Mögliche Lösung längerfristig: wie kurzfristig, dazu zusätzliche VPN-Server?

[y02hal]

Szenario 2: Nutzung der/des LAN-Ports

An sich ist es legitim, am eigenen FF-Router auch über LAN Freifunk zu nutzen. In der Praxis habe ich aber schon den Eindruck gewonnen, daß das offensichtlich dann wohl doch keine so gute Idee ist.

In meinem Fall versuchte ich das an einem HNA und stellte fest, daß das binnen kurzer Zeit zu einer immens hohen Systemlast im Router führen kann. Insbesondere Windows ist ja dafür bekannt, im Netzwerk "eigenartige Dinge" zu tun, was über die einzelnen Versionen stetig zugenommen hat und m.E. bei Windows 10 extrem auf die Spitze getrieben wurde (m.E. ohne erkennbaren Mehrwert für den Anwender).

Überraschend für mich war, daß dieser Effekt dort verstärkt mit einem Router auftrat, der auf der Liste der Empfehlungen steht (TP-Link TL-WR842N/ND).

Ob sich dieser Zusatand auch so einstellt, wenn der FF-Router KEIN HNA ist, habe ich nicht untersucht.

Im Szenario war ein TP-Link TL-WR940Nv6 als HNA im Einsatz mit einem PC mit Windows 10 am LAN-Port. Lösen lies sich das nur, indem der PC über WLAN mit Freifunk verbunden wurde. Anders ließ sich der überdurchschnittliche Anstieg der Systemlast im Router in dem Fall nicht in den Griff bekommen...

[tmk]

Danke für die Hinweise.

Tatsächlich hängt an dem Router eine DVB-2/HbbTV-Box via LAN-Kabel. Habe die Box jetzt mal rausgezogen, ändert leider nichts. Da läuft, glaube ich, ein Android drauf, bin mir nicht sicher. Aber die macht sowieso fast nie Traffic. Die hing da auch schon über ein Jahr dran, es ist bestimmt das andere Problem mit zu viel Info durch den Tunnel vom Server. Habe in anderen Freifunkforen auch gelesen, dass dieses Problem in der 2017er OpenWRT-Version auftritt, die verwenden wir auch.

Ich denke ja schon länger darüber nach, etwas stärkeres als HNA zu nehmen. Für einen Turris Omnia gibt es OpenWRT-Images, die nur SFTP-Anschlüsse und die Rainbow-LEDs nicht unterstützen, sowie nur 1 WAN an die CPU hängen, statt zwei. Das wäre für Freifunk aber ausreichend. Da müsste ich aber irgendwie gluon noch draufbasteln. Einfacher wäre es vielleicht mit einem Raspi. Für den 2er und 3er habe ich gluon-Images gefunden, da müsste ich nur die Halle'sche Site-Conf einbinden. Die heißt aber bei uns anders, oder? Kann mir jemand sagen, welche Datei in unserer Firmware genau die Site-Conf ist, von denen die anderen Communities reden? Ist es bei uns /lib/gluon/site.json? Wenn ich noch ein bisschen warte, gibts das gluon vielleicht auch für den Raspi 4, von dem habe ich schon ordentliche Messwerte LAN-zu-WLAN gesehen im Netz, der würde sich besser eignen als die Vorgänger, die alles durch einen USB 2-Hub quetschen.

Viele Grüße
Tim

[y02hal]

...um aus dem gluon fremder Communities das für FF Halle zu machen, müßte m.E. der Austausch von

/lib/gluon/site.json
/lib/gluon/web/i18n/gluon-site.de.lmo

völlig genügen...

[tmk]

Cool, danke!

[tmk]

Hallo! Ich bekomme jetzt auch von anderen Stellen mitgeteilt, dass "das Freifunk nicht richtig geht". Hohe Last auf den Routern führt zu unbenutzbarem Internet. Z. B. im Czech, da kann man nicht mal einen Radiostream geradeaus abspielen.

Ich hab mich ein bisschen informiert und sehe, dass das System nicht so gut skaliert auf der "Plastehardware". Aber 1) unser Netz ist nicht mal 200 Nodes groß und 2) ich sehe das Problem auch auf Routern, die nicht billigst sind, z.B. WDR4300.

Kann ich irgendwie, irgendwo helfen, das Problem einzugrenzen und zu lösen?

[tmk]

Hey 3dfx, ich habe gesehen, dass du die VPN neugestartet hast, es war kurz alles rot Hat leider nichts gebracht

Ich könnte am 20.08. zum EBK-FF-Treffen kommen, hast du da auch Zeit für VPN-Analyse und/oder Firmware?

GLG
Tim

[tmk]

Moin moin, wurde etwas unternommen? Wenn ja, was? Anscheinend geht es an manchen Routern wieder besser, inkl. huygens. GLG Tim

[dac524]

Wir haben diskutiert wie man die zufällige Verteilung der Knoten beeinflussen kann. Meines Wissens wurde an dieser Thematik aber noch nichts verändert. Die von Dir festgestellte geringere Last dürfte reiner Zufall sein.

[tmk]

Ok, gut zu wissen erstmal. Ich glaube aber, dass eine Neu- oder Umverteilung uns zunächst nichts bringt, weil wir insgesamt nur knapp unter 200 Nodes haben. Treten die batman-adv-Skalierungseffekte nicht erst bei 1000+ Nodes auf?

Ich befürchte ja, es ist noch ein anderes Problem. Huygens jetzt gerade z. B., der macht nichts, sind zwar Clients in der Wolke aber die sind idle. Er empfängt aber permanent 1,5 - 2 MBit durch den Tunnel und dabei steigt seine Last auf 2 bis 3,5. Diesen ankommenden Traffic pusht er auch auf keine Clients oder Nachbarrouter raus, das sehe ich im bwm-ng. Hauptverantwortlich für die Last ist der Kernelthread "ksorftirqd" wieder. Der brauchte in den letzten 30h fast genauso viel CPU-Zeit wie der fastd-Tunnel. Normalerweise ist dieses Verhältnis ung. 1/10. Bandbreite gerade auf meinem Telefon, 2 Meter neber der Node: knapp unter 1 MBit runter und knapp unter 2 MBit raus. Da ist doch was im Busche?

[tmk]

Fyi, es ist wieder soweit: seit zehn Tagen macht mein Uplink-Knoten nichts anderes, als SoftIRQs abarbeiten ("ksoftirqd" 100% CPU-Zeit).

Ich habe gestern den Knoten durch einen baugleichen, neuen ersetzt - leider gleiches Phänomen.

VPN3 schickt ohne Unterlass 3 Mbit/s. Handy direkt neben die Antenne halten bringt heute sogar nur 1/4 Mbit/s (~ 30 kbyte/s), Freifunk ist hier mehr oder weniger nur auf der Karte online.

3d und ich treffen uns bald, neue Firmware bauen, vielleicht hilft das.

Die anderen beiden VPN scheinen nicht betroffen, auch Verbindungen mit VPN3 hatten seit Mitte August wieder funktioniert.

[tmk]

Hi, kann ich vpn3 testweise verbieten/auskommentieren für den Node hier? Wenn ja, in welcher Datei?

[tmk]

Soweit ich jetzt herausgefunden habe, könnte es eine falsch konfigurierte LAN-Brücke sein, die in unserem (alten) Batman zu Topologiefehlern führt, die dann die Nodes fluten.

ksoftirqd ist es, weil fastd im Userspace läuft und er für jedes Paket einen Kontextwechsel vornhemen muss. Nicht weiter wild, aber falls die Topologie doppelt/falsch announced/mitgeteilt wird eben doch nervig, weil man nicht mehr surfen kann.

Kann mir bitte jemand helfen? Wir sind hier offline. Es ist ganz furchtbar.

Edit: sind vpn{1,2,3} bei uns via Layer 3 (Routing) oder Layer 2 (batman) verbunden?

[tmk]

Neue Firmware hat nichts verbessert, surfen immer noch unmöglich

Edit: Es liegt nicht am Freifunk, sondern am Router davor. Wenn die Node direkt am Modem hängt geht alles. Thema erledigt hier. VG

[Klops]

Hallo,

ich habe heute festgestellt, dass die Internetverbindung in der Südstadt (Umsonstlädchen) nicht funktioniert.
Selbst am neuen Knoten WG1 sehr lahm.
Ich komme vom WG1 auch auf keinen anderen internen Knoten.
Vielleicht ein anderes Thema, vielleicht aber auch nicht.

Grüße

k.

[tmk]

So es ist tatsächlich wieder passiert, ich habe langsam keine Ideen mehr...

Nachdem ich den LAN-Router vor dem Freifunkrouter ausgetauscht hatte (Turris Omnia ersetzt durch Stock-Firmware TP-Link WDR4300), und auch die Kabel, und es seitdem gute vier Wochen wunderbar lief, ist die Last auf dem Freifunkrouter seit zwei Tagen wieder maximal hoch.

Mein LAN besteht seit vier Wochen nur aus Modem, LAN-Router, und daran Freifunkrouter und ein Rechner. Server, Laptos, WLAN-Radio, der ganze Kram, ist alles aus seit geraumer Zeit.

Im Anhang auf dem Bild von bwm-ng sieht man, dass der Freifunkrouter ordentlich Daten bekommt (280 kByte auf eth0), aber kaum weiterleitet nach client0/mesh0 und client1/mesh1. Das merkt man halt, Speedtests mit 1000 ms Ping und Bandbreite < 1 MBit auf dem Endgerät.

Auf dem Bild von htop sieht man, dass ksoftirqd "running" ist. Das ist auch nicht schlimm, aber es passiert ggü. dem normalen Betrieb viel zu oft. Die Last des fastd-Tunnel ist auch ganz schön hoch dafür, dass die Node einem fast kein Internet gibt und nur knapp 300 kByte ankommen.

Was kann das noch sein?

[dac524]

Hallo Tim!

Es tut mir Leid, dass Du nicht vorwärts kommst. Meine FF-Router sind auch mit einem Turris-Omnia verbunden. Deine Probleme tauchen bei mir aber nicht auf.

Welche Konfiguration verwendest Du für diese Geräte? Die Turris-Config läßt ja einige Voreinstellungen zu, die zu erhötem Traffic führen können. Zum Beispiel der auswählbare Honeypot und der VPN-Rückkanal zum Hersteller.

Ich kann mir vorstellen, dass es bei einer Mischung aus eigener und aus voreingestellter Konfiguration zu Situationen kommt, die man nicht beabsichtigt hat. Evtl. ein Loop über die vielen Schnittstellen oder etwas Anderes in der Art.

Ich hab zwei Turris-Router. Der eine läuft im Moment mit der Standart-Konfiguration (ohne Alles). Der Andere muss als Testgerät herhalten. Dort wollte ich Früher oder Später FF drauf laufen lassen. Bis jetzt hab ich dafür aber nicht den Kopf frei.

Wenn Du Lust und Zeit hast, können wir unsere Setups detailliert vergleichen. Vielleicht kann ich Deine Probleme nachstellen.

Viele Grüße,

Alex...

[tmk]

Hallo Tim!

Hallo Alex! Danke für deine Antwort.

Meine FF-Router sind auch mit einem Turris-Omnia verbunden. Deine Probleme tauchen bei mir aber nicht auf.

Damit kann ich schonmal ein Update des Turris als Ursache mehr oder weniger ausschließen, danke.

Welche Konfiguration verwendest Du für diese Geräte?

Ich habe den Turris auf Werkszustand zurückgesetzt (Knopf halten bis 3 Lampen leuchten) und den Wizard durchlaufen. Problem bestand noch. Dann ist der Turris mal als Client im LAN mitgelaufen, nach dem Auto-Update die Nacht danach habe ich auch mal die drei standardmäßig ausgewählen "Softwares" NAS, LuCI-Extras und Extra-Protokolle entfernt. Das macht für mich funktional keinen Unterschied, Problem besteht aber noch.

Ich hab zwei Turris-Router. Der eine läuft im Moment mit der Standart-Konfiguration (ohne Alles). Der Andere muss als Testgerät herhalten. Dort wollte ich Früher oder Später FF drauf laufen lassen. Bis jetzt hab ich dafür aber nicht den Kopf frei.

Irgendwann schaffen wir das Ich habe die gluon build-chain jetzt auch auf meinem Rechner und konsultiere regelmäßig Matthias, habe aber bisher Richtung Firmware für den Turris noch nichts unternommen.

Wenn Du Lust und Zeit hast, können wir unsere Setups detailliert vergleichen. Vielleicht kann ich Deine Probleme nachstellen.

WLAN ist aus beim Turris, das ist eigentlich die einzige Abweichung vom Standard. DNSSEC habe ich angelassen und LAN-Domainnamen werden nicht weitergeleitet (beides standard). In LuCI habe ich jetzt noch nichts eingestellt, dort mache ich normalerweise auch nur folgende Sachen: Port-FWs, DynDNS und MAC ↔ IP DHCP-Einstellungen für mein LAN.

Bevor ich jetzt denke, dass es die Hardware ist, werde ich noch einen tcpdump auf dem Turris und, wenn ich es hinkriege, auch auf der Freifunknode machen während das Ganze auftritt, dazu muss ich aber wieder mal alle meine Nachbarn offlinen für eine Weile und ich muss auch mal ein paar Stunden Lust haben

Viele Grüße
Tim

[tmk]

Ich habe den TCP-Dump gemacht. Es ist bestimmt nicht die Hardware. Im Mesh-VPN bekommt meine Node alle 20 Sekunden für jeweils knapp 6 Sekunden lang ICMPv6 Multicast-Pakate. Richtig krass viele. Viel, viel mehr als BATMAN oder andere Pakete/Payload. Ich vermute, dass es die Ursache ist, aber ich weiß es nicht genau und ich weiß auch nicht, wie es zu lösen sei.

Wenn mal jemand draufschauen könnte... Ich lade den Dump aber nicht hier rein, da sind die Anfragen meiner Nachbarn ans Netz drin. Obwhol, innerhalb der 3 Minuten, 100k Pakete, sind das sowieso nur ganz wenige... Trotzdem ist es wahrscheinlich besser, ich zeige das am 19.11. beim Stammtisch? Ist jemand da, der Wireshark lesen kann?

[y02hal]

...offensichtlich gibt es einen Zusammenhang mit der Größe der Liste der gleichzeitig mit dem VPN-Server verbundenen Nodes.... wird eine "magische" Anzahl überschritten, nimmt die Last dramatisch zu und das ohne "Ansehen der Person" (betrifft so gut wie jedes Routermodell).... diese erzeugen offenbar diese massiven ICMPv6 Multicast-Pakate.

Mein "Würgaraund" ist erst mal, zu vermeiden, daß vpn3a benutzt wird. Die Auswahl wird ja eigentlich per Zufallsprinzip getroffen. Offensichtlich ist aber trotzdem die Liste von vpn3a am Größten. Bewerkstelligen läßt sich das in /etc/config/fastd (oder das dazu passende uci-Kommando)...

[tmk]

Bewerkstelligen läßt sich das in /etc/config/fastd (oder das dazu passende uci-Kommando)...

Kannst du eins von beiden oder beides konkretisieren bitte? Ich habe mir die Datei angeguckt, es springt mich aber nicht an, wie ich einen der VPN-Server darin "abschalten" kann...

[y02hal]

... habe lediglich den Namen des Servers (vpn3..) durch 2 Einträge mit vpn3b.. und vpn3c.. ersetzt. Das bewirkt, daß fastd selbst eine Auswahl zwischen diesen beiden trifft und vpn3a.. nicht mehr nachgefragt wird. Ursprünglich wird diese Auswahl auf dem Server getroffen. Jetzt wird diese Serverentscheidung umgangen...

[tmk]

Code: Alles auswählen

(...)

config peer 'mesh_vpn_backbone_peer_vpn3'
	option enabled '1'
	option key '123'
	option net 'mesh_vpn'
	list remote '"vpn3b.freifunk-halle.org" port 10000'
	list remote '"vpn3c.freifunk-halle.org" port 10000'
	option group 'mesh_vpn_backbone'

So?

[y02hal]

..ganz genau so...

[tmk]

Danke! Das klappt offenbar! Die Wolke hier ist wieder online.

Ich werde den corax-1 noch umstellen müssen, damit es dort wieder geht.

Ich finds nur komisch, dass es bei uns schon mit relativ wenig Knoten zu Problemen führt.

Ich bin aber auf jeden Fall super dankbar für den Workaround!

VG

[y02hal]

...man betrachte das wohl als die experimentelle Komponente am Freifunk