Mal wieder: Kein IPv6 bei Deutsche Glasfaser

Korrekt, alles was grau ist, kann ich nicht ändern. Die WAN xxxx ist eine andere.

Würde eine Fritz mein Problem lösen?

Zitat von idb

Würde eine Fritz mein Problem lösen?

Einen Versuch wäre es wert - hier kannst du eine für eine Mindestlaufzeit mieten; habe ich seinerzeit bei meinem Wechsel vom Telekom-VDSL-Anschluss zu DG auch gemacht.

OK. Danke für den Tipp

Ich würde eigentlich der DG schreiben, dass sie den Router tauschen sollen, wenn es an dem liegt. Deshalb mietet man doch.

In ein teureres Mietmodell sollte man deswegen eigentlich nicht wechseln müssen.

Zitat von idb

Hallo zusammen,

bin neu hier im Forum und mich angemeldet, weil ich wohl auch das hier geschilderte Problem habe: Ich habe eine IPv6 Adresse, komme aber keinen ping/Zugriff auf Internet IPv6 Adressen. Ich habe gefühlt 10 Tickets bei DG mit

Moinsen,

bie mir lief es so:

4.02. BNG Störung, keine IP6 erhalten, Ticket aufgemacht - wurde am 7.02. geschlossen mit dem Hinweis Störung behoben. Danach IP6 (die alte) bekommen, aber kein Inbound / Outbound Routing im BNG.

10.02. Neues Ticket aufgemacht und detailliert Fehler beschrieben mit dem Hinweis "Port am BNG falsch konfiguriert, Problem an 2nd Level weiterleiten" (im 1st Level, meist ein outsourced Callcenter, kann soetwas in der Regel nicht entstört werden).

17.02. Ticket lag immer noch unbearbeitet, per Telefon DG Vertrieb angerufen und hingewiesen, dass seit 2 Wochen der Vertrag nicht erfüllt wird verbunden mit der Frage, ob DG das beheben möchte oder ich aussergewöhnlich kündigen soll. Dann gings schnell, am nächsten Morgen ca. 2 Uhr lief das Routing wieder.

Just my 2 cents ...

Warum ist das alles mit der DGF so schwierig?? Hatten wir kürzlich auch bei zwei Businessanschlüssen - DGF eigener aktiver Netzabschluss, seit Jahren (relativ) problemloser Betrieb, Config der Fortigates auch seit 2 Jahren nicht geändert und von heute auf morgen kein IPV6 mehr!

Business-Support! sagt mir: Setzen sie ihr Netzwerk neu auf, denn vorher machen wir nichts ...

Meine Frage darauf hin: Welche Teile denn? Antwort: Das Netzwerk eben ...

... im RIPE Record für das betroffene BNG sind technische Ansprechpartner genannt, wollte diese zuerst vor Ticket aufmachen auf die Fehlkonfig hinweisen. Eine Mailadresse bounced, die zweite hat geantwortet "... kann Ihnen nicht helfen, weiterleiten mache ich nicht, machen Sie ein Ticket auf".

DG Support scheint irgendwie eine 'lights out' Organisation zu sein, 1st Level "GPON reset" und danach wirds dunkel ...

Zitat von ::1

Einen Versuch wäre es wert - hier kannst du eine für eine Mindestlaufzeit mieten;

Es bleibt natürlich anzumerken, dass man eben nicht mal kurz den DG-Mietrouter abklemmt, um stattdessen eine eigene Fritzbox zu testen - dazu müsste DG-seitig ja auch auf das Anschlussprofil "kundeneigener Router" umgestellt werden. Temporär zu Testzwecken wird man das dort wohl nicht tun.

Zitat von gponner

Warum ist das alles mit der DGF so schwierig?? Hatten wir kürzlich auch bei zwei Businessanschlüssen - DGF eigener aktiver Netzabschluss, seit Jahren (relativ) problemloser Betrieb, Config der Fortigates auch seit 2 Jahren nicht geändert und von heute auf morgen kein IPV6 mehr!

Business-Support! sagt mir: Setzen sie ihr Netzwerk neu auf, denn vorher machen wir nichts ...

Meine Frage darauf hin: Welche Teile denn? Antwort: Das Netzwerk eben ...

Hab selber einen Business Anschluss, ich kann nur dazu sagen, das ich dem bei so einem Spruch geraten hätte, weniger Drogen zu nehmen...

Hatte auch mal ein Problem, was sie auf unseren Router, Netzwerk schieben wollten. Wenn man dann etwas ernster und bestimmend wird, natürlich nicht ausfallend..., dann bewegt sich da schon etwas. Jedenfalls meine Erfahrung, da dann immer noch am selben Tag der Second Level Support angerufen hat.. Das ist immerhin ein Business Anschluss und der hat zu laufen.

