MTU Problem an Kabel Deutschland Dual-Stack

Hallo jetzt dachten wir das MTU Problem im Griff zuhaben.

Aaaber…

ping6 -s 1122 2a03:2260:100a:a:f6f2:6dff:fe22:67da geht noch durch
ping6 -s 1123 2a03:2260:100a:a:f6f2:6dff:fe22:67da geht nicht mehr durch

http://[2a03:2260:100a:a:f6f2:6dff:fe22:67da]/ geht demnach auch nicht

2a03:2260:100a:a:f6f2:6dff:fe22:67da ist ein FF-Knoten mit aktuellem Image aus dem gluon Master.
Uplink ist Kabeldeutschland mit Dualstack

Gepingt hatte ich von zuhaue, auch ein KD Anschluss und von einen hetzner Server.
Beide male das gleiche Ergebnis.

Ich bräuchte da mal Hilfe :slight_smile:

Mit Welcher MTU wurde der anschluss gesynct ?? wir haben hier Dualstack-Lite und haben eine MTU von 1460 Und hier läuft alles soweit …

Als test dient derzeit ein image vom Fichtenfunk MZ

Ohne site.conf wird das Rätselraten.
(Ich gehe mal davon aus, es geht um Fastd, oder?)

Freifunk Südpfalz?

Habe Titel mal auf >15 Zeichen geändert.

Die MTU bei KD ist zu gering und verletzt offenbar die IPv6 Anforderung minimaler MTU = 1280. Die MTU ist nur für TCP Verbindungen von Bedeutung. Die „MTU“ Probleme sind zum Teil selbst verursacht. Auf unsere Supernode wird die MSS für alle Interface entsprechend Interface MTU festgeklemmt. Damit sorgen wir für ein nicht funktionierenden pmtu discovery. Die zur Verfügung stehende pmtu ist von vieles anhängig IPv4/IPv6 Verbindung der Node zur GW, pmtu für einzelnen Interface,…
zur geringe mtu/mss sorgen für eine erhöhten Datenaufkommen, zu hohe ebenso, dazu kommt noch die Reassemblierung der TCP Pakete. die eine Belastung der CPU bedeutet, usw.

@BlackSheep : kann man die MTU mit der der Anschluß gesynct wurde bei der fritzbox auslesen?

@adorfer: fastd ja.

Das ist die site.conf des genannten FF-Routers https://github.com/freifunk-suedpfalz/site-ffsuedpfalz/blob/ffhassloch-experimental/site.conf

Scheinbar macht der Anschluß nur (gerade) Probleme, aufgefallen ist es mir nachdem ich den experimental Knoten zum Testen mit an das Gäste-Lan der Fritzbox gehängt hatte.
Es funktionierte vorher ja und das Einzige was sich geändert hat ist das zum Test zwei nun FF-Knoten dran hängen.
Der andere Knoten der vorher schon angeschlossen war läuft mit gluon v2015.1.2 und der site.conf https://github.com/freifunk-suedpfalz/site-ffsuedpfalz/blob/ffhassloch/site.conf

Aufgefallen war mir das die Knoten mit unterschiedlichen Supernodes verbunden waren (wie haben nur zwei).
Eine schlüßige Erklärung für die super kleine MTU unter 1280 kann ich mir daraus zwar auch nicht herleiten, aber ich habe den experimental Knoten einfach mal abgehängt und versucht den alten Knoten mit ping6 -s 1123 zu erreichen was trotzdem nicht ging. Nur kleinere Pakete gehen durch.

Ich würde zum Testen ja auch einfach mal die Fritzbox neustarten damit sie eine neue Verbindung aufbaut aber wenn es dann funktioniert sind wir auch nicht schlauer und haben keine Möglichkeit mehr das zu debuggen.

Also am Kabeldeutschland Anschluss kann es IMHO nicht liegen.

ping6 an google und heise gehen mit größeren Paketen.

Ich hab ein kleines Bashscript geschrieben für die automatische Ermittlung der maximalen Paketgrößen.

Die Ausgabe wird übersichtlicher wenn man verbose=0 setzt :wink:

./check_icmp_packetsize.sh heise.de
ermittlete Paketgröße: 1454

ermittlete Paketgröße: 1232



./check_icmp_packetsize.sh google.de
Paketgröße: 1500
ermittlete Paketgröße: 1232

System → Ereignisse →

Es sei noch dazu gesagt das Wir eine Fritz!Box 6490 Cable haben … bei anderen Routern von UMKBW/Kabel Deutschland kann das abweichen zB. bei einem Technicolor wird es nicht angezeigt welche MTU du bekommen hast … bei der neuen Surfbox habe ich noch keine Gelegenheit gehabt

Ok da hatte ich natürlich schon nachgesehen, steht bei meiner FB aber keine MTU dabei.

30.01.16  01:21:51  IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: xxx:xxx:xxx:xxx::/62
30.01.16  01:21:51  Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: xxx:xxx::xxx:xxx:xxx:xxx:xxx
30.01.16  01:21:51  Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xx.xx.xx.xx, DNS-Server: xx.xx.xx.xx und xx.xx.xx.xx, Gateway: xx.xx.xx.xx

