IPV6 mit FREETZ NG und dnsmasq. Routing-Probleme.

[hermann72pb]

Ich nutze seit ein Paar Wochen freetz-ng-20986 auf meiner 7590 mit FW7.50 und aktiviertem dnsmasq (nach der wrapper-Methode von cuma/fda, die etwa seit Mitte Januar funktioniert). Da dnsmasq nun auch IPV6 unterstützt, habe ich nun angefangen, vorsichtig IPV6 bei mir im Netz in Betrieb zu nehmen. An sich funktionierte das Ganze anfangs mehr oder weniger gut und stabil, bis ich einige Zeit später gemerkt hatte, dass ich manche externe Seiten nicht erreichen kann. Wie es sich herausgestellt hat, lag es an IPV6. Meine Geräte im lokalen Netz haben bereits IPV6 "erkannt" und haben logischerweise versucht die Verbindung mit dem Ziel über IPV6 aufzubauen, sobald das Fernziel einen AAAA konfiguriert hatte.
Das Problem "heilt" sich mit einem Reboot der Box, was ich schon ein Paar als "Heilmittel" eingesetzt hatte. Danach ist die Welt eine gewisse Zeit in Ordnung und ich kann externe IPV6-Adressen erreichen. Das hält aber nur eine gewisse Zeit lang.
Es war für mich relativ schwierig, das Problem zumindest teilweise einzugrenzen. Ich hatte anfangs die Namensauflösung von DNSMASQ in Verdacht. Bei einer näheren Analyse mit "dig" von den linuxfähigen RPIs im lokalen Netz hat sich aber gezeigt, dass die AAAA-Anfragen von der Box sauber beantwortet werden. Sprich: DNS an sich funktioniert ja schon, dafür aber "ping6" aus dem lokalen Netz nach draußen weder mit dem Namen noch mit der IPV6 möglich (Fehlermeldung: Das Netzwerk ist nicht erreichbar).
Gegenseitiges ping6 (sowohl mit dem Namen als auch mit einer IP) im lokalen Netz funktioniert. Man kann auch die FritzBox per ping6 aus dem lokalen Netz erreichen. Also, IPV6 geht grundsätzlich zumindest im lokalen Netz.
Unmittelbar von der FritzBox (per ssh mit der box verbunden) kann ich die externen Adressen per ping6 erreichen (sowohl mit Namen, als auch mit IP). Sprich: Die IPV6-Verbindung von der Box nach draußen besteht und scheint zu funktionieren.
Logische Schlussfolgerung meinerseits: Irgendwas stimmt mit dem IPV6-Routing der Box nicht.
Bloß, wie kann ich das Problem weiter eingrenzen und nach Möglichkeit beheben? Zumindest mit irgendeinem Workaround.
Daher meine Fragen:
1. Hat schon jemand ähnliche Probleme beobachtet?
2. Habt ihr für mich Tipps, wie ich das Problem weiter eingrenzen kann?

Edit:
Mein Vergleich der Routing-Tabellen mit und ohne Problem hat gezeigt, dass offensichtlich folgende Routen fehlen:

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
xxxx:yyy:zzzz::/64                          ::                                      U     256    0        0 dsl    
xxxx:yyy:zzzz:1::/64                        ::  Hat 256 anstatt 128 als metric ==>  U     128    4      277 lan    
xxxx:yyy:zzzz:1::/64   <== fehlt            ::                                      U     256    0        0 lan    
xxxx:yyy:zzzz:2::/64   <== fehlt            ::                                      U     128    0        0 guest  
xxxx:yyy:zzzz:2::/64   <== fehlt            ::                                      U     256    0        0 guest

Also, meine Vermutung mit dem Routing wahrscheinlich richtig. Frage ist nur, wodurch gehen die Routen verloren? Wie kann man es erkennen und ggf. als workaround per cron und shell-script reparieren, wenn denn sowas passiert?
Box rebooten wäre ein bisschen overkill als workaround. Vor allem, weil sie bei mir jedes Mal 3-5 Minuten für den DSL-Sync braucht, manchmal sogar mehr.

 

[WileC]

Hallo Hermann,

ich habe zwar keinen Lösungsvorschlag, aber einen Gedanken: macht deine Box einen Reconnect, wenn dann dein IPv6-Problem auftritt? Dann könnte es vielleicht daran liegen, dass das neue IPv6-Präfix nicht per RA (Router advertisement) an die Clients weitergegeben wird?

Ich habe lokal kein IPv6 laufen, deswegen - es ist nur so ein Gedanke.

VG

 

[frank_m24]

Ist in der Routing Tabelle keine Defaultroute?

