Performance und Planung der Wupper Infrastruktur


#1

War ich doch gestern so happy mit der Geschwindigkeit und ganz allgemein wie sich der FF anfühlte (Fastd encryption dauerhaft disablen), heute wieder der totale Rückschlag. Kurz nach 24 Uhr wurde der Supernode von meinem Router gewechselt, seitdem Katastrophe. WGET Durchschnitt 130KB / Ping Durchschnitt 137, Freifunk total unbrauchbar. Ist ungefähr ein Zehntel der Geschwindigkeit von gestern!

Aktuell verbunden bin ich mit 04:be:e1:ba:fe:00. Wenn ich mir den im Grafana anschaue so kann ich absolut nichts auffälliges an dem entdecken. Der Router scheint auch normal zu laufen. Aber im Ergebnis eine unbrauchbare Verbindung. Wenn jetzt so eine Installation draussen steht dann geht sofort das Geheule los. Wie kommt das denn nur das lediglich der Wechsel eines Supernodes solch fatale Folgen nach sich zieht?

Die erste 3 Zeilen waren noch der 10.3.0.240, danach schwenkt er um auf den 10.3.0.244, danach nur noch Grütze.

DATE HOST Ping minimum (ms) Ping Durchschnitt (ms) Ping maximum (ms) Abweichung (ms) Paketverlust % wget Transfer (KB/s) FF-GW
2018-02-22T00:00:39 8.8.8.8 38,922 40,32 44,92 1,64 0 1540 10.3.0.240
2018-02-22T00:01:39 8.8.8.8 39,084 41 52,46 3,86 0 1480 10.3.0.240
2018-02-22T00:02:39 8.8.8.8 38,935 46,42 107,5 20,37 0 1470 10.3.0.240
2018-02-22T00:03:41 8.8.8.8 87,737 156,99 383,73 107,8 0 270 10.3.0.244
2018-02-22T00:04:41 8.8.8.8 89,408 166,01 487,34 117,17 0 0 10.3.0.244
2018-02-22T00:05:42 8.8.8.8 88,037 104,83 160,15 25,11 0 0 10.3.0.244
2018-02-22T00:06:43 8.8.8.8 89,473 142,44 191,93 41,68 10 0 10.3.0.244
2018-02-22T00:07:41 8.8.8.8 87,933 131,13 407,84 93,12 0 0 10.3.0.244
2018-02-22T00:08:41 8.8.8.8 98,653 142,78 263,72 57,7 0 0 10.3.0.244
2018-02-22T00:09:42 8.8.8.8 88,469 131,87 238,92 49,27 0 0 10.3.0.244
2018-02-22T00:10:40 8.8.8.8 88,39 118,28 230,99 45,41 0 0 10.3.0.244
2018-02-22T00:11:40 8.8.8.8 92,371 108,32 208,46 33,65 0 123 10.3.0.244
2018-02-22T00:12:39 8.8.8.8 90,853 108,16 164,13 20,98 0 0 10.3.0.244
2018-02-22T00:13:40 8.8.8.8 87,372 100,52 124,75 11,68 0 131 10.3.0.244
2018-02-22T00:14:40 8.8.8.8 91,968 140,3 327,08 73,03 10 227 10.3.0.244
2018-02-22T00:15:39 8.8.8.8 93,388 159,57 213,53 38,97 0 131 10.3.0.244
2018-02-22T00:16:38 8.8.8.8 88,669 103,07 170,17 21,83 202 10.3.0.244
2018-02-22T00:17:39 8.8.8.8 89,404 100,43 153,77 18,09 0 160 10.3.0.244
2018-02-22T00:18:40 8.8.8.8 93,662 136,95 248,69 57,03 0 203 10.3.0.244
2018-02-22T00:19:40 8.8.8.8 87,641 111,52 194,21 34,65 0 183 10.3.0.244
2018-02-22T00:20:39 8.8.8.8 88,935 161,14 411,18 98,13 0 154 10.3.0.244

Alle Details einsehbar unter Netzwetter FF Wuppertal.

Könnte bitte mal jemand aus Wupper dazu Stellung nehmen? Ein Endverbraucher wird ein solches Surf Erlebnis als defekt empfinden. Das macht so in der Form einfach keinen Sinn das Ganze.

