Mich hatte es schon lange interessiert was mit den FF-Routern hier in WTAL wirklich über den Tisch geht. Subjektiv gesehen ist es halt oft sehr langsam.
Ich progge da nun schon eine ganze Weile dran rum und bin nun mit der Darstellung (nicht aber natürlich mit den Ergbnissen!) zufrieden und stelle es der interessierten Öffentlichkeit hiermit zur Verfügung.
Ihr findet die aufbereiteten Ergebnisse hier als Webseite:
Zwar haben die Daten vom 3/4 Löcher aber man kann keine so starken Einbrüche sehen wie es jetzt grade wieder der Fall ist (20:00) - was war denn da anders?
Ich habe mal noch ein paar Fragen.
Wie ist das Verhältnis von Blech zu VM-Supernodes?
Wirft jeder Wupper-VM-Supernode den Verkehr ab oder wird alles über ein gemeinsames Interface geleitet?
Wie kann ich von extern den grade connecteten Supernode ermitteln?
Der Test ist immer nur für ein zufälliges Gateway. Deinen Freifunkrouter (oder besser VM) solltest du zu wupper0-9 verbinden lassen und den Test gleichzeitig über die Gateways 10.3.0.240-249 fahren (Nicht immer alle online). Deine IPv4 kannst du dir per DHCP holen und kann für jedes Gateway gleich sein.
Danke für die Infos. Das wäre natürlich möglich aber macht das Sinn? Wenn die VM’s auf einem Blech laufen müsste es doch genügen eine zu testen (gesetzt die Supernodes sind gleichmässig mit clients bestückt).
Mir scheint es ja so zu sein das den Teilen die Luft aus CPU Gründen ausgeht selbst wenn sie noch ethernetbandbreite hätten. Das müsste sich in einem gut konfigurierten System auf alle VM’s auswirken (also alle machen gleichzeitig und gleichermassen „schlapp“). Ich will mal gucken das ich das gerade benutzte gateway noch rausfilter.
Kannst du das Script anpassen damit man ein Interface angeben kann? Würde das dann auf meinen Server laufen lassen, dieser ist mit allen Wupper verbunden.
Ja das Script kann das. Ich hatte es ursprünglich dafür geschrieben das er mir in meinem Netzwerk die Route ins FF Netz legt sobald diese verfügbar ist, weil sie fiel einfach so oft aus und das hat mich genervt. Also ich kann die Route sozusagen bei Bedarf setzen oder aufheben.
Wenn man jetzt alle Supernodes überwachen wollte müsste man wie folgt vorgehen. Die Routen für den/die Referenzhost werden in einer grossen for schleife gesetzt, der Test wird gefahren, dann wird die Route erneut gesetzt. (Vorausgesetzt natürlich das der Rechner auf dem das läuft mit einem Interface direkt mit dem FF verbunden ist).
Aber: wget holt jede Minute 5MB, das macht 300MB die Stunde, 7,2GB pro Tag. Mal 10 erzeugt dann ein Test so einen Traffic von 72GB pro Tag - wenn ich mich nicht verrechnet habe. Ist das nicht ein bisserl heftig? Sie sollte eine gewisse Grösse haben, je grösser desto genauer das Ergebnis. Und es gäbe natürlich auch Probleme beim zeitlichen Ablauf, innerhalb einer Minute dürfte schwierig werden.
Deshalb ja auch meine Frage nach dem Blech, also den physischen Maschinen die dahinter stecken. Da würde es m.E. nach durchaus Sinn machen eine VM zu testen, die jeweils auf einem Blech ausgeführt wird.
Interessant fänd ich persönlich es auch das ganze in einer Domäne mit L2TP laufen zu lassen um zu schauen ob die sich diese smarter verhält. Letztendlich ist der Vorteil dieser Methode das man das Netz quasi aus Kundensicht testet. Ich meine man sieh bei der Domäne Wupper deutlich wo und vor allem wann es wirklich klemmt.
Soll ich Dir mal das Script für den Datensammler schicken?
Gibt es noch eine clevere Methode files zu uppen? Er erlaubt scripte nicht. Wie gesagt ist nicht grade die Krönung an Programmierleistung, funktioniert aber für unsere Zwecke ganz gut.
gesteuert wird das script via
let WORKMODE=1 # 0=routing manager / 1=only statistic
let DOTRACERT=1 # disabled with 0
let RWGET=1 # disabled with 0
HOSTLISTE=„85.17.1.8 190.1.2.2 8.8.8.8“ # da kannst du auch mehrere Hosts anpingen
Würde ich erst mal alles auf 0 stellen und mich dann pö a pö an das script rantasten. Das muss mit Sicherheit an fremde Umgebung angepasst werden. Läuft out of box auf aktuellem Debian, Mint17 und auf dem PI
Braucht an externen Tools bash,bc, ping, wget, traceroute
WUPPER6
2 40 ms 38 ms 38 ms 10.3.0.246
4 65 ms 62 ms 76 ms strato.nikhef.nl-ix.net [193.239.116.37]
Broadband Hosting B.V. trading as NL-ix
Ich habe ,ir die routen jetzt mal manuell zurechtgebogen und es passiert etwas was ich garnicht mehr blicke.
Trage ich mir den Wupper2 als Supernode / def. GW ein kommt beim traceroute folgendes raus:
Tracing route to ipv6-test.com [5.135.165.173]
over a maximum of 30 hops:
1 43 ms 30 ms 34 ms 10.3.0.242
2 74 ms 64 ms 61 ms 100.64.4.228
3 90 ms 90 ms 85 ms strato.nikhef.nl-ix.net [193.239.116.37]
4 * * * Request timed out.
5 78 ms 88 ms 76 ms be10-1184.rbx-g1-a9.fr.eu [94.23.122.76]
6 * * * Request timed out.
7 88 ms 88 ms 78 ms agaric.t0x.net [5.135.165.173]
Frage ich jetzt aber meine IP via Webinterface ab zeigts mir an:
Dem liegt wohl ein Denkfehler meinerseits zu Grunde. Ich hatte erwartet das der erste Host auf der Route mit öffentlicher IP (also der eigentliche Übergabepunkt des FF Traffics) identisch ist mit der IP mit der ich mich durchs Netz bewege. Aber in Wirklichkeit ist es wohl die öffentliche IP vom 100.64.4.228.
Ist das der BGP Konzentrator (=> Eulenfunk Doku)? Ich hatte nicht erwartet das der mit „echten“ IP4 Adressen arbeitet…
WOW! Ich hatte heute Nacht einen „IP-Wechsel“ im FF-netz. Er hat mich auf WUPPER2 umgeswitcht.
War ich schon betrübt über die Leistung vom WUPPER4 so muss ich nun feststellen das der WUPPER2 erst mal eine tiefe Delle in den WGET Transfer geschlagen hat.
Lag der Durchsatz auf WUPPER4 immer so um die 480KB/s so ist der Schnitt jetzt abgesunken auf unter 300KB/s - und das ausserhalb der Primetime!
Möglicherweise liegt dem Geschwindigkeiteinbruch ein generelleres Problem zu Grunde:
Habe auf jeden Fall eine neue Version gemacht und klippe jetzt immer auch den eth0 Durchsatz des aktiven Supernodes, sowie die Generalstatistik der Domain Wuppertal mit ein. Da hat man dann alles auf einem Blick!
Du wirst von der Position des Nodes aus kaum sinnvoll den Backbone ausmessen können.
Allenfalls ein „alles ist super“ wird möglich sein, wenn es denn so ist.
Aber wenn es es hakt, dann wirst Du nicht herausbekommen, woran es liegt.
Dafür sitzt Du schlicht an der falschen Stelle mit Deinem Probe.
Ich würde vorschlagen, dass Du Dich bei den Messungen auf das beschränkst, was Du von dort sinnvoll beurteilen kannst.
Das ist nach meiner Einschätzung:
-Packetloss und Durchsatz zu den public-IPv4 und public-IPv6 der fastd-server
-Aufbau (OK/NOK) der fastd-tunnel via IPv4 und IPv6 der fastd-server
-batman Anbindung der gateway (TQ vom lokalen batman zu IPv4-Gateway)
-Packetloss zu den allen ipv4-gateways von allen fastd-servern aus (2-dimensionale Tabelle, um Quertraffic zu erfassen)
-DHCP-Performance (request UND renewal)
Was der Probe dafür tun müsst? eine site.conf als Parameterfile bekommen und sich dann selbstständig durchfräsen durch die Optionen/Möglichkeiten, die sich daraus ergeben.
Alles andere wird in Kaffeesatzleserei und gereizten gegenseitigen Vorhaltungen enden.