Ich habe den Eindruck, dnsmasq und die AVM Deamons kommen sich in die Quere. Dafür spricht, dass es mehrere identische Routen mit unterschiedlichen Metriken gibt. Was macht das erste /64 Subnetz deines Prefixes auf dem DSL Interface? Das sollte nicht so sein. Und es fehlen wichtige Einträge. Ist das wirklich die komplette Routing Tabelle?

 

[hermann72pb]

Nein, es ist natürlich nicht die komplette Routing-Tabelle. Ich habe es versucht visualisiert in Form eines "diffs" sozusagen darzustellen, woran sich die beiden Rooting-Tabellen unterscheiden, wenn ich das Problem habe und wenn ich es nicht habe. Mit den Pfeilen sind da entsprechende Zeilen markiert, die dann anders sind oder fehlen. Und ja, nur IPV6 und nur auf Interfaces DSL, LAN und GUEST bezogen.
Ja, ich vermute da auch sehr stark irgendeine Interaktion zwischen dem multid und dnsmasq. cuma/fda hat es zwar herausgepatcht, man weiß ja nie, ob da irgendwelche Überbleibsel doch geblieben sind und bei bestimmten Aktionen der Box zu solchen Nebeneffekten führen. Eigentlich ist ja multid porttechnisch komplett woanders verlegt. Dadurch können wir nun dnsmasq starten. Aber ja, man kann es dennoch nicht ausschließen, dass multid da "dazwischenfunkt" und z.B. die Routen löscht, weil er die neu anlegen will, was aus irgendwelchen Gründen auch immer dann am Ende nicht passt.
Die Theorie mit doppelten Routen ist auch interessant. Kann denn jemand ohne dnsmasq seine Routing-Tabelle mit IPV6 hier ähnlich posten, dass ich z.B. die Metriken vergleichen kann, Anzahl der Routen etc.?
Bzgl. DSL-Recconect. Wie meinst du es? Richtig mit dem Verlust des DSL-Links usw.? Oder rein Erneuern der externen IP-Adresse? Erneuern der externen Adresse passiert bei mir automatisch alle 24 Stunden. Ich habe natürlich nicht geprüft, ob sich dabei die IPV6-Adresse wirklich ändert. Die IPV4 tut es aber auf jeden Fall täglich. Ich bin nicht bei Telekom, wo es aktuell tatsächlich nicht jeden Tag passieren würde. Meine Probleme entstehen aber eher sporadisch und auf keinen Fall öfter als alle 24 Stunden. Daher würde ich den Zusammenhang mit dem Wechsel der externen IP-Adresse fast ausschließen.

 

[frank_m24]

Pflücke die Routen mit und ohne dnsmasq auseinander. Ich sehe in deinem kurzen Ausschnitt ne Menge Unsinn. In Anbetracht des Setups kommt dafür eigentlich nur eine massive Fehlkonfiguration von dnsmasq infrage. Der multid verteilt das erste Subnetz schon im LAN und packt es nicht aufs DSL Interface. Aber um das im Detail beurteilen zu können, müsste man das komplette IP und Routensetup sowie die dnsmasq Konfiguration sehen. So ist das unmöglich beurteilen.

 

[hermann72pb]

Meine dnsmasq-Konfiguration ist zu spezifisch dafür, dass ich sie hier offen posten würde. Sie wird mehr Fragen als Antworten hervorrufen, weil ich ja dnsmasq nicht aus Spass verwende, sondern, um mir meine sehr spezifische DNS-Konfiguration damit zu erzeugen, die im Falle von IPV4 per DHCP auf die Clients verteilt wird. Im Netzwerk laufen auch redundante samba-basierte ADDC, wozu ich auch dnsmasq nutze, um per DHCP diese Informationen an die Clients zu verteilen. Jetzt wirst du natürlich sofort sagen: Klar, daran liegt es. Und genau eine solche Diskussion auf dem Niveau will ich hier vermeiden. Denn in der IPV4-Welt hat das alles wunderbar seit einigen Jahren funktioniert.
Alle custom-Einträge beim dnsmasq stammen noch aus der IPV4-Zeit und beinhalten zum Teil Domänen-Namen usw. Ziemlich viel Privatinformation. Routing-Tabelle ist mir auch schon zu heikel dafür, um hier unzensiert gepostet zu werden. Und wenn ich das alles ausiXe, wie oben, versteht man dann hier wieder nur Bahnhof.
Bzgl. default route. Die gibt es bei mir nur bei IPV4 und sie bleibt in beiden Fällen bestehen (mit Problem und ohne Problem). Beim IPV4 habe ich ja auch keine Probleme. Beim IPV6 sehe ich keine default-Route. Es funktioniert aber anscheinend auch ohne diese.
Ich habe übrigens seit mehreren Tagen keine Ausfälle mehr und die oben gepostete Route mit doppelten Einträgen scheint ja trotzdem zu funktionieren, abgesehen davon, ob sie richtig oder falsch ist.
Aber gut, ich sehe schon: Ich muss mich selbst in die Thematik reinfuchsen.

 

