Hallo Zusammen,
wir haben das Problem das fastd an Unitymedia Anschlüssen die DsLite haben den tunnel über die NAt IPv4 IP herstellt. Der Tunnel kommt dann zustande, aber ist trotzdem irgendwie kaputt. Autoupdate geht nicht, SSH Verbindungen brechen ab etc.
Kann man fastd sagen das er IPv6 bevorzugen soll? Interessiert fastd die Rheienfolge der Server einträge?
Hier ist es genau umgekehrt.
Was aber wohl daran liegt, dass die Gluons beim Starten des Switches kurzzeitig IPv6-Routen/Prefixe auf dem Wan-Port announcen, was dann die umstehenden im FF-Router im gleichen Netz total durcheinanderbringt, weil diese Routen wenige Sekunden (wenn der Switch vollständig konfiguriert ist im OpenWRT) nimmer funktionieren.
Aber zum Thema: Was für eine Domain ist denn betroffen?
(notfalls kann man auch in den betroffenen Routern die /lib/gluon/site.conf editieren, also die IPv6 oder IPv4 herauswerfen.)
Was die Instabilität betrifft bei IPv4-vpnmesh an CGNv4 anbelangt: Ich habe da die MTU-Size in Verdacht.
Welche MTU steht denn in der site.conf? 1406 oder 1426?
Gibt es die site.conf irgendwo zu sehen?
Es geht um die Troisdorfer Firmware. Die Probleme treten nur bei unitymedia auf.
Die Lösung mit Site.conf editieren hilft, ist aber keine super Lösung.
IPv6 only aber leider auch nicht, da es ja noch viele Anschlüsse ohne IPv6 gibt.
Mtu: 1426
Unsere Aktuelle site.conf
Kann sein dass Du die MTU auf 1406 senken musst…
Gebt ihr intern über den DHCP schon 1280 raus?
dhcp-option-force=26,1280
Egal, das ist wieder was anderes und hat mit Deinem Problem erstmal nichts zu tun.
Jedenfalls müsst ihr extern:
1426 für IPv4 only haben
aber 1406 für IPv6
Selbst mit 1406 kann es in ungünstiger Konstellation noch sein, dass die Verbindung keine Daten durchbekommt, aber nur im Einzelfall. Mit 1426 werdet ihr nicht glücklich für den v6 fastd Aufbau…
Aber ich kann 1406 für IPv4 und IPv6 nehmen oder?
eth0 Link encap:Ethernet Hardware Adresse bc:ae:c5:36:83:28
inet Adresse:10.188.252.66 Bcast:10.188.255.255 Maske:255.255.0.0
inet6-Adresse: fe80::beae:c5ff:fe36:8328/64 Gültigkeitsbereich:Verbindung
inet6-Adresse: fda0:747e:ab29:7405:beae:c5ff:fe36:8328/64 Gültigkeitsbereich:Global
inet6-Adresse: fda0:747e:ab29:7405:788f:20a5:2278:afa7/64 Gültigkeitsbereich:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:191412 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:113025 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:244118794 (244.1 MB) TX-Bytes:10817979 (10.8 MB)
MTU scheint 1500 zu sein… (Intern)
1406 kann man für beide nehmen, ja.
Mit 1406 muss die Verbindung noch nicht unbedingt funktionieren, dies ist von der MTU der Anbieterleitung abhängig.
Im IRC wurde eine MTU 1312 empfohlen um maximal kompatibel zu sein, bei so wenig wie möglich Performanceeinbuße.
Als Minimum kann man 1194 setzen, aber das drückt halt auf die Performance: 1280 - 52 - 14 - 20 = 1194 bytes
Fastd kann derzeit noch nicht selber fragmentieren, eventuell ab fastd v18…
Als Fallback für einen Server könnte man das tun.
Aber da weder ein Fallback bei zu großer MTU stattfindet, noch der Server überprungen wird, wenn die anderen auch laufen: Ginge nur manuell.
Oder man bräuchte ein MTU-detection-script auf dem Node, welches dann an der site.conf herumfummelt…
P.S: Irgendwer hatte neulich eine MTU von 1 vorgeschlagen. Weil das mit Sicherheit nicht mehr fragmentieren kann…
Kurze Frage zum vorgehen… Wie schaffe ich es denn die MTU zu ändern?
Wenn ich auf dem Server die MTU auf 1406 setze und die Nodes noch 1426 haben verbinden sie sich dann trotzdem?
Wie würdet ihr vorgehen?
Für mich sieht es so aus als ob wir für die Übergangszeit 2 fastd Instanzen laufen lassen müssen bis alle Nodes die Aktuelle FW haben… Sehe ich das falsch?
Kann mal bitte jemand allgemein irgendwo festhalten, welche Interfaces welche MTU eingestellt haben müssen?
Bei uns auf den Nodes hat nur die mesh-vpn Schnittstelle eine MTU von 1426, (wlan0 hat 1528) alle anderen Interfaces haben alle eine 1500er MTU.
Auf dem Gateway sieht das ganze gleich aus, alle Interfaces 1500 und nur die mesh-vpn Schnittstelle von fastd hat eine MTU von 1426.
Und was hat die MTU mit unserem DHCP Server zu tun?
Die externe Seite zwischen den fastd Peers hatte ich oben kurz angerissen.
Überall da wo Übergänge zwischen Netzwerken sind muss man sich Gedanken über die MTU machen.
Wenn die Clients mit 1280er MTU arbeiten sollte es keine Probleme mehr geben, deshalb das Senden über den DHCP, funktioniert aber nicht immer.
Auf den NAT Servern sollte zur Sicherheit nen MSS Clamping als Paketmanipulation hin:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
http://lartc.org/howto/lartc.cookbook.mtu-mss.html
Damit sollten auch die Dienste hinter dem nächsten Netzwerkübergang (ins Internet) laufen, die eine Aushandlung nicht oder broken unterstützen…
Also wir haben in fastd eine MTU von 1426, alle anderen Interfaces 1500. Ich habe jetzt mal wie oben beschrieben 1280 als MTU in der dnsmasq config eingestellt.
Siehe Gluon-Liste: 1406 (oder weniger) sollten es sein, wenn man davon ausgeht, in diesem Leben noch v6-Clients zu sehen. 1280 war IIRC das absolute Minimum bei IPv6. Irgendwo dazwischen würfeln, wobei 1406 IIRC schon DSL-Overhead abgezogen hat.