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ür 899€/Monat am laufen, inklusive IPv6 Netz in der Größe /48, was auch funktionierte.
Nun kam es dazu, dass der Anschluss zu „DeutschlandLAN Connect IP“ 100Mbit (für knapp 800€/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 erreichbar, sieht auch gut aus.
Nebenbei wurden die Firewalls beim Kunden hochgepatcht, weil ein Update verfügbar war.
Nun kam es jedoch, dass interne Rechner nicht mehr per IPv6 ins große 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ück kommen. Ich suche nach dem Fehler, warum die IPv6 Paket an der WAN-Schnittstelle gar nicht erst zu sehen sind, während Pings, die von der Firewall selbst abgesetzt werden, einwandfrei zurück 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ärung für das Phänomen geben: Die Ursache muss extern liegen.
Alles deutet darauf hin, dass nur noch ein /64 geroutet wird, die Firewall ist außen erreichbar, nicht jedoch dahinter liegende Netze. Anruf bei der Telekom Business-Hotline. Der Mitarbeiter bestätigt, dass irgendetwas faul ist, ich soll den Fall per Email schildern. Schreibe Email an die Telekom mit detaillierter Beschreibung.
Sehr geehrte Damen und Herren,
wir bitten um Überprüfung der IPv6-Konnektivität auf dem /48-Netz [2003:58:802A:0:0:0:0:0].
Seit 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.
Zum Testen läuft IP:[2003:58:802A:2:250:56af:fea7:8e7c], welcher per ICMPv6 erreichbar sein sollte.
Es folgt gegen 17:30 Uhr ein Anruf der Business-Hotline. Der Mitarbeiter gibt zu Wort, dass das Problem in der Tat so bestätigt werden kann. Leider könne er die Routen derzeit nicht korrigieren, da die benötigten Tools (noch) nicht zu Verfügung ständen. Wir sollten eine Änderungsauftrag über den entsprechenden Vertriebsmitarbeiter eingeben.
Ich schicke die Email mit erweiterter Erklärung an unseren Vertrieb’ler und seinen Mitarbeiter im Office. Mir schwant schon, dass das eine längere 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:
Hallo Cheffe,
ist dir bekannt, was hier zu tun ist?
So ein Thema hatte ich noch nicht.
Da IPv6 glücklicherweise nicht geschäftskritisch ist und die IPv4-Netze funktionieren, lasse ich dem Vertrieb freundliche drei Tage Zeit, bis ich per Anruf nachharke. Der Vertriebsmitarbeiter, hörbar bemüht, möchte seinerseits nachharken. Mich erreicht eine Information, die „IP-Adressänderung sei über den Innendienst angewiesen“.
<zyn on>Wie ab die doch gehen.<zyn off>
Fünf Tage später 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üssen, er wird sind melden.
Am nächsten Tag erreicht mich morgens folgende Email:
bei der Übernahme von Company Connect (CoCo) auf Deutschland LAN IP (DCIP) ist auf dem RD eine statische Route vergessen worden.
Diese Route wurde nun im RD-Profil zugefügt.Sollten Sie in einer verkehrs-schwachen-Zeit Ihren RD neu starten, sollte die IPv6-Connectivity wie gewohnt funktionieren.
Ich möchte Sie jedoch bitten, sich an Ihren vertrieblichen Ansprechpartner zu wenden und über ihn, einen Korrekturauftrag (IP-Adressauftrag einzustellen).
Ich wünsche Ihnen noch eine angenehme Restwoche und verbleibe mit freundlichen Grüßen
Aha, aha. Professionell wurden Abkürzungen für die Produktnamen in Klammern eingefügt (wozu?), aber RD nicht erklärt. Glücklicherweise 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?
Ich wähle wieder die Hotline-Nummer. Wer logisch inkonsistente Informationen sendet, darf sich gerne erklären.
Der Mitarbeiter am Telefon ist gleich im Bilde – noch bevor ich unsere Kundennummer nennen darf. Ich bin verblüfft. Üblicherweise darf ich erstmal alles erklären, 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ählen. Und dieser Mitarbeiter weiß sofort bescheid.
Ich frage nach dem tieferen Sinn, speziell des letzten Absatzes in der letzten Email. Er bestätigt, dass man das nicht so ganz verstehen kann. Aber letzten Endes müsse diese „quick&dirty“-Änderung noch dokumentiert werden, und dafür sei wiederum der Vertrieb zuständig. 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“.
Ich erkundige mich allerdings noch danach, ob die Änderung in unserem Telekom-Router ausreiche, da meine Diagnose darauf hindeute, dass die Route auch im tiefer liegenden Netz korrigiert werden müsse. Die Antwort fällt wie erwartet aus: „Das sehe man ja dann, wenn es immer noch nicht funktioniere“.
Für 21 Uhr habe ich von entfernt über das Outlet-Segment der USV, an welcher der Router hängt, einen Hard-Reset programmiert. Nachdem die Internetverbindung wieder online war, funktionierte IPv6 tatsächlich wieder im kompletten /48-Raum.