[frank_m24]

Bzgl. default route. Die gibt es bei mir nur bei IPV4 und sie bleibt in beiden Fällen bestehen (mit Problem und ohne Problem). Beim IPV4 habe ich ja auch keine Probleme. Beim IPV6 sehe ich keine default-Route. Es funktioniert aber anscheinend auch ohne diese.

Du brauchst zwingend eine Default Route. Die kann aufs Device zeigen oder ein link-lokales Gateway haben, aber sie muss da sein, zumindest, wenn du die Standard Mechanismen des Linux Kernels verwenden willst (was du willst, wenn du den multid ausschaltest). Ggf. macht AVM mit dem multid das anders, aber das hilft dir nicht.

und die oben gepostete Route mit doppelten Einträgen scheint ja trotzdem zu funktionieren

Da sie bis auf die Metrik identisch sind, ist es nicht so schlimm. Sie sorgen allenfalls für ein wenig mehr Systemlast, aber bei der Anzahl ist das wohl irrelevant. Aber es ist unschön und zeigt, dass das was nicht stimmt, denn in einem ordentlich abgestimmten Setup wären sie nicht da. Und wo einmal geschlampt wurde ...

Jetzt wirst du natürlich sofort sagen: Klar, daran liegt es. Und genau eine solche Diskussion auf dem Niveau will ich hier vermeiden.

Naja, muss man die ganze Interface- und Routenkonfiguration auf den Kopf stellen, um ein paar Informationen per DHCP zu verteilen? Man kann es ja selber machen, aber warum dafür kollidierende Einstellungen verwenden? Dazu: Bei IPv6 werden die Informationen möglicherweise nicht per DHCP, sondern per RA verteilt. Vor allem die fehlerhafte IPv6 Route auf dem DSL Interface könnte auch von einer falschen RA Konfiguration kommen.

Es mag ja sein, dass du viel Hirnschmalz in dein Netzwerk gesteckt hast. Aber trotzdem vermute ich genau da den Fehler. Aber wie gesagt: Ohne Eingangsinformationen keine Analyse. Das alles ist Stochern im Nebel und wilde Vermutungen.

 

[hermann72pb]

Mir geht es nicht um Gehirnschmalz. Wie gesagt, da stehen viele private Informationen drin. Das ist der Hintergrund.
Danke trotzdem für ein Paar weitere Hinweise. Da kommen wir schon näher an die Ursache!
Zunächst fernab zu diesen doppelten Einträgen. Ich habe es gerade auf einer anderen 7490-Box geprüft, die einen älteren FREETZ NG hat. Auf der Box habe ich zwar auch dnsmasq, aber wohl noch die ältere Version, auch ein älterer Stand von FREETZ NG. Der alte dnsmasq war wohl noch nicht IPV6-fähig und allgemein lief es vor einem Jahr auch anders bei FREETZ NG mit den wrapper und co. Die Box hat keine so komplizierte dnsmasq-Konfiguration, wie bei mir, hat auch einen anderen Provider (die IPV6-Anbindung an den Provider könnte auch eine gewisse Rolle spielen). Also, unterschiedlicher könnte es nicht sein. Und die hat diese doppelten Einträge da mit genau dieselben 128 und 256 Metriken. Also, behaupte ich mal, dass es zwar ggf. unschön ist, aber vermutlich nicht nur mich betrifft und nicht mein dnsmasq.
Bzgl. default route. Ich sagte doch, ich musste mich reinfuchsen. Ich bin in der IPV6-Welt noch relativ neu. Und ja, die gibt es und die verschwindet nicht im Fehlerfall. Daher hatte ich die da oben zu deiner Verwirrung nicht gepostet, weil sie ja unverändert bleibt. Mein Verständnisproblem lag daran, dass ich genau so, wie "route" von busybox nicht wusste, dass ::/0 diese Default-Route darstellt. In der ipv4-Welt nennt busybox es "default", wenn man -n weg lässt, bei ipv6 aber nicht. Aber sei es drum: Default-Route ist da.
RA. Hier kommen wir der Sache schon näher. Unter AVM-WebIF gibt es nämlich diverse Einstellungen zu dem Thema. Und an denen hatte ich tatsächlich bisschen rumgedreht, weil ich mir bis jetzt immer noch nicht sicher bin, ob und wie diese RA-Einstellungen richtig einzustellen wären, damit multid damit dem dnsmasq nicht in die Suppe spuckt. Und ja, diese Einstellungen waren bei mir vor ein Paar Tagen tatsächlich anders, als jetzt, weil ich die Frage zum "anderen Server im Netz" auch so deute, dass der dnsmasq auf der selber Box da eigentlich auch "ein anderer Server" so gesehen wäre.
Die Einstellungen kann ich hier gerne posten. Und mit denen hatte ich rumgespielt.
Und ja, ich habe beim dnsmasq einen DHCPV6-Server eingerichtet und der verteilt auch fleißig eine einzige Adresse an einen einzigen DHCPV6-Client hier bei mir, der es so haben will. Und ja, ich weiß, dass es so blödsinnig ist und eigentlich per RA erfolgen sollte. Aber der Rechner ist nicht in meiner Verwaltung und bleibt für mich somit ein Unikum mit diesem DHCPV6.
Bzgl. RA anstelle dieser DHCP-Verteilung und zum Thema, dass ich das alles rausschmeißen könnte. Ja, langfristig wahrscheinlich schon. Wenn ich es aber jetzt schlagartig mache, lege ich bei mir hier vermutlich alles lahm. Denn diese Dualität mit IPV4 und IPV6 ist derzeit wahrscheinlich auch einer der Gründe, dass vieles noch als Fallback per IPV4 läuft, auch die ganzen NAS, ADDC, Windows-Rechner usw. Komplett auf IPV4 zu verzichten wird bei mir vermutlich aufgrund der Vielzahl der Geräte, die nur IPV4 beherrschen gar nicht möglich sein.

 