Klaus


#2

Schade das hier keiner antwortet. Ich würde eigentlich wirklich nur gerne wissen ob ich hier “private” Probleme habe oder ob etwas mit der Infrastruktur nicht stimmt.

Ich fänd es auch gut wenn andere User/innen der Wupper Domäne ihr “Bauchgefühl” zum FF in Wtal wiedergeben würden.

Der Datendurchsatz heute und die daraus resultierende Kurve können vielleicht noch mal verdeutlichen was ich meine.

Immer gegen 24H sucht sich mein per fastd Tunnel angebundener Router ein neues GW. Auf der Grafik ist das nicht zu erkennen, weil ich kam vom Wupper0 zum Wupper4. Diesmal hatte Wupper4 ein Problem, wget unter 100KB/s! Wupper0 lieferte die letzten 2-3 Tage immer so 500-600KB/s an, so auch gestern, da war ich den ganzen Tag mit dem verbunden.

Gegen 4 Uhr hatte ich noch mal nachgeschaut und die Misere gesehen. Habe ich den Router kurzhand neu gestartet und er verband sich mit Wupper6. Dort alles mehr oder weniger super, der Plastrouter kam erstmals über 2000KB/s, ok Nachts 4 Uhr, keine encryption, kein traffic shaping. Zeigt aber was FF können könnte…

Aus irgend einem mir unbekannten Grund wurde ich aber gegen 5:25 wieder mit Wupper0 verbunden. Der schafft grundsätzlich (so wie ich das beobachten kann) wie gesagt nur 500-600, aber die liefert er (zur Zeit) relativ konstant.

Somit habe ich mal auf einer Tages-Kurve alle drei Wupper Gates drauf. Und das sind Ergebnisse die m.E. nach total crazy sind: Von 60 - 2000 KB/s alles dabei.

Wie gesagt, ich erhebe mit meiner Messmethode keinerlei Anspruch auf die Gewinnung objektiver Daten. Ich habe das Programm bereits im Sommer 16 geschrieben, und sammle seitdem die Daten. Mein Plan war es das Surferlebnis einer normalen Userin abzubilden, die von Supernodes, B.A.T.M.A.N und fastd keinen Dunst hat. Und ich meine das tut das Tool ganz gut.

Aufgebaut ist das so dass ein Linux Rechner per Kabel mit einem FF Router verbunden ist und jede Minute einen Ping und einen wget absetzt. Die so gewonnenen Daten werden dann grafisch aufbereitet und in den Webspace geschoben. Da das Linux per Kabel angebunden ist werden lokale WLAN Störungen eliminiert. Der Linux Rechner sieht das Netz so, wie es ihm der Plasterouter anbietet.

Ich habe nur eine vage Idee was da hinter den Kulissen abläuft, aber im ERGEBIS ist DAS für den Freifunk kontraproduktiv. Irgend etwas geht da fundamental schief.


Dunkelgrün = wget (avg)
Hellgrün = Einzelwerte wget
Brau = ping (avg)
Gelb = Einzelwerte ping

Details (mit Einzelwerten) abrufbar unter Netzwetter FF Wuppertal , dort die Datei für den 25.2.10 abrufen.


#3

Hallo kdeiss, ein Link zu deinem Router wäre sicher noch gut. Ich weiss leider nicht wie aktiv die Wuppertaler das Forum nutzen. Bitte probieren doch mal die anderen Kontaktmöglichkeiten die auf der Homepage stehen.


#4

Ja das ist seit 10 Tagen der hier:

https://map.eulenfunk.de/stats/dashboard/db/node-byid?var-nodeid=e4956e43148f&orgId=1

Ich teste diese GL-150 Teile gerade intensiv durch, sie sind vorgesehen für den Einsatz in einem Wohnheim (da wo sie auf der Karte schon eingetragen sind),

Normalerweise steht dort aber der hier (TP-Link TL-MR3420 v2), Ergebnisse sind aber gleich. Nur der GL ist jetzt schneller, da encryption und traffic shaping aus.

https://map.eulenfunk.de/stats/dashboard/db/node-byid?var-nodeid=6466b36e936c&orgId=1


#5