Ist hier auch eine 6490 mit FRITZ!OS 06.31aber halt kein DSLite

Unter Windows mal mit „ping -f -l 1465 www.t-online.de“ probieren

Wenn kommt „Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.“

immer mehr mit der MTU Runter gehen solange bis du wieder Pakete zurück bekommst

Sprich „ping -f -l 1406 www.t-online.de“ oder „ping -f -l 1305 www.t-online.de

Wenn ich es also richtig verstanden habe, dann sind die fastd-server nicht per IPv6 erreichbar, die Gluon-Knoten gehen also in diesem Fall zwangsweise über DSlite (den GCN Tunnel).
Die Benchmarkerei an IPv6 kann man sich hier also sparen, da nicht relevant.

Ich würde dann sagen: 1406er-MTU für die Fastd-peers ist schicht zu groß. Versucht es mit 1364 oder macht die Supernodes per IPv6 erreichbar. (letzteres hilft aber nicht Leuten, die ihre Freifunk-Router aus Sicherheitsgründen (z.b. Arztpraxen) in einer Routerkaskade hängen haben hinter einem TC7200, welche leider keine IPv6-Prefixe deligieren kann. Da gibt es dann nur IPv4.)

Die Supernodes sind per IPv6 erreichbar.

0.queich.net has address 78.46.193.78
0.queich.net has IPv6 address 2a01:4f8:c17:29e::2
1.queich.net has address 78.46.191.160
1.queich.net has IPv6 address 2a01:4f8:c17:207::2

udp6       0      0 :::10000                :::*                                0          13401       1338/fastd
socat - UNIX-CONNECT:/var/tmp/fastd.ffld.sock

zeigt sowohl IPv4 also auch ipV6 Peers an.

Die fastd MTU hatte roman von ffka auf 1406 ausgerechnet damit der fastd Tunnel sowohl über IPv4 und IPv6 passt.
Erklärst du mir den Vorschlag von 1364 bitte.

Die MTU der GRE Tunnel zum FFRL Backbone ist auf 1400 gesetzt.
Und wir haben TCPMSS clamp to PMTU mit iptables gesetzt.

Das Problem scheint auch nur meinen Anschluss zu Betreffen.
Andere Knoten in unserer Domäne die ich sporadisch testet hatten das Problem nicht.

Die fastd MTU hatte roman von ffka auf 1406 ausgerechnet damit der fastd Tunnel sowohl über IPv4 und IPv6 passt.
Erklärst du mir den Vorschlag von 1364 bitte.

Meistens haben die Kabelanbieter wesentlich kleinere MTUs als 1406, 1364 ist der Wert womit wir am wenigsten Probleme hatten.

Okay wie habt ihr das ermittelt?
Ich würde es gerne nachvollziehen können.

Via Path-MTU discovery zum Supernode :slight_smile:

empirisch.

(ich überlege, zu welchem der vielen MTU-Size-Limbo-Threads das hier gejoined werden könnte. Neue Erkenntniss, abgesehen von „Alles fsck da draussen“ ist nicht mehr zu erwarten. Dass der Code für AutoMTU im fastd ja mal vorgesehen war, wegen dauer-broken aber removed wurde. Ärgerlich… wäre schön, wenn sich da mal jemand drum kümmern würde. Aber dafür bräuchte es halt mehr fähige Programmier. Die Liste der wünschenswerten Dinge ist lang.)

1 Like

Auf MTU test - LetMeCheck.it kann man die MTU auch ermitteln.
Der Test mit der IP 2a03:2260:100a:a:f6f2:6dff:fe22:67da kommt aufs gleiche Ergebnis.
1122 bytes maximaler Payload

Wie finde ich heraus welcher Hop die Größe so runterzieht?

EDIT: da war ja was… tracepath

tracepath6 2a03:2260:100a:a:f6f2:6dff:fe22:67da
...
9:  freifunk-rheinland.speedboneber1.nlsix.net           23.711ms asymm  6
10:  freifunk-rheinland.speedboneber1.nlsix.net           23.750ms pmtu 1400
10:  2a01:4f8:c17:29e::2                                  17.409ms asymm  9
11:  2a01:4f8:c17:29e::2                                  17.507ms pmtu 1328
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1328
     Resume: pmtu 1328

nach 2a01:4f8:c17:29e::2 kommt normal der FF-Knoten
traceroute6 läuft ja durch mit den kleinen Paketen.

Achtung, wir geben per radvd eine mtu von 1328 bekannt. Dieser Wert wird selbst verständlicherweise für IPv6 Adressen verwendet (es sei den die Gegenstelle hätte ein geringere Wert)…

Aber warum ist die MTU hier nur 1170?
Woher kommt der Overhead von 158 byte?

Woher es kommt ist schwer zu sagen. Unter Umständen kommt eine Rückantwort über der 2. GW. Ich hatte bei einige Test mit wireshark komische Phänomene die auf so etwas deuten.