[frank_m24]

Ich glaube so langsam, wir hab hier wieder einen Fall, wo jemand von der Komplexität seines eigenen Netzes überfordert ist. Deine Bemerkungen über die Defaultroute und RAs lassen vermuten, dass dir einfach die Grundlagen fehlen. Es ist nicht die konkrete Konfiguration das Problem, sondern der Umstand, dass du keine Ahnung hast, was du da eigentlich tust und wie du dein Ziel mit IPv6 erreichen kannst.

Ohne auf alles im Detail einzugehen: die anderen Server in der AVM Konfig beziehen sich natürlich auf andere Netze, und nicht auf Server, die die gleichen Informationen verteilen, wie die Fritzbox selber. D.h. entweder oder: wenn du dnsmasq nutzen willst, muss es in der Fritzbox deaktiviert werden. Und RAs können DHCPv6 nicht ersetzen, spätestens bei PD. Du musst dir nur präzise überlegen, welche Info du wo verteilst. Eine Fritzbox und ein dnsmasq, die diesbezüglich widersprüchlich konfiguriert sind, macht es nicht einfacher. Und genau das kann Routen verschwinden lassen oder an falscher Stelle auftauchen lassen usw.

Bevor du jetzt alles deaktivierst: mach dir klar, welche Info im Moment von wem verteilt wird, was davon benutzt wird und wie du es zukünftig verwenden willst. Jetzt einfach irgendwas auszuschalten, lässt vermutlich dein Netz zusammenbrechen.

 

[hermann72pb]

Ich lasse es so hier im Raum stehen, wenn du mit der Glaskugel aus der Ferne so tiefgründlich über mich urteilen magst. Aber sei es drum. Der Hinweis mit RA war der Anstoß in die richtige Richtung für mich. Dafür danke. Rest der Diskussion kann man sich dann hier ersparen.

 

[heimi666]

Ich hab auch IPv6 und dnsmasq und für ipv6 nur

enable-ra
dhcp-range=tag:lan,::1,constructor:lan, ra-names, 12h

engänzt.
Was mir auffällt ist das Deine routing tabellen nicht zwischen underschiedliche v6 Präfixes unterscheidet.
Deine Clients brauchen eine routbare GUA Adresse 2003::/3 alle anderen Adressen ULA oder LL kannst du getrost ignorieren, mit obigem Änderungen klappt das auch, das das richtige Präfix verteilt wird.
Deine Client routen mit 2 vorn solten dann "proto ra" haben, auf der fritzbox gibts dann eine v6 default route nach draussen und eine fürs Präfix (also GUA Adressen für die Clients), eigendlich relativ einfach.
Ich kann mir vorstellen, das das hakt wenn dein Provider Deiner FB ein neues Präfix zuweist (ich bemerke aber, das das sogut wie nie vorkommt / vorkommen muss) Ich hab seit Wochen schon das gleiche.