Woran hat es denn jetzt eigentlich gelegen, dass die VMs keine v6-Konnektivität hatten? 
V6 läuft noch nicht (Von Netcup, das interne FFRL V6 klappt natürlich).
Warum wissen wir noch nicht, da aber die meisten User per V4 verbinden habe ich die Nodes jetzt schon in Betrieb genommem.
mtu = 1426
könnte sein das es schlicht nicht durch die Anschlüsse passt, weil der v6 header größer ist…
Habe wir bei uns auch getestet… IPv6 ohne MTU 1406 ging garnicht oder nur selten / mit abbrüchen.
Joa, da muss man minimum auf 1406 runter, das ist auch der empfohlene Wert aktuell.
Wobei da je nach Region die Meinungen auseinander gehen, zwischen 1312 und 1406 sind da sämtliche berechenbaren Werte bei. Kommt eben auf die Anbindung der Nodes an, was da durchgeht, oder eben auch nicht mehr durchpasst, da fastd derzeit noch nicht fragmentieren kann…
Ja Ich habe hier die letzten Tage an allen Providern die ich so finden konnte getestet. Mit 1406 ging es überall.
1 „Gefällt mir“
Deutschlandweit scheint es wohl ein paar abstruse Aufschaltungen zu geben, nennen wir es mal einfach „Sonderlocken“.
Hattest Du auch schon Kabelanschlüsse dabei, z.b. Unitymedia?
Ja. Unitymedia war der Problemauslöser… Es ist ein Unitymedia Anschluss mit DS-Lite… Über die NAT v4 adresse kommt zwar ein Tunnel zustande, der ist aber total instabil. Desswegen wollten wir IPv6 Testen. Mit einem Tunnel über IPv6 geht der anschluss
2 „Gefällt mir“
@FxFx hat daran mit Sicherheit großes Interesse, wir haben in Aachen einen für uns wichtigen Anschluss bei einem Unitymedia Kunden.
Hast du uns Details zur Config Anpassung?
@CyrusFox Die Alfred Config wurde beim mutmaßlichen clonen der VMs anscheinend noch nicht angepasst. Auf der Liste tauchen Supernode 1-3 doppelt auf, die Duplikate jedoch ohne Angabe der Zahl der Tunnel. Dadurch haben Knoten die zu den neuen Supernodes verbunden sind auch fälschlicherweise nur 0-1 VPN Tunnel angezeigt.
1 „Gefällt mir“
Wir haben einiges getestet… Rausgekommen ist folgendes:
- fastd Server und Node mit MTU 1406
- fastd IPv6 Aktiviert (site.conf und Server)
- Auf dem Node muss anscheinend auf dem WAN Interface IPv4 deaktiviert werden, da der Node ansonsten die Verbindung über IPv4 herstellt, weil die IPv4 adresse zuerst zugewiesen wird.
Die richtige MTU hatte ich bei euch auf der Supernode bereits bei der initialen Config IPv6 gerecht eingestellt > 1406
Meine zwei Rheinufer Knoten schickten kurz vor 19 uhr einen Hilferuf durch das monitoring. Seit dem sind sie nicht mehr zu erreichen
Ich kann seit ca. einer Stunde keine IPv6-Verbindungen mehr herstellen (von den Nodes selber und aus dem Freifunk-WLAN).
Vielleicht liegt’s daran.
IPv4 funktioniert hingegen problemlos.
Stimmt, seit etwa 19 Uhr ist kein Node mehr per IPV6 erreichbar.
da lob ich mir doch aldi talk
Kann ich nicht sagen wie Rheinufer derzeit angebunden ist.
Ich kann höchstens mal auf dem bb0 nachsehen, ob da falsche Routen gezogen wurden.
Für mich wirkt es augenscheinlich so, als würde ich gar keine IPv6-Route zu einem Gateway bekommen.
Bin aber auf’m Sprung, deshalb könnte ich da erst später detailliert nachschauen.
Also auf bb0 gibt es nur eine Route:
2a02:f98:0:28::/64 via 2a03:2260:ffff:2::1 dev rheinufer0 metric 1
Mach mal nen traceroute, um zu zeigen wo es klemmt, und mach mal nen ip -6 a und ip -6 r…das kann ich von aussen sonst nicht einschätzen wo es klemmen könnte…
Vom mobilen Client kann ich schon mal mit den ip-Ausgaben dienen:
