MTU of 1280B for clients w/o fragmentation #14

skorpy2009 · 2016-10-16T23:04:14Z

https://twitter.com/ffhhnoc/status/787771192853798915
Dank hexa- und ffhh müssten wir endlich wieder schön funken können...

oszilloskop · 2016-10-16T23:07:33Z

Das bedeutet, raus mit der Auto-MTU?
Das bedeutet MTU auf 1280B setzen?

skorpy2009 · 2016-10-16T23:18:15Z

Ziel ist: Raus mit Auto-MTU und nur noch ein Tunnel mit 1312B für die Knoten ( in der Übergangszeit auf den Supernodes alle 3 (4 für BB)

christf · 2016-10-17T05:15:11Z

Warum ist das das Ziel und wo ist der Vorteil gegenüber der aktuellen Lösung, die auch größere MTU erlaubt?

oszilloskop · 2016-10-17T06:33:06Z

Wie wird die MTU für die Clients vorgegeben? Über "dhcp-option-force"?
Die können wir jetzt schon auf 1280 Byte setzen und irgendwie per Wireshark mal bei aktuellen Verbindungen mit grosser MTU eine Vorher-/Nachheranalyse fahren und nachsehen, was das ganze so bringt. Ist zwar nicht 100% identisch, aber besser als nix.

skorpy2009 · 2016-10-17T07:24:56Z

Aktuell kann es passieren das Batman Pakete fragmentiert => weniger Durchsatz.
Laut https://tools.ietf.org/html/rfc2460#section-5 ist die Minimum MTU 1280 für IPv6 Pakete.
Aktuell wird somit manchmal fragmentiert, da wir 1280er MTU auf dem Tunnel haben, da aber noch batman-adv und l2 header hinzukommt. Siehe geniale Grafik von ~~Hamburg~~ Frankfurt.

Neu:

Alt:

Damit wir die MTU von 1280B für Clients auf br-client Seite hinbekommen, müssen wir die Tunnel größer machen => von 1280B auf ~~1312B~~ 1298B (den B und L2 Header addieren).

skorpy2009 · 2016-10-17T09:01:29Z

@oszilloskop was meinst du damit?

oszilloskop · 2016-10-17T11:55:48Z

Na irgendwie müssen die Clients doch bescheid bekommen, dass sie eine MTU von nur 1280 Byte verwenden sollen. Das geht unteranderem per DHCP.
Wenn die eine andere MTu verwenden, wäre das ganze hier hinfällig.

skorpy2009 · 2016-10-17T14:00:14Z

@oszilloskop schau dir bitte den freifunk-ffm/supernode_puppet#19 mal an

christf · 2016-10-19T06:51:53Z

@oszilloskop @skorpy2009 @t-8ch
ist denn schon Einigkeit über die Ziele hergestellt? Das hieße:

Änderung der mtu der fastd-tunnel auf 1312
Entfernung des MTU-Auto-Selektors aus der Firmware

oder behalten wir den mtu-selektor und heben nur die kleinere MTU von 1280 auf 1312 an? Auch das wäre ja eine Alternative....

christf · 2016-11-03T21:19:19Z

und?

oszilloskop · 2016-11-21T21:08:52Z

Nach neuesten Erkenntnissen benötigt der fastd-Tunnel nur eine fastd-MTU von 1298 Byte (anstelle von 1312 Byte)
(Siehe angepasste Grafik oben)

christf · 2016-11-21T21:40:25Z

:-)

nochmal zu den Zielen. @oszilloskop möchtest Du das auto-mtu-paket aufgeben?

in einem batman-Netz ist das auto-mtu-paket leider nutzlos, weil batman auf 1280 Byte MTU gepatcht wird. In einem Babel-Netz gibt es diesen Patch nicht.
Zwischen der minimalen fastd-MTU von 1280 und der maximalen fastd-MTU von 1406 liegen 126 Byte, was einem 10% Zuwachs der Datenmenge je Paket entspricht.