Was meinst du wohl, wie ausfallend ich geworden bin!! Ist trotzdem ein Unding in der Häufigkeit bei dem Laden!

Zitat von Taxan4711

... im RIPE Record für das betroffene BNG sind technische Ansprechpartner genannt, wollte diese zuerst vor Ticket aufmachen auf die Fehlkonfig hinweisen. Eine Mailadresse bounced, die zweite hat geantwortet "... kann Ihnen nicht helfen, weiterleiten mache ich nicht, machen Sie ein Ticket auf".

DG Support scheint irgendwie eine 'lights out' Organisation zu sein, 1st Level "GPON reset" und danach wirds dunkel ...

Ist das bei meinem BNG auch eine Fehlkonfig? Woran sehe ich das?

Ich würde gerne ein neues Ticket aufmachen. Aber dazu bin ich in dem Thema nicht tief genug drin.

Meine Idee: Ich schicke denen das Bild vom Heise tracert, dass die nur zur DG kommen, aber nicht zu mir und dass ich davon ausgehe, dass es wohl ein Inbound / Outbound Routing am BNG ist und die es dem 2nd Level schicken sollen...

Passt das oder hat jemand noch eine Idee? (wenn das dann immer noch nicht hilft, würde ich den Vertrieb anrufen)

@ID - ich kenne Deinen Rtr nicht, aber befürchte, dass ein DG Rrt wenig Diagnosen im Bauch hat. Falls Du überhaupt als root/admin in das Ding reinkommst (unüblich bei CPE Routern), dann such "traceroute / ping" und falls vorhanden, dann check ob IP4 und IP6 beides.

Ideal ist traceroute auf beide IP6 Google DNS, das wird bei Dir nicht funktionieren (siehe einen Post von mir paar Tage zurück als Antwort auf ::1) -> das ist der erste Beleg.

Dann traceroute von aussen (CDN) irgendeine globale IP6 in Deinem Netzwerk an (Router WAN*, Router LAN Interface*, ein PC**) die erreichbar sein sollte (!! *=Router, Firewall oder TR069 darf nicht blockieren, **=Dein PC hat vom Router eine valide globale IP6 erhalten z.B. 2a00:6020 ....., am besten eine Linux Box, WIN Boxen können zicken) -> auch dieses endet dann im BNG .....:ffff:ffff. -> das ist der zweite Beleg.

Beide Belege in ein Ticket packen (Portal -> Störung -> Anlagen) und im Text deutlich darauf hinweisen, dass die Fehlerursache im BNG liegt und Routing des Tickets in den 2nd Level notwendig ist -> Daumen drücken, dass der 1st Level Agent sein Goal "90% fix before dispatch" erreicht hat und das Ticket routen darf anstelle mit den o.a. Antworten zurückkommt.

Habs versäumt, aber nicht vergessen - Kudos ::1 ohne seine Analyse der Systematik der Addressvergabe wäre diese zielgenaue Fehleranalyse für mich erheblich aufwendiger gewesen - mercie vielmals

Ein gewichtiges Argument pro DG-Mietrouter ist ja, dass der (laut dieser Anleitung) bezüglich der Internet-Anbindung (und somit Bereitstellung von IPv4 und IPv6) zentral seitens DG konfiguriert wird.

Wenn also IPv6 nicht funktioniert, obliegt es nicht dem Kunden, dies gegenüber DG nachzuweisen und sogar noch mögliche Ursachenforschung in der DG-Infrastruktur zu betreiben (vermutlich fehlt im BNG eine IPv6-"Rückwärts-Route" zum /56-Block des Kunden über die betreffende WAN-Leitung zum Kunden-Router). Anders als beim "kundeneigenen Router" kann DG sich hier auch nicht damit herausreden, der Kunde habe seinen Router fehlkonfiguriert, denn dessen Konfiguration erfolgt ja seitens DG.

Ich würde DG freundlich auf diesen Sachverhalt in einem Ticket hinweisen, eine Gutschrift für den Zeitraum ohne IPv6 einfordern und zusätzlich eine angemessene Frist zur Problembeseitigung setzen - das Androhen einer Vertragskündigung als Ultima Ratio verleiht der Sache vielleicht auch etwas Druck.

Hallo zusammen,

ich habe mich heute aufgrund meines Frustes mit der DG hier im Forum registriert und habe dasselbe "Phänomen", dass ich zwar eine IPv6 erhalte, allerdings keine Konnektivität habe.

Ich nutze eine Palo Alto PA-440 als Router. Ich hatte bis letztes Jahr Oktober keine Probleme mit meiner IPv6 Konnektivität. Irgendwann um diese Zeit ist mir dann aufgefallen, dass viele Websites (u.a. Google) in einen Timeout laufen. Nachdem ich die Websites (nach dem Timeout) aktualisiert habe, waren sie erreichbar. Niemand sonst hatte Probleme.. komisch.

Da ich aufgrund meiner Arbeit nur wenig Zeit hatte, habe ich mich mit dem Problem abgefunden und das Problem erst im Dezember begonnen zu analysieren.

Bei meinen Analysen ist mir aufgefallen, dass das Gateway der DG nicht auf Neighbor Solicitation Nachrichten reagiert und damit das DG Gateway nicht in die Neighbor Table aufgenommen wird. Das hat zur Folge, dass ich zwar eine IPv6 erhalte und eine Default-Route in die Routing Table aufgenommen wird, da allerdings das DG Gateway aus der Sicht der Firewall nicht existiert, werden auch keine Pakete an dieses weitergeleitet.

Das Einzige, was ich bei meiner PA-440 als Workaround machen kann, ist einen statischen Eintrag in die Neighbor Table hinzuzufügen (das geht natürlich nur so lange gut, wie sich die IP Adresse des DG Gateways nicht ändert).

Vielleicht hilft dir/euch diese Information?

Ergänzend: Ich bin seit Januar mit der DG am kämpfen, dass dieses Problem behoben wird, allerdings sind die höchstqualifizierten Techniker der DG der Meinung, dass kein Problem bestehen würde und schließen seither meine Tickets, ungeachtet der Packet Captures, die ganz klar das Gegenteil beweisen..

Zitat von DaSokas

Bei meinen Analysen ist mir aufgefallen, dass das Gateway der DG nicht auf Neighbor Solicitation Nachrichten reagiert und damit das DG Gateway nicht in die Neighbor Table aufgenommen wird.

Das ist ein wirklich guter Hinweis, der auch die anderen ähnlich gelagerten Problemfälle erklären könnte!

Das heißt: In deinen Paketmitschnitten an der Palo siehst du:

1. Solicited und unsolicited RA werden von der DG-Gegenstelle gesendet und kommen bei der Palo an?
2. Von der Palo gesendete NS werden hingegen von der DG-Gegenstelle nicht mit NA beantwortet?

Ein erhaltenes RA enthält als Option ja auch die zur (linklokalen) DG-Gateway-Adresse gehörende MAC-Adresse - sie sollte daher auf diesem Wege auch im Neighbor-Cache des WAN-Ports deiner Palo landen. Allerdings wird sie nach Ablauf der maximalen Cachedauer dort gelöscht. Schlecht, wenn die Cachedauer < mittlere Zeitdauer zwischen dem Erhalt zweier RA ist. Kannst du evtl. die Cachezeit des Neighbor-Caches hochdrehen? Z.B. auf die Router-Lifetime (siehe im RA, default: 1800s). Aber das wäre auch nur ein Workaround, nur etwas besser als ein statischer Eintrag im Neighbor-Cache.

Noch ein anderer Gedanke: ND-Pakete sind ja Pakete, bei denen ein Netzinterface selbst Quelle bzw. Ziel des Pakets ist. Bei einer Firewall (und so kenne ich es von einer Cisco ASA, weiß nicht wie es bei einer Palo ist) muss man daher ND-Pakete nicht als übliche FW-Passthrough-Regeln definieren, sondern durch einen gesonderten Satz interface-spezifischer host-based Regeln. Falls das bei einer Palo auch so geregelt ist, müsstest du mal kontrollieren, welche Regeln dort konfiguriert sind.

Zitat von DaSokas

Das Einzige, was ich bei meiner PA-440 als Workaround machen kann, ist einen statischen Eintrag in die Neighbor Table hinzuzufügen (das geht natürlich nur so lange gut, wie sich die IP Adresse des DG Gateways nicht ändert).

Das ist tatsächlich hochinteressant. Leider lassen sehr viele Heimrouter solche Einträge nicht zu. Da wäre jetzt die Frage, ob man die irgendwie faken oder spoofen kann, sodass die Router glücklich sind.

Ich habe die IPv6 Konfiguration gerade entfernt und nochmal neu erstellt, damit ich für diejenigen, die Interesse haben, einen Packet Capture bereitstellen kann.

Der Packet Capture ist auf jeglichen IPv6 traffic des WAN Interface beschränkt, weshalb der Ping vom LAN Interface auf die Google DNS Server (2001:4860:4860::8888) nicht zu sehen ist.

