Mal eine ganz naive Frage: seit fast 5 Stunden ist IPV6 tot. Und ich sehe keine Probleme. 14 Clients an einer Node kein Thema. Was für Auswirkungen hat denn der Ausfall von IPV6 überhaupt?
Seiten, die IPv6 anbieten, werden von vielen Browsern auch bevorzugt darüber angesprochen. Es kommt dann zu dem Problem „manches Seiten gehen, manche nicht“. Zumindest ist das mein Stand.
Na ja, das macht auch nicht mehr so viel aus. Ich habe derzeit max. 1 Mbit/s an meinem FF-Router, auch wenn ich ihn exklusiv nutze. 
Und wenn das hier aus http://ffmap.freifunk-rheinland.net/list.html Tatsache ist, stimmt wohl eh was nicht. Die Zahl ist Anzahl VPN und rheinufer5 gibt es wirklich 2 mal.
Supernode: rheinufer5 160
Supernode: rheinufer5 0
Supernode: rheinufer4 160
Supernode: rheinufer3 3
Supernode: rheinufer2 0
Supernode: rheinufer1 102
Supernode: rheinufer0 194
Damit gehen die diversen „Uptime-Robots“ los, die einige hier auf ihre Router angesetzt haben.
Mobilgeräte am AP bemerken idR recht schnell, dass IPv6 zwar irgendwie da ist, aber keine Connectivity hat und schalten dann auf IPv4 zurück.
Das kommt auch auf den Client an. Zumindest moderne Browser implementieren Happy Eyeballs. Da kriegt einfach IPv6 ein paar 100ms Vorsprung, danach wird parallel eine IPv4-Anfrage abgeschickt, und die Verbindung die zuerst steht wird dann genutzt. Das bedeutet, dass wenn beide Protokolle gleich schnell sind, die Seite immer per v6 ausgeliefert werden wird, und wenn es ein Problem oder Latenz bei v6 gibt, der User nicht davon betroffen wird (und dann vielleicht gar versucht ist v6 wieder abzuschalten).
Kann natürlich sein, dass das bei anderen Apps als dem Browser anders ist.
Oder das darunter liegende OS.
Zumindest hatte ich bei Android den Eindruck, dass das bereits auf Betriebsystem-Ebene abgefangen würde und somit gar nicht erst auf „weniger schlaue“ Apps durchschlagen kann.
Hm, okay, weder v6 Adresse, noch ne Route, so wird das auch nix…die ULA fda Adressen verteilt der Router lokal, aber damit kann man nix anfangen…
Unsere IPv6-Anbindung zieht gerade um und wird heute erst im Laufe des Tages wieder verfügbar.
2 „Gefällt mir“
Ohne zu nerven oder unbeabsichtigt Druck aufbauen zu wollen:
Mich interessiert ja sehr was da gerade im Hintergrund passiert. Dürfte ich erfahren was da gerade passiert bzw wie der Stand der Dinge ist?
Ich sehe nur, dass meine Nodes nicht via IPv6 zu erreichen sind.
3 „Gefällt mir“
Zwischenstand:
Genau dafür benötigen wir ein Werktzeug (Jehova) wo Änderungen, Updates, Störungsbeseitgung , Status verbindlich u zeitnah dokumentiert werden müssen… nein kein ITIL, aber ein Basis Workflow der von allen gelebt und genutzt werden kann.
Insbesondere IPv6 schaut jetzt wirklich viel besser aus!
Danke für die Arbeit, so können wir ja wieder Geräte ausrollen 
5 „Gefällt mir“
Gerade erreicht mich die Meldung von meinem Lieblingsunterstützer: Freifunk läuft nicht. Ich kann das bestätigen. Gerade kann ich die Bytes hereintröpfeln sehen.
Die Übertragungsrate lag in den letzten Tagen bei unter 1 Mbit/s. Egal welches Device, egal an welcher Node. Auch die IP-Vergabe dauert sehr lange.
Die 7 Supernodes scheinen zu arbeiten, die Verteilung ist gut.
Wo ist das Nadelöhr? Oder geht mir das nur in Mettmann so?
Nein, wir haben das Problem hier in Aachen auch.
Ich habe den starken Verdacht das Problem ist diesmal IPv4.
Per IPv6 ist alles bestens:
traceroute6 www.six.heise.de
traceroute to www.six.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85) from 2a03:2260:40:0:690d:e0d0:e563:5cc4, 30 hops max, 24 byte packets
1 2a03:2260:40::1 (2a03:2260:40::1) 81.38 ms 71.227 ms 70.452 ms
2 2a03:2260:0:7::1 (2a03:2260:0:7::1) 82.769 ms 83.277 ms 90.257 ms
3 2001:8d8:2:1050::1 (2001:8d8:2:1050::1) 83.4 ms 89.425 ms 79.132 ms
4 te0-0-2-3.c350.f.de.plusline.net (2001:7f8::3012:0:2) 81.952 ms 86.087 ms 218.931 ms
5 te2-2.c301.f.de.plusline.net (2a02:2e0:11:16:c::301) 104.999 ms 156.462 ms 84.501 ms
6 2a02:2e0:10:0:c::2 (2a02:2e0:10:0:c::2) 83.035 ms 85.64 ms 83.077 ms
7 te2-4.c102.f.de.plusline.net (2a02:2e0:10:1:c::2) 166.857 ms 83.275 ms 177.91 ms
8 2a02:2e0:3fe:0:c::1 (2a02:2e0:3fe:0:c::1) 84.389 ms !S 175.161 ms !S 86.266 ms !S
Über IPv4 geht nichts:
tracepath www.heise.de
1?: [LOCALHOST] pmtu 1280
1: 10.40.100.1 76.814ms
1: 10.40.100.1 71.821ms
2: no reply
3: no reply
Nachdem ich die IPv4 Adresse manuell entfernt habe ging das Netz gleich wieder schön flüssig, leider aber nur bei den paar Anbietern die bereit voll IPv6 unterstützen. Seltsam ist dass ohne das Löschen der Adressen auch IPv6 kompatible Seiten wie ffmap oder dieses Forum nicht geladen wurden. Ganz ohne IPv4 flutscht es halbwegs.
Mein Knoten ist verbunden zu:
mesh_vpn_backbone_peer_rheinufer5&6
Ebenfalls bestätigt ist das Problem von einem Knoten aus der mit 0&1 und einem der mit 0&2 verbunden ist.
Nach Neustart von fastd auf dem lokalen Knoten und Verbindung zu rheinufer 0&3 sieht es viel besser aus:
tracepath www.heise.de
1?: [LOCALHOST] pmtu 1280
1: 10.40.0.1 32.318ms
1: 10.40.0.1 32.653ms
2: 100.64.0.12 49.047ms
3: irb-1050.bb-a.fra3.fra.de.oneandone.net 53.290ms asymm 5
4: te0-0-2-3.c150.f.de.plusline.net 55.649ms asymm 7
5: 82.98.102.9 57.090ms asymm 7
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: 212.19.61.13 51.016ms !H
Resume: pmtu 1280
traceroute6 www.six.heise.de
traceroute to www.six.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85) from 2a03:2260:40:0:690d:e0d0:e563:5cc4, 30 hops max, 24 byte packets
1 2a03:2260:40::1 (2a03:2260:40::1) 23.573 ms 23.136 ms 24.446 ms
2 2a03:2260:0:9::1 (2a03:2260:0:9::1) 31.274 ms 32.32 ms 32.896 ms
3 2001:8d8:2:1050::1 (2001:8d8:2:1050::1) 57.034 ms 56.645 ms 39.288 ms
4 te0-0-2-3.c350.f.de.plusline.net (2001:7f8::3012:0:2) 52.365 ms 40.267 ms 43.546 ms
5 te2-2.c301.f.de.plusline.net (2a02:2e0:11:16:c::301) 39.225 ms 39.747 ms 42.628 ms
6 2a02:2e0:10:0:c::2 (2a02:2e0:10:0:c::2) 47.561 ms 41.963 ms 39.329 ms
7 te2-4.c102.f.de.plusline.net (2a02:2e0:10:1:c::2) 39.199 ms 39.863 ms 44.269 ms
8 2a02:2e0:3fe:0:c::1 (2a02:2e0:3fe:0:c::1) 66.642 ms !S 50.243 ms !S 39.523 ms !S
@nomaster das Problem liegt also offensichtlich auf Rheinufer0 nicht vor. Schaut danach aus, dass etwas mit der IPv4 nat nicht stimmt, vielleicht die v4 Transportnetze?
Ich habe ein Problem mit der Verbindung der Supernodes untereinander gehabt. Diese haben sich teilweise nicht direkt miteinander verbunden, sondern nur indirekt über reguläre Nodes. Das war natürlich nicht performant. Heute Nacht habe ich das Problem lösen können, in dem ich für diese Verbindungen separate Mac-Adressen verwende.
Das andere Problem war die Reihenfolge der IPv4 Routing-Regeln. Bei manchen hat die explizite Angabe einer Priorität gefehlt, so dass die Pakete nicht in der richtigen Routing-Tabelle gelandet sind. Das ist jetzt auch gelöst.
9 „Gefällt mir“
Danke für deinen unermüdlichen immer flotten Einsatz!
5 „Gefällt mir“
9,77 Mbps down und 7,83 Mbps up, wow!
Mal schauen, wie es heute abend wird 
2 „Gefällt mir“
Hier in Aachen ist wieder so ziemlich alles offline… nur link local Adresse. Kein v6, kein v4 (SN rheinufer 0+2)
IPv6 scheint zu gehen, IPv4 scheint tot.
Anscheinend gibt’s weder IP noch DNS-Server vom DHCP-Server.
Fastd-Verbindung über rheinufer0 und rheinufer2.