Was meint ihr: Wie viel mehr Durchsatz / Entlastung des Netzes bringt diese Struktur?

oszilloskop · 2016-11-22T22:00:11Z

@christf
Für die langfristige Vereinfachung der Supernode-Konfiguration würde die Aufgabe des auto-mtu Package helfen.

Spätestens beim Wechsel auf "Babel" müssen wir dann erstmal nur noch die best mögliche universelle MTU-Size (für Unitymedia und Telekom) unterstützen. Das erspart uns eine Menge Wirrwarr

Nach der Umstellung auf Babel können wir dann testen und weitersehen.
Das Package kann ja ggf. wieder reaktiviert werden.

christf · 2016-11-26T16:31:41Z

serverseitig tun mehrere fastd-instanzen nicht weh. Vorteil könnte sein, dass am node die fastd-Verbindungen etwas schneller aufgebaut werden.
Ein Vorteil von mehreren fastd-instanzen auf dem Server ist, dass mehrere CPUs von fastd genutzt werden können.

oszilloskop · 2016-11-26T23:34:59Z

Ein Vorteil von mehreren fastd-instanzen auf dem Server ist, dass mehrere CPUs von fastd genutzt werden können.

Haben wir den überhaupt einen so direkten Zugriff auf die VMs und die Anzahl deren vCPUs und kennen wir die Anzahl der realverfügbaren Kerne der Spender-Maschinen?
Die Spielwiese ist z.B. mit vCPUs schon überbucht.

christf · 2016-12-21T18:04:24Z

Wir wissen schon wie viele vcpus verbaut sind. Das reicht tatsächlich schon. Ob wir einen Einfluss darauf haben steht auf einem anderen Blatt.

CPUs sind immer overcommitted in modernen Betriebssystemen weil gleichzeitig dutzende Prozesse laufen aber nur wenige kerne vorhanden sind. Scheduler lösen das ganz gut, solange die kontextwechsel im Griff sind.

oszilloskop · 2016-12-21T18:20:58Z

Ich habe den Überblick verloren.
Packt hier bitte mal rein, welche und wieviele MTUs jetzt von den Supernodes unterstützt werden.
Dann sollten wir uns mal gemeinsam bei einem regelmäßige oder Basteltreffen abstimmen, was wir dann wo und wann in die Firmware packen.

oszilloskop · 2017-01-29T14:30:18Z

Gibt es etwas neues? Ansonsten werden die bisherigen Werte für die neue Stable-Firmware verwendet.

oszilloskop · 2017-02-12T15:54:33Z

Vorbereitungen für zwei fastd-MTU-Größen laufen:
Tests mit einem Router von @MyIgel haben gezeigt, dass Unitymedia eine maximale PMTU von 1460 Byte unterstützt.
Daher könnten folgende zwei fastd-MTU genutzt werden:

Kleine MTU = 1312 Byte als Fallback (Hier gehen sichergestellt 1280 Byte Client-Payload durch. Alle Up-Links sollten eigentlich diese MTU unterstützen können.)
Große MTU = 1374 Byte für Unitymedia und Telekom Up-Links

Die site.conf der einzelnen Branches werden angepasst, sobald auch die Supernodes diese MTUs unterstützen.
Mein Vorschlag:

1312 Byte über Port 10003
1374 Byte über Port 10004

oszilloskop · 2017-02-22T00:42:43Z

Also, es gestaltet sich jetzt wie folgt:
Auf den Frankfurter Supernodes gibt es folgende fastd-Tunnel:

Bisher:
Port 10001 -> MTU 1280 Byte (bald unbenutzt)
Port 10002 -> MTU 1426 Byte (bald unbenutzt)

Zusätzlich und Neu:
Port 10003 -> MTU 1374 Byte (sollte immer durch Unitymedia und Telekom nutzbar sein)
Port 10004 -> MTU 1312 Byte (Fallback)