Zitat von ::1

Solicited und unsolicited RA werden von der DG-Gegenstelle gesendet und kommen bei der Palo an?

Ich sehe im Packet Capture lediglich unsolicited RA.

Zitat von ::1

Von der Palo gesendete NS werden hingegen von der DG-Gegenstelle nicht mit NA beantwortet?

Genau.

Ich habe aber gerade gesehen, dass die Palo sehr früh zwei NA vom DG Gateway erhält, die von der Firewall gedroppt werden. Ich vermute mal, dass das passiert, weil die Palo noch keinen ND gestartet hat und daher keine NA erwartet..

Alle späteren NS von meiner Palo werden vom DG Gateway nicht mehr beantwortet.

Zitat von ::1

Ein erhaltenes RA enthält als Option ja auch die zur (linklokalen) DG-Gateway-Adresse gehörende MAC-Adresse - sie sollte daher auf diesem Wege auch im Neighbor-Cache des WAN-Ports deiner Palo landen.

Ich möchte mich nicht zu weit aus dem Fenster lehnen, aber warum sollte der RA dazu führen, dass ein Eintrag im ND erstellt wird? Wenn ich den RFC 4861 richtig im Kopf habe, dann sind die RAs doch lediglich dafür da (salopp gesprochen) einen Router bekannt zu geben und dafür zu sorgen, dass Hosts sich eine IP generieren können.

Mal ein theoretisches Konstrukt: Ich könnte einen Router A nutzen um eine Route via Router B bekannt zu geben. Nur durch den RA weiß der Host aber nicht, ob Router B tatsächlich erreichbar ist, weshalb der Host per ND prüft, ob Router B tatsächlich erreichbar ist. Erst wenn sichergestellt ist, dass Router B existiert, wird der Eintrag der ND-Table hinzugefügt, oder nicht?

Edit: Ignorier den Schwachsinn von oben bitte, ich habe mir gerade nochmal RFC 4861 angeschaut und gesehen, dass ein RA die zwei Felder "Reachable Time" und "Retrans Timer" besitzt, mit denen konfiguriert werden kann wie lange der Router in der ND-Table als erreichbar markiert bzw. wann erneut NS versendet werden sollen.

Zitat von ::1

Noch ein anderer Gedanke: ND-Pakete sind ja Pakete, bei denen ein Netzinterface selbst Quelle bzw. Ziel des Pakets ist. Bei einer Firewall (und so kenne ich es von einer Cisco ASA, weiß nicht wie es bei einer Palo ist) muss man daher ND-Pakete nicht als übliche FW-Passthrough-Regeln definieren, sondern durch einen gesonderten Satz interface-spezifischer host-based Regeln.

Gute Idee, allerdings wäre mir das neu, dass man das bei der Palo explizit konfigurieren muss. Ich habe auch vor meiner Analyse im Dezember (bitte keine Steine werfen) kein Update meiner Palo durchgeführt.

Zitat von DaSokas

Ich habe aber gerade gesehen, dass die Palo sehr früh zwei NA vom DG Gateway erhält, die von der Firewall gedroppt werden. Ich vermute mal, dass das passiert, weil die Palo noch keinen ND gestartet hat und daher keine NA erwartet.

Ich denke mal, die Antwort liefert der erste Absatz von Chapter 7.2.5 in RFC4861:

7.2.5.  Receipt of Neighbor Advertisements
   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.

Ich kann in deinem Packet Capture ansonsten keine Auffälligkeiten erkennen. Es bestätigt lediglich erneut, dass die DG-Gegenstelle keine (solicited) NA auf die sekündlich von der Palo gesendeten NS zurück schickt.

Zitat von ::1

Ich kann in deinem Packet Capture ansonsten keine Auffälligkeiten erkennen. Es bestätigt lediglich erneut, dass die DG-Gegenstelle keine (solicited) NA auf die sekündlich von der Palo gesendeten NS zurück schickt.

So blöd das auch klingen mag, freut mich das zu hören. Dann scheine ich, auch wenn ich einige Details zum RFC4861 nicht mehr korrekt im Kopf hatte, zumindest mit meiner Schlussfolgerung, dass der Fehler wahrscheinlich nicht bei mir liegt, nicht ganz falsch zu liegen.

Vielen Dank!

Zitat von DaSokas

zumindest mit meiner Schlussfolgerung, dass der Fehler wahrscheinlich nicht bei mir liegt,

Das würde ich auch so sehen. Aber ja, lieber einmal mehr hinschauen, um diese Wahrscheinlichkeit zu erhöhen.