Auch auf die Gefahr hin das ich hier anfange Selbstgespräche zu führen…

Ist das eigentlich das gewünschte Verhalten von batman?

root@XXX-YY-01:~# batctl gwl
Gateway (#/255) Nexthop [outgoingIF]: advertised uplink bandwidth … [B.A.T.M.A.N. adv 2016.2, MainIF/MAC: ibss0/de:6f:b2:cb:77:ba (bat0)]
04:be:e1:ba:fe:40 ( 4) 04:be:e1:ba:fe:00 [ mesh-vpn]: 92.0/92.0 MBit
04:be:e1:ba:fe:60 ( 5) 04:be:e1:ba:fe:00 [ mesh-vpn]: 92.0/92.0 MBit
 04:be:e1:ba:fe:00 ( 45) 04:be:e1:ba:fe:00 [ mesh-vpn]: 48.0/48.0 MBit

0 und 4 sind beide ziemlich unter Dampf, 0 anounced auch niedrige Bandbreite. 4 interessanterweise nicht (obwohl auch 142 Nodes connected sind). Der einzige der Resourcen frei hätte (Wupper6) dümpelt mit unter 20 nodes vor sich hin. Aber der lokale Node verbindet sich partout immer mit 0.

Wieviele Nodes sind eurer Ansicht nach eigentlich per Gateway noch gesund?


#6

Tja, das schaut nach “Feintuning” aus.
Es wird das Gateway mit der Höchsten TQ (der Wert in Klammern, maximal 255) ausgewählt.
Eine TQ von 45 ist aber (nach 15+ Minuten Laufzeit) eher Off- als Online.
D.h. mehr als 70% Packetloss vom Knoten zum Supernode.


#7

Wird hier eigentliche ein dynamisches Annouce Verwendet oder immer eine feste Bandbreite announced?

Batman ist Irgendwie ein bisschen Vodoo, du kannst 2 GW haben die das gleiche Announcen aber eins wird trotzdem bevorzugt.


#8

Sorry kann sein das ich da Mist gepostet habe, weil ich hatte den fastd Tunnel kurz zuvor neu gestartet bevor ich den batctl gwl abgesetzt hatte. Deswegen zeigte der Befehl bestimmt verfälschte Werte an.

@adorfer Entgegen deiner Empfehlungen habe ich mir doch ein virtuelles Gluon gebaut (ff-wupcrb-01). Dem habe ich aber verboten sich mit dem Wupper0 zu verbinden (via uci set fastd.mesh_vpn_backbone_peer_wupper0.enabled=0)

Dem scheint er auch zu folgen und zeigt mir die Welt so an:

root@ff-wupcrb-01:~# batctl gwl
Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2016.2, MainIF/MAC:  primary0/76:75:56:47:25:23 (bat0)]
=> 04:be:e1:ba:fe:60 (255) 00:be:e1:ba:fe:60 [  mesh-vpn]: 92.0/92.0 MBit
04:be:e1:ba:fe:00 ( 35) 00:be:e1:ba:fe:60 [  mesh-vpn]: 48.0/48.0 MBit
04:be:e1:ba:fe:40 ( 23) 00:be:e1:ba:fe:60 [  mesh-vpn]: 92.0/92.0 MBit

Das ist der Plasterouter, er sieht die Sache total anders:

root@WHAUS-ZG-01:~# batctl gwl
Gateway      (#/255)           Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2016.2, MainIF/MAC: mesh-vpn/de:6f:b2:cb:77:b8 (bat0)]
04:be:e1:ba:fe:60 ( 35) 04:be:e1:ba:fe:00 [  mesh-vpn]: 92.0/92.0 MBit
04:be:e1:ba:fe:40 ( 23) 04:be:e1:ba:fe:00 [  mesh-vpn]: 92.0/92.0 MBit
=> 04:be:e1:ba:fe:00 (255) 04:be:e1:ba:fe:00 [  mesh-vpn]: 48.0/48.0 MBit

Beide hängen mit ihren jeweiligen WAN IF via Lankabel direkt an einem Switch der zu meiner DMZ gehört. Ping usw zum def gw scheint alles gut zu sein.

Vodoo (@MisterCrumble :grinning:) oder Feintuning?


#9

hi

sieht für mich alles richtig aus.

  1. Fall:
    Es besteht anscheinend nur eine fastd Verbindung zu :60 da dies immer der Nexthop ist. Somit hat :60 natürlich auch 255 weil kein Paketloss auf dem VPN. Zu den anderen Gateways hast du keine direkt Verbindung (krausam sowas zu machen aber macht wohl mittlerweile fast jede Community so als Notlösung) somit mehr hops (batctl tr MAC würde zeigen wieviele es sind) und daher geringeren TQ.

  2. Fall:
    Kann man genau das gleiche beschreiben, nur das dort eben die direkte Verbindung zu :00 besteht (siehe NextHop) und deshalb auch dort die 255er Metrik ist, die anderen GWs haben mehr hops (batctl tr MAC und so…).

Interessant wäre, welche Batman Gatewayselection eingestellt ist, da gibts nämlich verschiedene Modi:
batctl - html man page (v2018.0-6-gb560610) unter gw_mode

Warum es langsam ist, kann man anhand dieser Daten nicht sagen, ich schau mal in meien Voodoozauberkugel und behaupte mal wieder zu große Layer 2 Domain aber was weiß ich schon mit meinen 1-10 Router pro L2 Netz wo ich ordentlich per Layer 3 wegtunnel (und auch Layer 3 Richtfunk habe) und somit problemlos 50Mbit voll mache (mehr würde auch noch gegen wenn die Telekom endlich 100/40 schalten würde…)

mfg

Christiajn


#10

Danke für Deine Hinweise. Ab wann ist denn erfahrungsgemäß eine Level2 Domain zu groß? Also was ist die kritische Masse?

Der GW Mode ist so eingestellt.

root@WHAUS-ZG-01:~# batctl gw_mode
client (selection class: 20)

#11

Hallo,

das ist schwer zu Sagen, immer wenn zu viel Hintergrundtraffic da ist.

100 Router bei 2 Gateways sollte keine Problem sein ab 200 sollte man mal überlegen ob man trennt.


#12

Wupper hat im Moment so ca. 350 Nodes connected (verteilt auf 3 Gateways, eigentlich zwei Gateways, weil einer hat nur so um die 20 Nodes).Wäre also weit drüber was Du als verträgliche Werte angibst.

Zum Verständnis, der Overhead wird also dann so groß das der Betrieb der gesamten Domäne gestört ist?


#13

Je mehr Router umso mehr Overhead Traffic, dann kann so ein Router schon mal 8 GB Traffic/Tag im Leerlauf machen


#14

Auf die Gefahr, dass in einer “Diagnose auf Distanz” immer Konfliktpotenital liegt:

Der Status in Wupper ist (aus meiner Perspektive) seit vielen Monaten unverändert:

  • Die Wupper-Hauptdomain hat tendenziell zu viele Supernodes (zu viel RA-Traffic, potentiell viele Routen)
  • Fastd-Supernodes, die selbst kein Exit sind, sondern per Fastd zu anderen Supernodes (mit Exit) tunneln: Nicht unbedingt gut für den RTD.
  • TAL-DE-Projekt in einem (für Externe) undokumentierten Status
  • Mitversorung von ein paar zusätzlichen Communities, zu denen aber seit Jahren kaum oder gar kein Kontakt mehr besteht. (siehe Wupper – Freifunk Rheinland e.V. )
  • ein Teil der Supernode-VMs auf FFRL-Instanzen, zum Teil noch auf ESXI bei OVH
  • eine Konfiguration, die hochgradig “speziell” ist und eine Restrukturierung der Infrastruktur nicht erleichtert (Supernode-VMs bedienen viele Batman-Domains gleichzeigt mit fastd-Tunneln auf verschiedenen Ports)
  • Seit mehr als 1,5 Jahren baut niemand mehr neue (offizielle) neue Firmware.
  • seit vielen Monaten niemanden, der als Ansprechpartner für die Freifunk-Weiterentwicklung/Planung fungiert (“Geht nicht? Wir machen dann mal nachher einen Reboot von den Servern?”-Betriebsmodus)

Falls es nicht gelingt, jemanden (besser: mehrere) zu finden, die sich in die bisherige Struktur einzuarbeiten bereit sind: Dann wird die einzig sinnvolle Lösung sein:

  • etwas neues bauen (nach einem Konzept das mehrere aktive Leute warten können)
  • aktive betreute Knoten in diese neuen Domains umziehen.

#15

@adorfer
danke für das Feedback, dann braucht man sich hier also keine Gedanken mehr machen (ich war gerade dabei was zu schreiben und hab noch überlegt wie) und kann das unter “sterbendes System” abhaken.

Nachdem das jetzt innerhalb recht kurzer Zeit die 2. “Community” ist die praktisch tot ist (von der letzten fällt mir gerade der Name nicht ein, wird wohl aktuell versucht zu retten und hatte irgendwas um die 700 Knoten), frag ich mich ernsthaft, gibt es da noch mehrere? Langsam bekommt man als Aussenstehender bzw. Mitglied einer recht gut laufenden Community das Gefühl das bei Freifunk einiges mehr im argen liegt als ich bisher dachte.

mfg

Christian


#16

@adorfer Danke für die offenen Worte.


#17

Mein Wunsch würe, dass die Wupper-Domain wieder zu alter Blüte zurückfindet (Das “L2-Domains klein halten”-Konzept wurde dort schon 2014 betrieben, als andere noch meilenweit von der Erkenntnis entfernt waren).

Aber so wie andere ihre Infrastruktur in den vergangenen Jahren umgebaut haben, weil sie langfristig Dinge gelernt haben, so wäre soetwas in Wupper meines Erachtens auch notwendig.
Also nicht nur Feintuning, sondern vielleicht auch mal “kompletter Neubau”.

Da ich aber lediglich “historisch” mit Wupper verbunden bin (ffdus ist als Teildomain dort mal 2015 gestartet und wir bald herausgesplittet sind): Ich kann es nur von außen betrachten.
Es gibt durchaus Ansätze, sinnvolle Dinge zu tun dort. Nur meiner Beobachtung fehlt eine Gruppe von Leuten, die sich da “den Hut aufsetzt” und das Projekt als das ihrige vorantreibt.

Aber ich lasse mich natürlich auch gern eines Besseren belehren. Denn weder bekomme ich alles mit, noch besteht überhaupt eine Pflicht, dass eine Community auf ihrer Webseite oder im Forum über die aktuellen Vorgänge oder Pläne informiert.


#18

Wir sind aktuell dabei “alles neu zu bauen” aber wie du schon sagst fehlen etwas die Leute um es mal eben zu machen.


#19

Kannst Du das etwas näher beschreiben? Gilt dies dann auch für die Wupper-Domänen außerhalb Wuppertal und deren Firmware?


#20

Nach meinem Kenntnisstand soll für diese nichts getan werden und diese sind aufgefordert, ihre Geschicke selbst in die Hand zu nehmen. (Also so oder ähnlich herauszusplitten wie andere wie ihr und wir) auch getan haben in den vergangenen Jahren)

Konkret geht es nach:
https://wiki.freifunk-rheinland.net/wiki/Wupper#Funkzellen_in_der_Dom.C3.A4ne
um

  • Abschaltung “Restdomain Gelsenkirchen” (noch 2 Router mit deaktiviertem oder defekten Autoupdater)
  • Radevormwald (rund 80 Knoten aktiv derzeit)
  • WupperGL-BergischerKreis (rund 40 Knoten derzeit)

Ob man den Betrieb von vermutlich seit 2 Jahren ungepatchten Supernodes auf VMs des FFRLs überhaupt “aus sicherheitstechnischen Aspekten” noch verantworten könne: Das war bereits in den vergangenen Monaten häufiger in dem einen oder anderen Gespräch Thema.

Aber mangels exakter Kenntnis des Status der Maschinen und fehlender Handlungsoptionen gab es als Fazit eigentlich immer nur Betroffenheit. Klingt jetzt ziemlich blöd, aber was ich damit sagen will: Es machen sich durchaus Leute Gedanken darüber, was mit “an Communities ausgeliehenen VMs” passiert im Namen des Vereins.
Eventuell ist aber auch da alles in bester Ordnung und es fehlt lediglich ein etablierter Rückkanal. (oder überhaupt Kommunikationsstrukturen)