Bisher bin ich davon ausgegangen, dass die Telekom als ausgewachsener Carrier im Jahr 2018 bereits ausreichend Erfahrung mit IPv6 gesammelt hat. Und dass die Telekom Routing-Fehler in ihrem Netz mittels vorhandener Tools schnell und effizient beheben kann. Weit gefehlt.<\/p>\n
Ein Kunde hatte die letzten drei Jahre als Glasfaser Internetanschluss „Company Connect 34MBit“ f\u00fcr 899\u20ac\/Monat am laufen, inklusive IPv6 Netz in der Gr\u00f6\u00dfe \/48, was auch funktionierte.<\/p>\n
Nun kam es dazu, dass der Anschluss zu „DeutschlandLAN Connect IP“ 100Mbit (f\u00fcr knapp 800\u20ac\/Monat) umgeschaltet wurde. Neue Glasfaser beleuchtet, Router und Netzabschluss ausgetauscht, Routen auf die neue Schnittstelle umgeschaltet. IPv4-Netze sind nach dem Umschalten nach ein paar Minuten da, es scheint alles ok soweit. IPv6 an der WAN-Schnittstelle ist\u00a0 erreichbar, sieht auch gut aus.<\/p>\n
Nebenbei wurden die Firewalls beim Kunden hochgepatcht, weil ein Update verf\u00fcgbar war.<\/p>\n
Nun kam es jedoch, dass interne Rechner nicht mehr per IPv6 ins gro\u00dfe weite Netz kamen, pings endeten an der Firewall. Lange doktere ich herum, verfluche die Firewall, die letztendlich unschuldig war. Pings funktionieren von A nach B, von B nach C, aber nie von A nach C. Wobei B die Firewall ist. TCPDump zeigt auch, dass Pakete rausgehen, aber nicht zur\u00fcck kommen. Ich suche nach dem Fehler, warum die IPv6 Paket an der WAN-Schnittstelle gar nicht erst zu sehen sind,\u00a0 w\u00e4hrend Pings, die von der Firewall selbst abgesetzt werden, einwandfrei zur\u00fcck kommen. Ich bin erstmal ratlos. Von dem \/48 Netz nutze ich als Transfernetz zwischen Telekom-Router und der Kunden-Firewall allerdings nur ein \/64-Netz. Und genau dieses ist auch erreichbar. Es kann nur noch eine Erkl\u00e4rung f\u00fcr das Ph\u00e4nomen geben: Die Ursache muss extern liegen.<\/p>\n
Alles deutet darauf hin, dass nur noch ein \/64 geroutet wird, die Firewall ist au\u00dfen erreichbar, nicht jedoch dahinter liegende Netze. Anruf bei der Telekom Business-Hotline. Der Mitarbeiter best\u00e4tigt, dass irgendetwas faul ist, ich soll den Fall per Email schildern. Schreibe Email an die Telekom mit detaillierter Beschreibung.<\/p>\n
Sehr geehrte Damen und Herren,<\/p>\n
wir bitten um \u00dcberpr\u00fcfung der IPv6-Konnektivit\u00e4t auf dem \/48-Netz [2003:58:802A:0:0:0:0:0].
\nSeit Umstellung der Leitung auf DeutschlandLAN Connect IP kann nur noch das \/64 Netz (z.B. [2003:58:802A::8] erreicht werden. „Dahinter“ liegende Netze werden ab Router [2003:0:8400:e800::1] nicht weiter geleitet.
\nZum Testen l\u00e4uft IP:[2003:58:802A:2:250:56af:fea7:8e7c], welcher per ICMPv6 erreichbar sein sollte.<\/p><\/blockquote>\nEs folgt gegen 17:30 Uhr ein Anruf der Business-Hotline. Der Mitarbeiter gibt zu Wort, dass das Problem in der Tat so best\u00e4tigt werden kann. Leider k\u00f6nne er die Routen derzeit nicht korrigieren, da die ben\u00f6tigten Tools (noch) nicht zu Verf\u00fcgung st\u00e4nden. Wir sollten eine \u00c4nderungsauftrag \u00fcber den entsprechenden Vertriebsmitarbeiter eingeben.<\/p>\n
Ich schicke die Email mit erweiterter Erkl\u00e4rung an unseren Vertrieb’ler und seinen Mitarbeiter im Office. Mir schwant schon, dass das eine l\u00e4ngere Sache wird, da ich von Vertrieb’lern bisher wenig zufriedenstellende Antworten bekommen habe. Die Antwort kommt prompt in Form einer fehladressierten Emaill, die eigentlich an den Vertrieb’er gehen sollte:<\/p>\n
Hallo Cheffe,<\/p>\n
ist dir bekannt, was hier zu tun ist?
\nSo ein Thema hatte ich noch nicht.<\/p><\/blockquote>\nDa IPv6 gl\u00fccklicherweise nicht gesch\u00e4ftskritisch ist und die IPv4-Netze funktionieren, lasse ich dem Vertrieb freundliche drei Tage Zeit, bis ich per Anruf nachharke. Der Vertriebsmitarbeiter, h\u00f6rbar bem\u00fcht, m\u00f6chte seinerseits nachharken. Mich erreicht eine Information, die „IP-Adress\u00e4nderung sei \u00fcber den Innendienst angewiesen“.
\n<zyn on>Wie ab die doch gehen.<zyn off><\/p>\nF\u00fcnf Tage sp\u00e4ter ist alles noch beim Alten. Zur Abwechslung rufe ich wieder die Business-Hotline an. Die Dame am andere Ende der Leitung ruft sich den Fall auf und entscheidet sofort, die Angelegenheit an ihren Kollegen weitergeben zu m\u00fcssen, er wird sind melden.
\nAm n\u00e4chsten Tag erreicht mich morgens folgende Email:<\/p>\nbei der \u00dcbernahme von Company Connect (CoCo) auf Deutschland LAN IP (DCIP) ist auf dem RD eine statische Route vergessen worden.
\nDiese Route wurde nun im RD-Profil zugef\u00fcgt.<\/p>\nSollten Sie in einer verkehrs-schwachen-Zeit Ihren RD neu starten, sollte die IPv6-Connectivity wie gewohnt funktionieren.<\/p>\n
Ich m\u00f6chte Sie jedoch bitten, sich an Ihren vertrieblichen Ansprechpartner zu wenden und \u00fcber ihn, einen Korrekturauftrag (IP-Adressauftrag einzustellen).<\/p>\n
Ich w\u00fcnsche Ihnen noch eine angenehme Restwoche und verbleibe mit freundlichen Gr\u00fc\u00dfen<\/p><\/blockquote>\n
Aha, aha. Professionell wurden Abk\u00fcrzungen f\u00fcr die Produktnamen in Klammern eingef\u00fcgt (wozu?), aber RD nicht erkl\u00e4rt. Gl\u00fccklicherweise ist aus dem Kontext ableitbar, dass es sich um unseren Telekom-Router handeln muss. Aber was um Himmels willen soll ich mit dem letzten Absatz anfangen? Klappt’s nun, wenn die den Router neu starte, oder soll ich nun wiederholt einen IP-Korrekturauftrag an den vertrieblichen Ansprechpartner stellen? Und wenn ja, warum?<\/p>\n
Ich w\u00e4hle wieder die Hotline-Nummer. Wer logisch inkonsistente Informationen sendet, darf sich gerne erkl\u00e4ren.
\nDer Mitarbeiter am Telefon ist gleich im Bilde – noch bevor ich unsere Kundennummer nennen darf. Ich bin verbl\u00fcfft. \u00dcblicherweise darf ich erstmal alles erkl\u00e4ren, unsere Kundennummer nennen, ggf. ein Password und noch eine Leitungsbezeichnung, um dann drei mal hin- und herverbunden zu werden und stets die selbe „Geschichte“ von Neuem zu erz\u00e4hlen. Und dieser Mitarbeiter wei\u00df sofort bescheid.
\nIch frage nach dem tieferen Sinn, speziell des letzten Absatzes in der letzten Email. Er best\u00e4tigt, dass man das nicht so ganz verstehen kann. Aber letzten Endes m\u00fcsse diese „quick&dirty“-\u00c4nderung noch dokumentiert werden, und daf\u00fcr sei wiederum der Vertrieb zust\u00e4ndig. Ich erspare ihm meine Frage, warum ICH das nun machen solle, denn die Antwort kann ja eigentlich nur lauten: „weil wir’s einfach nicht drauf haben“.
\nIch erkundige mich allerdings noch danach, ob die \u00c4nderung in unserem Telekom-Router ausreiche, da meine Diagnose darauf hindeute, dass die Route auch im tiefer liegenden Netz korrigiert werden m\u00fcsse. Die Antwort f\u00e4llt wie erwartet aus: „Das sehe man ja dann, wenn es immer noch nicht funktioniere“.<\/p>\nF\u00fcr 21 Uhr habe ich von entfernt \u00fcber das Outlet-Segment der USV, an welcher der Router h\u00e4ngt, einen Hard-Reset programmiert. Nachdem die Internetverbindung wieder online war, funktionierte IPv6 tats\u00e4chlich wieder im kompletten \/48-Raum.<\/p>\n","protected":false},"excerpt":{"rendered":"
Bisher bin ich davon ausgegangen, dass die Telekom als ausgewachsener Carrier im Jahr 2018 bereits ausreichend Erfahrung mit IPv6 gesammelt hat. Und dass die Telekom Routing-Fehler in ihrem Netz mittels vorhandener Tools schnell und effizient beheben kann. Weit gefehlt. Ein Kunde hatte die letzten drei Jahre als Glasfaser Internetanschluss „Company Connect 34MBit“ f\u00fcr 899\u20ac\/Monat am … <\/p>\n