Anstelle von technischen Details heute mal ein Erfahrungsbericht. Vielleicht sollte ich eher sagen: ein Odysseebericht. Für einen meiner Kunden habe ich den Business-Internetanschluss umgezogen. “Einfache Sache”, so dachte ich anfangs, zumal der alte und neue Anschluss beide bei dem gleichen Anbieter liegen: der Telekom. Von einem “Company Connect” der T-Systems (ok, doch nicht exakt Telekom) hin zu einem DeutschlandLAN Connect IP.
Es war fürchterlich:
Es sollte von einer 34 Mbit/s Leitung (Kupfer, ging nicht mehr schneller) zu einem 100 Mbit/s Anschluss via Glasfaser gehen. Vom Prinzip also eine gute Sache. DeutschlandLAN Connect IP. “Höchste Verfügbarkeit und optimaler Service rund um die Uhr”. Ist klar!
Hier eine Auflistung der Fehler/Probleme, welche die Telekom während dem ganzen Prozess dabei begangen hat. Und um es noch mal ganz klar zu sagen: Es ging hier um einen Business-Anschluss, bei dem eine ganze Firma dahinter hing. (Also nicht nur ein einfaches DSL für zu Hause.)
- Fehler: IP Netze können nicht (ohne weiteres) mit umgezogen werden: Da fing der Ärger schon an. Der Kunde ist vorher Dual-Stack angebunden gewesen, also IPv6 und IPv4. Über mehrere statische IP-Adressen sind Services im Internet verfügbar, Site-to-Site VPNs werden aufgebaut, Zugriffsregeln (eingehend und ausgehend) mit IP-Beschränkungen versehen. Was würde also mehr Sinn machen, als die IP-Adressen einfach zum neuen Anschluss mit umzuziehen? Ging leider nicht, da die Anschlüsse unter verschiedenen Kundennummern bei der Telekom registriert wurden und eine Änderung mindestens 6 Wochen in Anspruch genommen hätte. Diese Zeit hatte der Kunde leider nicht.
- Fehler: Zu kleines IPv4 Netz: Der Kunde hatte neben einem /48er IPv6-Präfix ein /27er IPv4-Netz. Beim neuen Anschluss war aber zunächst nur von einem /29er die Rede. Von Beginn an wurde kommuniziert, dass der Kunde auch wieder ein /27er braucht. Ging aber in den Akten unter. Doch dies war nur die erste Verzögerung:
- Fehler: Größeres IPv4 Netz am Schaltungstermin nicht verfügbar: Dann kam zwar die Zusage, dass ein /27 ebenfalls zum Anschluss gerouted werden wird, aber am kommunizierten Schaltungstermin war es noch nicht verfügbar. Die Planung für eine reibungslose Umstellung musste also verworfen werden. Sehr nervig, zumal mehrere Parteien mit im Boot waren und man extra einen Samstag dafür freigehalten hatte, um möglichst wenig Ausfall an den Arbeitstagen zu haben.
- Fehler: IPv6 Routing am Tag der Umstellung nicht verfügbar: Am zweiten angesetzten Umstellungstermin ein paar Tage später war zwar das /27er IPv4-Netz verfügbar, nicht aber die ebenfalls von Beginn an kommunizierten IPv6-Routen. Während der Internetanschluss also lief, mussten notgedrungen einige Services auf IPv4 ausweichen, was bei teilweise vorhandenen IPv6-only Diensten (intern) gar nicht möglich war!
- Fehler: IPv6 Routing falsch umgesetzt -> Ausfall der gesamten Internetverbindung inkl. IPv4! Haha, jetzt kommt der Knaller: Als die Telekom die IPv6-Routen dann endlich konfiguriert hatte, haben sie sich in der Schreibweise der IPv6 Next-Hop Adressen vertan. Die offizielle PDF mit den Adressdetails hatte diese falsch gelistet. (Da die Telekom die Abkürzungsregel mit den zwei aufeinanderfolgenden Doppelpunkten nicht nutzt, müssen stets alle 8 Hextetts angegeben werden. Ich hatte die IPv6-Adressen wie gewohnt gekürzt übermittelt
2001:db8:abcd::4 und irgendein Depp hat es nicht geschafft, daraus die vollständige IPv6-Adresse zu extrahieren. Es wurden anstatt 8 Hextetts einfach nur 7 aufgeschrieben:
2001:db8:abcd:0:0:0:4 . Richtig wäre folgende Adresse gewesen:
2001:db8:abcd:0:0:0:0:4 .) Die Folge war, dass nach einem Reboot des Routers der Telekom jener nur noch rot blinkte und der gesamte Internetanschluss tot war! Und das für mehrere Stunden während eines Arbeitstages! Dass man sich mit der Schreibweise einer IPv6 Adresse mal vertut kann ich ja noch verstehen. Vor allem wenn man mit Netzgrößen zwischen /32, /48, /56 und /64 jongliert. Dass man bei der Telekom aber
- keine Eingabe-Validierung im Konfigurationssystem VOR der Installation in einen Router und
- keine Validierung WÄHREND der Installation in den Router nutzt, was dann
- zum Komplettausfall des Routers führt, kann ich nicht wirklich verstehen! Sinnvoll wäre eine automatische Varianta à la “wenn der Router nicht hochkommt nimm die letzte funktionstüchtige Konfiguration”. Aber das wäre ja auch schlau.
Au man ey. Es ist leider nicht das erste Mal, dass ich bei einem ISP Aufklärungsarbeit in Sachen IPv6 leisten muss. ;( Beispielsweise ist auch die PDF “Technische Informationen zur IP-Adressvergabe” an einer Stelle falsch. Beim Standard-Gateway (Typ: Interface) wird bei IPv4 korrekterweise von der ersten IP im Subnetz /27 gesprochen. Bei IPv6 ist zwar ebenfalls die erste IP Adresse (prefix::1) genannt, allerdings als /48. Ich hoffe doch sehr, dass am Interface ein /64 anliegt und nicht das komplett geroutete /48!
Nunja, nachdem am darauffolgenden Tag dann ein kompetenterer Telekom Mitarbeiter die IPv6-Routen händisch in den Router (übrigens ein Adtran NetVanta 4660) und in deren Konfigurationssystem eingetragen hat, lief es dann endlich alles. Puh, hat ja auch nur mehrere Wochen (und für mich: Nächte) gedauert. Vollpfosten!
Ich weiß, Blogposts wie diese sind nicht gerade die Seltenheit. Oder auch Artikelserien wie “Vorsicht, Kunde” der c’t sind ja teils legendär. Insofern dürfte ich hier kaum jemanden etwas Neues erzählen. Es war mehr für mich aber ein weiteres Mal eine nervige Erfahrung und ich wollte irgendwo Druck ablassen. ;) Insofern: Danke fürs Zuhören.
Featured image “Telekom-Baustelle” by Klaus Tenter is licensed under CC BY 2.0.
Hi,
kann ich nur zu gut verstehen. Daher machen wir immer eine übergangsfrist beim Umzug von ISP von mindestens 3Monaten.
So kann man nach und nach Side-to-side anbindungen testen (zu unternehmen unkritischen Zeitpunkten) etc.
Und deshalb baut für sich wichtige wichtige Anschlüsse parallel auf. Und ja dann muss man an den Gateways die Konfiguration ändern, aber die hat man ja hoffentlich selbst im Griff. Aber dafür gibt es dann auch ein failback Weg.
Hier kommt noch ein Kracher: Company Connect wird eingestellt. Daher wird man nun vor die Wahl gestellt: Internet wird abgeschaltet oder ein neuer Connect IP Anschluss bereitgestellt – Kosten in Höhe von rund 4.000 € sind vom Kunden zu tragen.