In der Site.conf findet sich jetzt folgendes:

  ...
  fastd_mesh_vpn = {
    mtu = 1312,
  ...
  fastd1 = {
            key = '6d98ed09fc260a65234a65b03ce47c9e1a19226c66220c66b89255bf569fa68b',
            remotes = {'ipv4 "fastd1.ffm.freifunk.net" port 10003' , 'ipv4 "fastd1.ffm.freifunk.net" port 10004'},
          },
  ...
  fastd_auto_mtu = {
    mtu_fastd_low = 1312,
    mtu_fastd_high = 1374,
    mtu_uplink_max = 1460,
    ping_target = '8.8.8.8',
    delay_time = 10,
    wan_if = 'br-wan',
  },
  ...

Damit unterstützt die Frankfurter Stable-Firmware v2.1-stable-0220 z.z. folgende fastd-MTUs:

1312 Byte
1374 Byte

Auto-MTU wird weiterhin auf den Routern angewendet.

skorpy2009 · 2017-06-03T18:43:16Z

So, wie lange supporten wir noch 1280B MTU?

skorpy2009 · 2017-09-15T21:00:20Z

1374 ist jetzt die einzige MTU in der neuen Stable.

oszilloskop · 2017-09-15T21:07:17Z

Wenn es keine 'alte' Firmware mehr im freien Feld gibt (FW kleiner v2.2), dann könnten wir die Unterstützung der MTUs ungleich 1374 abschalten.

skorpy2009 · 2017-09-15T21:11:55Z

Wir haben noch folgende Knoten, die ich alle schon angeschrieben habe:
v2.1-stable-0220 | 1

v2.0-stable-34 | 2

ffmstable-1.10 | 3

Ich würde zwar nicht die alten Fastd Tunnel abschalten. Ich werde aber auch bei den neuen Gateways keine alten Tunnel mehr anlegen.

oszilloskop · 2017-09-16T00:58:10Z

Ich sehe das z.Z. zwar gerade etwas anders, aber es kommt auf das Gleiche hinaus -> "Es gibt noch Router mit älterer Firmware."

Es liegt wohl daran, dass nicht alle Router 24/7 online sind.

skorpy2009 · 2017-11-04T20:51:17Z

Wann kicken wir alte MTUs?
also grade die 1280er?
Denn sie können zu dem refragmentierung Problemen führen ( Batman fragmentiert immer nur einmal)

christf · 2017-12-30T23:44:22Z

eine MTU von 1374 wird von indestens einem Telekom hybird-anschluss nicht unterstützt. Wir haben da für das babel-netz länger analysieren müssen.

=> Der Schritt zurück auf 1312 ist sinnvoll. Das ist universeller einsetzbar.
Das babel Netz wird aktuell mit 1312 und 1374 gefahren, wobei 1374 in salt steht und 1312 manuell auf gw02 eingetragen ist. PR dazu ist gestellt.

skorpy2009 · 2017-12-31T09:05:50Z

Wer kann uns den mal so einen Telekom Hybrid Router geben?

ctr49 · 2017-12-31T14:10:34Z

@skorpy2009 der router alleine hilft Dir nichts, brauchst auch den passenden Anschluss dazu.
Hab hier einen solchen, wenn Du was testen willst kann ich Deinen ssh key auf den router packen

skorpy2009 · 2017-12-31T14:11:43Z

@ctr49 cool, danke, das meinte ich.

skorpy2009 assigned oszilloskop Oct 16, 2016

skorpy2009 added enhancement Infrastruktur Firmware Dev labels Oct 16, 2016

skorpy2009 added this to the dev milestone Oct 16, 2016

skorpy2009 assigned t-8ch Oct 16, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MTU of 1280B for clients w/o fragmentation #14

MTU of 1280B for clients w/o fragmentation #14

skorpy2009 commented Oct 16, 2016 •

edited by oszilloskop

Loading

oszilloskop commented Oct 16, 2016 •

edited

Loading

skorpy2009 commented Oct 16, 2016

christf commented Oct 17, 2016 •

edited

Loading

oszilloskop commented Oct 17, 2016

skorpy2009 commented Oct 17, 2016 •

edited by oszilloskop

Loading

skorpy2009 commented Oct 17, 2016

oszilloskop commented Oct 17, 2016 •

edited

Loading

skorpy2009 commented Oct 17, 2016

christf commented Oct 19, 2016

christf commented Nov 3, 2016

oszilloskop commented Nov 21, 2016

christf commented Nov 21, 2016

oszilloskop commented Nov 22, 2016

christf commented Nov 26, 2016

oszilloskop commented Nov 26, 2016 •

edited

Loading

christf commented Dec 21, 2016

oszilloskop commented Dec 21, 2016

oszilloskop commented Jan 29, 2017

oszilloskop commented Feb 12, 2017 •

edited

Loading

oszilloskop commented Feb 22, 2017 •

edited

Loading

skorpy2009 commented Jun 3, 2017

skorpy2009 commented Sep 15, 2017

oszilloskop commented Sep 15, 2017

skorpy2009 commented Sep 15, 2017

oszilloskop commented Sep 16, 2017 •

edited

Loading

skorpy2009 commented Nov 4, 2017

christf commented Dec 30, 2017 •

edited

Loading

skorpy2009 commented Dec 31, 2017

ctr49 commented Dec 31, 2017

skorpy2009 commented Dec 31, 2017

MTU of 1280B for clients w/o fragmentation #14

MTU of 1280B for clients w/o fragmentation #14

Comments

skorpy2009 commented Oct 16, 2016 • edited by oszilloskop Loading

oszilloskop commented Oct 16, 2016 • edited Loading

skorpy2009 commented Oct 16, 2016

christf commented Oct 17, 2016 • edited Loading

oszilloskop commented Oct 17, 2016

skorpy2009 commented Oct 17, 2016 • edited by oszilloskop Loading

skorpy2009 commented Oct 17, 2016

oszilloskop commented Oct 17, 2016 • edited Loading

skorpy2009 commented Oct 17, 2016

christf commented Oct 19, 2016

christf commented Nov 3, 2016

oszilloskop commented Nov 21, 2016

christf commented Nov 21, 2016

oszilloskop commented Nov 22, 2016

christf commented Nov 26, 2016

oszilloskop commented Nov 26, 2016 • edited Loading

christf commented Dec 21, 2016

oszilloskop commented Dec 21, 2016

oszilloskop commented Jan 29, 2017

oszilloskop commented Feb 12, 2017 • edited Loading

oszilloskop commented Feb 22, 2017 • edited Loading

skorpy2009 commented Jun 3, 2017

skorpy2009 commented Sep 15, 2017

oszilloskop commented Sep 15, 2017

skorpy2009 commented Sep 15, 2017

oszilloskop commented Sep 16, 2017 • edited Loading

skorpy2009 commented Nov 4, 2017

christf commented Dec 30, 2017 • edited Loading

skorpy2009 commented Dec 31, 2017

ctr49 commented Dec 31, 2017

skorpy2009 commented Dec 31, 2017

skorpy2009 commented Oct 16, 2016 •

edited by oszilloskop

Loading

oszilloskop commented Oct 16, 2016 •

edited

Loading

christf commented Oct 17, 2016 •

edited

Loading

skorpy2009 commented Oct 17, 2016 •

edited by oszilloskop

Loading

oszilloskop commented Oct 17, 2016 •

edited

Loading

oszilloskop commented Nov 26, 2016 •

edited

Loading

oszilloskop commented Feb 12, 2017 •

edited

Loading

oszilloskop commented Feb 22, 2017 •

edited

Loading

oszilloskop commented Sep 16, 2017 •

edited

Loading

christf commented Dec 30, 2017 •

edited

Loading