DIe Daumenregel ist: 1 Millisekunde RTT reichen fuer 100 Km Signallaufzeit in Glasfaser (also hin und zurueck), wobei aktive Netzwerk-Hops oft selber noch ein paar Millisekunden zusaetzlich benoetigen. D.h. 1000 km machen etwa 10 Millisekunden RTT aus.
Bei O2 sehe ich i.d.R. etwa 8-9 ms von Hamburg/Ahrensburg nach Frankfurt am Main/Offenbach, ich weiss aber nicht wie die Kabelstrecken da genau verlaufen, also wie lang der eigentliche Weg ist..
Was fuer einen Router hast Du denn und was fuer ein ONT? Ich wuerde als Test immer die Desktop-App von breitbandmessung.de empfehlen und deren Messanweisungen befolgen. Ich wuerde auch ueberlegen schon mal mit einer Messkampagne an zu fangen, eine abgeschlossene Messkampagne die eine Minderleistung bescheinigt kann helfen den Support darauf zu fixieren Probleme zu diagnostizieren und zu beheben.
Frage, taucht FFM da in traceroutes zu Zielen in HH auf, oder wird das alles so getunnelt, dass der "Umweg" ueber FFM auf L3 gar nicht sichtbar wird?
Das mag pragmatisch richtig sein freundlich und hartnaeckig zu bleiben, fair ist es nicht. Ich wette die DG wird, wenn der Kunde seinen vertraglichen Pflichten nicht nachkommt (z.B. monatliche Zahlungen), das Ganze auch schnell eskalieren.
Mein Beef ist hier nicht, dass es zu Problemen kommt oder, dass deren Loesung laenger dauert, sondern die komplett fehlgeleitete Unternehmenskommunikation der DG in dieser Sache (wenn die Technik um das Problem weiss und in Hintergrund an dessen Loesung arbeitet) oder vielleicht auch die mangelnde technische Kompetenz (wenn die Technik gar nicht weiss, dass da bei manchen Kunden einiges schieflaeuft).
Wenn man das TKG wörtlich auslegt, dann ist das so. Die Formulierung aus der EU Verordnung oben hat es nicht ins TKG geschafft.
Ist egal, her dier Anfang des Wikipedia Artikels zu EU Verordnungen:
Eine Verordnung der Europäischen Union, kurz EU-Verordnung (amtliche Kurzform Verordnung (EU)), ist ein Rechtsakt der Europäischen Union mit allgemeiner Gültigkeit und unmittelbarer Wirksamkeit in den Mitgliedstaaten. Die Verordnungen sind Teil des Sekundärrechts der Union. Sie unterscheiden sich von Richtlinien hauptsächlich dadurch, dass letztere erst von den Mitgliedstaaten in nationales Recht umgewandelt werden müssen, um wirksam zu werden. EU-Verordnungen haben gegenüber den nationalen Gesetzen der Mitgliedstaaten einen Anwendungsvorrang.
Aber Recht haben und Recht bekommen sind zwei paar Stiefel. UND das was da momentan bei manchen DG Kunden mit IPv6 passiert ist ja nicht im Sinne der DG (kann nicht erkennen wie verranzte IPv6-Provisionierung lukrativ fuer die DG sein koennte).
Wie ::1 andeutet ist das aktuelle Problem wohl der 1st Level Support an dem man erst mal vorbei kommen muss bevor die Fehlermeldung vielleicht mal bei der richtigen Fachabteilung landet.
Das mit dem Support ist aber auch bei anderen ISP aehnlich, auch wenn die Telekom wohl ein eigenes Social Media Team unterhaelt die sich um heikle Faelle kuemmern die in Social Media Seiten aufgebracht werden, und die den 1st Level Support augenscheinlich ueberspringen koennen. (Im O2 Forum machen das die offiziellen O2 Moderatoren auch, allerdings auf etwas kleiner Flamme).
Ah, BGP.tools listet auch nur Level3 und Cogent als Upstreams (AS37468 nur als Peer)
Netservices hat folgende Provider:
AS3356 (Lumen/Level3)
AS174 (Cogent)
AS37468 (Angola-Cables) (nur )
und peert am DE-CIX (wohl nur IPv6) (100G in FFM, 40G in HH)
und peert mit AS6461 (Zayo)
Das sieht fuer mich jetzt nicht erkennbar problematisch aus... (Cogent Multi-Homed ist so weit ich weiss OK)
Die DG kriegt hier viel ab, ist aber grundsätzlich auch in der Lage, funktionierendes Internet abzuliefern, Manchen jahrelang ohne Unterbrechung.
Wenn den Berichten hier im Forum folgt, dann baut die DG moeglicherweise ihre IPv6 Provisionierung gerade um, und das ist wohl von einigen "Kinderkrankheiten" betroffen. Das fuer sich alleine waere IMHO nicht so wild, wo gehobelt wird, da fallen halt Spaene, aber das ganze wird nicht kommuniziert und der Kundenservice weiss davon auch nichts und scheint dahef fuer Betroffene eher absurdes Theatef zu sein, denn Hilfe. Aber ich vrmute frueher oder spaeter kriegen die das auch hin und dann laeuft es auch bei den Endkunden.
Also "fe80::*" wird niemals via DHCPv6 angeboten.
Erm, das ist nicht die Adresse/Prefix das zugewiesen wurde sondern das ist das Prefix von dem die DHCPv6 Antwort (dhcp6 advertise) versendet wurde als Antwort auf das dhcp6 solicit des Heim-Gareways. Hier ein Beispiel:
12:15:41.058909 IP6 (flowlabel 0x2d3e1, hlim 1, next-header UDP (17) payload length: 109) fe80::251e:31a:f3a4:a2ba.546 > ff02::1:2.547: dhcp6 solicit (xid=15d7ae (elapsed-time 65535) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 3a146014ec49) (reconfigure-accept) [|dhcp6])
12:15:41.081639 IP6 (hlim 255, next-header UDP (17) payload length: 177) 0:80fe::ae99:29ff:fe6e:30e2.547 > fe80::251e:31a:f3a4:a2ba.546: dhcp6 advertise (xid=15d7ae (client-ID hwaddr type 1 3a146014ec49) (server-ID hwaddr/time type 1 time 766106055 ac99296e30e2) (preference 0) [|dhcp6])
12:16:05.729183 IP6 (flowlabel 0x2d3e1, hlim 1, next-header UDP (17) payload length: 109) fe80::251e:31a:f3a4:a2ba.546 > ff02::1:2.547: dhcp6 solicit (xid=6e0163 (elapsed-time 0) (option-request SIP-servers-domain SIP-servers-address DNS-server DNS-search-list SNTP-servers NTP-server AFTR-Name opt_67 opt_94 opt_95 opt_96 opt_82) (client-ID hwaddr type 1 3a146014ec49) (reconfigure-accept) [|dhcp6])
12:16:05.751160 IP6 (hlim 255, next-header UDP (17) payload length: 177) 0:80fe::ae99:29ff:fe6e:30e2.547 > fe80::251e:31a:f3a4:a2ba.546: dhcp6 advertise (xid=6e0163 (client-ID hwaddr type 1 3a146014ec49) (server-ID hwaddr/time type 1 time 766106055 ac99296e30e2) (preference 0) [|dhcp6])Es geht um 0:80fe::ae99:29ff:fe6e:30e2.547 , meine Firewall war so eingestellt, dass aus diesem Bereich keine DHCPv6 Pakete akzeptiert wurden.
Lustigerweise ist fe8000 in little-endian gleich 000080fe. Das ganze wurde letztlich in Kooperation mit einem ungenannten Ausruester in dessen Software gefixt... mein Verdacht ist, dass es sich dabei um Huawei handelt (basierend auf MAC Adressen) aber sicher bin ich da nicht.
Da ich es ja hier angerissen habe, hier ein Link zum Thread im O2 Forum (ich hoffe das ist OK andere Fora von hier zu verlinken).
O2 macht IPv4 via PPPoE und dann IPv6 ueber DHCPv6. Ja die haben auch gelegentlich mal Probleme (z.B. Anfang des Jahres als die DHCP Antwort von Prefix 0:80fe:: kam statt des erwarteten Prefix fe80:: *) aber insgesamt passt da die Zuweisung der Adressen.
Ich bin kein PPPoE Fan, wegen der relativ hohen Kosten fuer's Ver- und Ent-Tunneln, aber ich bin ein Fan von zuverlaessiger Adresszuteilung, und habe da die Praeferenz erst zuverlaessig, dann effizient. 
*) Das ist per se nicht "verboten" aber nicht im Sinne der relevanten RFCs weshalb Firewalls wohl oft nur den RFC Bereich fc00::/6 fuer DHCPv6 zulassen.
Die Vorgaben der EU Verordnung 2015/2120 sind:
Artikel 3
Gewährleistung des Zugangs zum offenen Internet
(1) Endnutzer haben das Recht, über ihren Internetzugangsdienst, unabhängig vom Standort des Endnutzers oder des Anbieters und unabhängig von Standort, Ursprung oder Bestimmungsort der Informationen, Inhalte, Anwendungen oder Dienste, Informationen und Inhalte abzurufen und zu verbreiten, Anwendungen und Dienste zu nutzen und bereitzustellen und Endgeräte ihrer Wahl zu nutzen.
Das geht halt nur mit oeffentlich erreichbaren Adressen (bzw. beschraenkt auch mit CG-NAT mit PCP). Das Problem ist bei uns eher, dass die BNetzA sich da nicht fuer zustaendig haelt und nur begrenzt auf ISPs einwirkt. Dabei ist es IMHO egal wie viele der Internetnutzer das brauchen, das ist eigentlich Bestandteil den Produktes "Internetzugang". Aber mein ISP hat da keine Probleme mit und bietet dynamische oeffentliche IPv4 und IPv6 Adressen... ich wuerde auch bei FTTH, wenn denn die Wahl besteht, einen kompetenten ISP mit echtem "Internetzugang" nehmen.
Erst wenn man das Netz selbst betreibt steht man im Wettbewerb.
Mei, klar ist das noch besser, aber z.B. Reseller auf L2/Ethernetebene koennten der DG zeigen wie man IPv4 und vor allem IPv6 robust und zuverlaessig provisioniert... das geht auch mit Bitstromzugang.
Wobei es fuer Wettbewerber/Reseller der DG ja wohl reichen sollte um Kunden zu gewinnen eine IPv6 Konfiguration zu bieten, die tatsaechlich zuverlaessig nutzbar ist... als wollte die DG da den Acker fuer die Wettbewerber vorbereiten.
Auf mein Angebot zeitweise einen DG-Router zu leihen ist mit Behauptung, dass diese mindestes für 1 Jahr geliehen werden soll und die Kündigung nachher nicht einfach ist, abgelehnt
Das waere allerdings ein interessanter Test, ob IPv6 mit den DG Routern an betroffenen Anschluessen funktioniert oder nicht. Ich kann allerdings verstehen, dass Du fuer diesen Datenpunkt selber keine grossen Investitionen taetigen willst.
Sieht so aus als haengst Du (und viel andere) da am ersten Mini-Boss fest, beim Versuch das 1st-Level-Support Level zu verlassen. Ich kenne leider niemanden bei der DG in de Technik, aber ich vermute das eigentliche Problem sollte loesbar sein, wenn denn erstmal die richtigen Leute darauf hingewiesen wuerden.
Persoenlich wuerde ich versuchen Verbraucherschutz und Bundesnetzagentur mit ins Boot zu holen, auch wenn ich von der BNetzA hier leider nicht mehr erwarte als dass sie Dein Anliegen versuchen wird abzuwiegeln.
Ja, hier im Forum gibt es einige die von solchen Eskalationsschritten abraten, weil diese eine Loesung noch weiter verzoegern koennten, aber der Thread ist vom Januar und geloest ist das Problemfeld IPv6 bei der DG offensichtlich immer noch nicht, und es gibt auch keine Anzeichen, dass an einer Loesung gearbeitet wird.
- Der HÜP ist gleichzeitig auch der passive Abschluss, da bewusst auf die abschließbare Variante verzichtet wurde; damit kann ich gut leben
Ein Steckeruebergang weniger... warum auch nicht.
- Interessant: net services fährt wohl einen 1:16 Split (wobei ich das ohnehin sehr gelassen bleibe, Statistik und so)
Waehrend ich grosser Freund der PtP-Netzstruktur bin und diese klar fuer zukunftsfester halte als PtMP ist mir PON oder AON eher weniger wichtig: ein kompetenter ISP kann auch mit PON zufriedenstellende Leistungen bieten und ein inkompetenter ueber AON Gruetze abliefern.
- Auch liefert der LAN-Port noch nichts, wobei ich nur ohne VLAN und auch Verdacht VLAN 7 probiert habe
Mmmh, das heisst es gibt da keine Informationsseite auf dem ONT die man ueber eine "magische" IP (bei DOCSIS legt der Standard dafuer mEn 192.168.100.1 fest) erreichen kann? Waere schade aber verschmerzbar (wenn der ISP kompetent ist).
Ich wuerde in solchen Faellen immer auch eine Messkampagne mit der Desktop-App von breitbandmessung.de machen. Ich wuerde aber auch gucken ob das am eigenen Router und dessen Konfiguration liegen koennte... wenn der eigene Router unauffaellig ist aber das Messprotokoll Minderleistung bescheinigt wuerde ich mich damit an den ISP wenden. Selbst wenn man weder ausserordentliches Kuendigungs- oder Minderungsrecht erwirken will*, haben solche offiziellen Messwerte hoeheres Gewicht und koennen helfen den Kundenservice zu fokussieren.
*) Ich neige dazu, in solchen Faellen erstmal mit dem ISP zusammen zu arbeiten und ihm die Moeglichkeit zur Diagnose und Abhilfe zu geben, aber das ist Geschmacksache, laut TKG kann man auch direkt mit der Tuer ins Haus fallen und eine Minderung fordern.
Ich sehe kein Gerät mit der genannten MAC-Adresse und auch keine MAC-Adresse auf dem SFP selbst, Nokia ist aber auf einem von den Screenshots zu lesen und ich denke, dass das den SFP ist.
Das ist die ISP Seite, also der OLT der als Nokia identifiziert wird.
Na ja, das mit "Nokia" kommt aus dem OUI Lookup von Wireshark fuer die MAC Adresse 80:b9:46:f0:0d:32, aber ob diese MAC auch tatsaechlich in Lukis Fall einem Nokia-ONT zugeordnet ist, ist eine andere Frage. Vielleicht ist das ja auh eine Antwort von ein Nokia-OLT oder BNG
Ich kann das gerade nicht testen, aber auf der Windowsmaschine was ist die Ausgabe von:
route printWähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum