Sophos Firewalls können kein DHCPv6-PD

Zugegebenermaßen, es betrifft nicht jeden. Aber es ist totzdem dramatisch, wenn eine sogenannte UTM Enterprise-Firewall eine Technik nicht beherrscht, die selbst eine kleine Fritzbox schon drauf hat. Es handelt sich um DHCPv6 prefix delegation, was die Fähigkeit bezeichnet, IPv6-Netze vom Zugangsrouter an dahinterliegende Router weiterzureichen. Mit Softwarestand 9.510-5 auf Sophos Firewalls ist diese Funktion auch im Jahr 2019 noch nicht vorhanden.d

Für alle, die jetzt nur Bahnhof verstanden haben:
Das ist in etwas so, wie wenn man ein Auto kauft und stellt fest, dass es keinen Rückwärtsgang hat. Natürlich hat man im Autohaus nicht danach gefragt – ist doch selbstverständlich, dass Autos Rückwärtsgänge haben.

Am kuriosesten ist an der Angelegenheit jedoch, wie man sich als Firewall-Hersteller eine solche Blöße leisten kann. Es gibt etliche Fälle von Global-Playern, die praktisch von einem Tag auf den anderen von der Bildfläche verschwunden sind, weil sie sich auf ihren Lorbeeren einfach ausgeruht habe. Daher fällt es schwer nachzuvollziehen, wie Sophos derart am Kunden vorbei entwickeln kann. Es gibt im Forum alleine 193 Anfragen für die Funktion. Das seit über 3 Jahren!
Ich habe gelernt, dass ein Kunde, der sich beschwert, für etwa 170 andere Kunden steht, die sich an der selben Sache stören. Das macht etwa 32.000 Kunden. Denn jeder, der dort seinen Willen kund getan hat, hat schon einen weiten Weg hinter sich, mit Recherchieren, mit Ausprobieren, einloggen, Posten, etc., um dann schließlich festzustellen: Das Ding kann DHCPv6-PD tatsächlich nicht. Die ignorieren die Kunden einfach.

Zeit, zu wechseln, wie dieser Beitrag zeigt…

und

wie der Kunde seit 2013 (!) ignoriert wird.

VMs lassen sich plötzlich nicht mehr migrieren

In einem Datacenter mit einem vmware-Cluster, bestehend aus mehreren ESXi Hosts trat die Unannehmlichkeit auf, dass sich einige virtuelle Maschinen unvermittelt nicht mehr migrieren ließen. Die Option zum Auswählen im Kontextmenu ist einfach ausgegraut, deaktiviert, nicht anklickbar. Ein Hinweis darauf, warum die Funktion nicht mehr verfügbar ist, ist nicht erkennbar. Das Hostbetriebsystem ist VMware ESXi, 6.5.0, 6765664, verwaltet von vCenter Server Appliance 6.5.0, 5973321.
Von der Beharrlichkeit, sich nicht zu anderen ESXi-Hosts migrieren zu lassen, sind Linux wie Windows Maschinen betroffen. Der Inhalt der virtuellen Container scheint somit keine Rolle zu spielen. Snapshots sind konsolidiert, bzw. es bestehen keine. Weiterhin sind keine Images in die virtuellen CD-Laufwerke der VM’s gemountet, was sonst unter vmware auch gerne mal zu informationtechnischem Schluckauf führen kann. Migrationen sind weder live, noch im ausgeschalteten Zustand der betroffenen VM’s möglich. Neustart des vCenter, der Hosts, sowie des Storge bringen keine Abhilfe. Die virtuellen Maschinen erscheinen festgenagelt an die Hardware.

Recherchen bringen Folgendes hervor:

https://kb.vmware.com/s/article/2044369

Notiz vom 09.November 2018 seitens vmware: Currently, there is no resolution

Vmware hat offensichtlich keine Ahnung, warum VM’s spontan nicht mehr korrekt in der Datenbank registriert sind, vCenter Server also an digitaler Amnesie leidet. Eine Lösung gibt es nicht, außer der harten OP an der Datenbank, oder der De- und Reregistrierung betroffener VM’s. Ich bevorzuge Letzteres.

Unangenehm an der Angelegenheit ist, dass man sich so nicht mehr auf die HA-Funktionalität verlassen kann. Die man teuer bezahlt hat. Keine Ahnung, wie sich der vmware Cluster verhält, wenn ein vmware Host wegbricht. Außerdem ist die Migration für den Fall eines Stromausfalles nicht mehr gesichert. Im Falle eines Stromausfalles meldet die USV innerhalb des Rechenzentrums, dass die VM’s in ein anderes RZ zu migrieren sind, um den reibungslosen Betrieb sicher zu stellen. Wenn VM’s jedoch an der Hardware „kleben“, crashen sie mit Ablauf der Batterielaufzeit. Wer kommt dann für den Schaden auf?

HFO Telecom bringt Ansage, dass Sprachkanäle begrenzt sind

Seit Anfang Dezember 2018 erhalte ich Beschwerden von Kunden der HFO Telecom, dass sie die Ansage hören, die maximale Anzahl von Sprachkanälen sei erreicht. Weitere Telefonate können dann nicht mehr geführt werden. Dies tritt ein, wenn zwei Leitungen belegt sind, obwohl vertraglich mehr Sprachkanäle ausgehandelt sind.

Nach Aussagen der HFO Hotline vom 10.Dezember ist dieses Verhalten auf einen Fehler zurückzuführen und sollte nun der Vergangenheit angehören.

HFO Telecom Ausfall

Seit mindestens 6 Uhr am 04.12.2018 wird mir von erheblichen Problemen bei der Erreichbarkeit von Anschlüssen berichtet, die beim SIP-Provider HFO Telecom konnektiert sind. Kunden klagen über einseitige Gespräche, abgehackte Anrufe oder auch totale Unerreichbarkeit.

Die Hotline des Anbieters konnte ich um 8 Uhr gar nicht erst erreichen.

Seit 10.21 Uhr ist der Status bei „NGN-Telefonie“ auf „schwerer Ausfall“ geändert.

Trotz Allem finde ich gut, dass der Anbieter Transparenz zeigt und die Vorfälle auf seiner Statusseite zeitnah publiziert.

Seit 13 Uhr entspannt sich die Lage. Die Kunden können wieder telefonieren.

VPN Durchsatz bei AVM’s Fritzbox

Der VPN Durchsatz der Fritzbox hat mich lange interessiert. Eben weil ich Heimzugänge mit Firmen damit gerne vernetzen wollte. Meine Erfahrungen mit dem Durchsatz waren dabei immer wieder ernüchtern. Mit dem Modell 7490 bekam ich immer nur maximal 1,2 Mbyte/s (entsprechend etwa 10MBit/s) durch die Leitung, egal ob eine weitere Fritzbox oder z.B. eine pfsense oder Linux im Rechenzentrum als Gegenstelle fungierte.

Gut, man kann einwenden, dass die Fritzbox ein Konsumer-Produkt und keine Enterprise Firewall ist. Und man darf sich darüber bewusst sein, dass nur wenige Kunden die Firewall-Funktionalität nutzen, gemessen an den gesamten Verkaufszahlen. Trotzdem dürften es sicher bestimmt einige zehn- bis hunderttausende Nutzer sein.

Recherchen zum VPN-Durchsatz blieben regelmäßig unklar. AVM vermied es, sich in irgendeiner Weise zum Durchsatz zu äußern. Tausend Meinungen in Foren, wenig kontextuelles Verständnis [1], schon gar keine brauchbaren Fakten.
Ein Datendurchsatz wie zu Modemzeiten, schrieb ein Forenteilnehmer jedoch passend im Jahr 2016.

Ebenfalls im Jahr 2016 misst ein Johannes Weber unter https://blog.webernetz.net/fritzbox-vpn-speedtests/ den Durchsatz unter professionelleren Bedingungen, und bestätigt, was ich auch immer messe: Der Durchsatz liegt üblicherweise bei höchstens um die 9 MBit/s. Unterirdisch.

Unter diesem Link schiebt der Hersteller AVM den Durchsatz sogar auf das Verhältnis von Overhead zu Payload, d.h. den Verwaltungsdaten zu Nutzdaten, das noch unter der alten Fritzbox 7390, bei der die CPU der noch limitierendere Faktor gewesen sein dürfte und noch lange nicht einmal 10 Mbit drin waren.

Ich hätte mir etwas mehr Ehrlichkeit von AVM gewünscht gegenüber den Kunden! Dass VPN immer langsamer als der native NAT-Durchsatz ist, das dürfte fast jedem klar sein. 20% Abzug, völlig normal.  Aber bei einer Diskrepanz von mehreren hundert Prozent, wenn man z.B. eine 50 oder 100 MBit Internetleitung betreibt und gerade mal 10 Mbit VPN-Durchsatz hat, da kommt man sich schon ziemlich „veräppelt“ vor, bei Hersteller-Aussagen, wie oben angeführt.

Die Zeitschrift C’t kommt mit den Durchsatzmessungen in Ausgabe 21/18 zu den selben Ergebnissen, wie meinen eigenen, als auch denen von Johannes Weber.

Ich tunnele nun mit OpenVPN und AES-NI-fähigen Prozessoren, damit ist der Durchsatz praktisch Wire-Speed (abzüglich Oberhead).

Utax Drucker und die Druckwarteschlange

Wie unter „https://www.nicht-trivial.de/index.php/2018/09/13/druckwarteschlange-stuerzt-unregelmaessig-ab/“ bereits angemerkt, stürzt auf einem Windows Server Betriebssystem unregelmäßig, aber häufig, die Druckwarteschlange ab. Und zwar sowas von „ab“, dass selbst Windows den Dienst selbsttätig nicht mehr startet. In einigen Fällen war sogar der Befehl „net stop Druckwarteschlange“ wirkungslos und produzierte nur den Ereigniseintrag (Eventlog) mit EventID: 7011 „Das Zeitlimit (30000 ms) wurde beim Warten auf eine Transaktionsrückmeldung von Dienst Spooler erreicht.“

Weiterhin sind gehäuft Meldungen mit EventID 1530 aufgetaucht:
„Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. “ betreffend \Device\HarddiskVolume1\Windows\System32\spoolsv.exe .

Bisher hatte ich die UTAX Druckertreiber in Verdacht. Der Verdacht hat sich nun erhärtet, als ich den Tipp bekam, den virtuellen Druckeranschluss (Standard TCP/IP Port) von RAW auf LPR umzustellen. Seither läuft die Druckwarteschlange stabil.

 

Druckwarteschlange stürzt unregelmäßig ab

Ein neuer Druckertreiber bringt offensichtlich den Spoolerprozess alias Druckwarteschlange unter Windows Server zum Absturz. Oder genauer gesagt wird die Druckwarteschlange in einen Zustand gebracht, in der sie nicht mehr reagiert, aber nicht ordentlich beendet wird. Das hat zu Folge, dass die Druckwarteschlange von Windows nicht als nichtfunktionierend erkannt und der Dienst neu gestartet wird. Supportanrufe diesbezüglich und manuelles Starten des Dienstes  lassen schnell nach Wegen suchen, die Sache automatisiert aus der Welt zu schaffen.

Die Lösung besteht derzeit daraus, ein Batch-Skript in Endlosschlaufe laufen zu lassen. Das Skript prüft auf Existenz eines vorhandenen Druckers. Wenn dieser nicht auffindbar ist, wird die Druckerwarteschlange neu gestartet.  Da rundll32 keinen auswertbaren Errorlevel zurück gibt, muss man über den Parameter /f eine Datei anlegen, welche als Indikator für den Fehlerfall dient. Bei jedem Neuaufruf der Skriptschleife wird die Datei (bei Existenz) wieder gelöscht.
Die Verzögerung wird über Pings an’s eigene System realisiert.
Ich setze zusätzlich noch eine „1“ per zabbix_sender an mein unabhängiges Monitoring-System Zabbix ab, um die Häufigkeit des Eingriffs mitzuloggen.

das Skript chkPrter.cmd:

@echo off
cls

SET PrinterName=Rechnungsdrucker
SET TESTfile=%TEMP%\PrtExist.txt

:start

REM Delete %TESTfile% to avoid false positives
IF EXIST „%TESTfile%“ (
DEL %TESTfile% /F /Q
)

REM Try to get the printer settings into a file
RUNDLL32.EXE PRINTUI.DLL,PrintUIEntry /Xg /n „%PrinterName%“ /f „%TESTfile%“ /q

IF EXIST „%TESTfile%“ (
REM ECHO Drucker %PrinterName% existiert
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 1 > NUL
) ELSE (
REM ECHO Drucker %PrinterName% existiert NICHT!
NET START Druckwarteschlange
REM „C:\Program Files\zabbix\zabbix_sender.exe“ -z zabbixserver.local -s ServerXYZ -k serverZYX.printer.spooler -o 0
)

ping -n 30 localhost > NUL

goto start

1&1 PHP extended Support

1&1 will Feedback …können sie haben. Und wenn ich mir schon die Mühe mache, dann gerne auch gleich öffentlich:

Ob ich zufrieden bin mit den Produkten von 1&1:
-> Da bin ich zwiegespalten. Manche Produke sind durchaus nutzbar. Aber da ist trotzdem immer Luft nach oben. Wenn ich neue Dienstleistungen in dem Bereich benötige, dann suche ich mir mittlerweile die Konkurrenz aus. Ihr (1&1) wollt mehr wissen? Das geht dann schon schnell in Richtung einer handfesten Beratung. Und Consulting kostet Geld. Punkt.

Ob ich 1&1 weiterempfehle: NEIN!
Zum dritten Mal nun schon flattert mir eine Rechnung über einen „PHP extended Support“ ins Postfach, verbunden mit der Selbstbedienung von meinem Bankkkonto.
Wir haben uns in den letzten Jahren bereits mehrfach am Telefon über die Praktik unterhalten: Dem Kunden wird ungefragt eine nicht willentlich gebuchte Leistung in Rechnung gestellt. Dazu sogar noch eine Leistung, die man oftmals gar nicht braucht.
Nach telefonischer Beschwerde wurde mir bisher das Geld wieder gutgeschrieben, wohl wissentlich, dass diese Geschäftspraktik alles andere als seriös ist. Wahrscheinlich ist das sogar rechtlich grenzwertig . Natürlich rufe ich immer persönlich auf der Hotline an. Ich gehe davon aus, dass Konzerne wie 1&1 nichts mehr scheuen als Kunden, die sich persönlich mit ihnen unterhalten wollen, denn das produziert Kosten. Hotline-Mitarbeiter kosten leider Geld. Also ran an die Strippe, 0721-9600 anrufen!

Das Geschäftsmodell mit dieser Praktik dürfte Folgendes sein: Kunden sind meist träge. Damit kann man Zaster machen.
Bei z.B. hunderttausend Hosting-Verträgen kann man einen PHP extended Support geltend machen, von denen es dann 50% gar nicht so schnell bemerken oder gar wissen, ob sie das brauchen. Von den übrigen 50% beschweren sich dann nur 5% und ein noch kleinerer Prozentsatz ist darüber ausreichend verärgert, dass er den Vertrag kündigt, bzw. zu einem seriösen Anbieter umzieht. Macht summa summarum: ganz fette Gewinne!

Aber zurück zum Feedback: 1&1-Vorstandsabteilung, ihr habt’s geschafft. Früher habt ihr mich von Hotline-Mitarbeitern zuhause und sogar auf dem Handy genervt, wenn ihr für eure Produkte werben wolltet. Meine Willenserklärung am Telefon, das zu unterlassen, habt ihr ignoriert, bis ich endlich in euerem Control-Center die tief versteckte Checkbox gefunden habe, Werbeanrufen zu widersprechen.

Und nun wollt ihr Feedback, wo ihr sonst nie zuhört. Wirkt auf mich ehrlichgesagt etwas Schizophren.

Nein, 1&1, so schnell nicht wieder!


Nachtrag: Herr M. von der Hotline hat auch zum dritten Mal die Rechnung gutgeschrieben. Meine Rückfrage, ob sich PHP komplett deaktivieren ließe, musste Herr M. verneinen. Sinngemäß „könne man es bei der Anzahl der Kunden nicht jeden recht machen“.
Ich interpretiere das so: Die Einnahmen rechtfertigt diese Geschäftspraktik. Die Controling-Abteilung wird gewiss entsprechende Geschäftszahlen herausarbeiten und daraus ableiten können, wie viele Kunden seit Einführung des „PHP Extend Supports“ 1&1 den Rücken gekehrt haben.
Denn: Es wäre ein Klacks, eine Checkbox im Control-Center zu implementieren, in der der Kunde entweder erklären kann, dass er gar kein PHP benötigt und damit die Frage nach einer Versionierung hinfällig ist, oder in der er dem automatischen Versionsupgrade zustimmt. Aber dann würde 1&1 ja keine derzeit 5,31€ pro Monat pro Kunde, der nicht widerspricht, verdienen.

Links zu ebenfalls verärgerten Kunden:

https://skillday.de/php-extended-support-von-1und1-kuendigen-widersprechen/

http://blog.mecksite.de/2017/02/13/was-bedeutet-11-extended-support-bauernfaengerei/

Und in diesem Forum möchte ein 1&1-Mitarbeiter eine Diskussion um die rechtliche Situation der Angelegenheit ungern öffentlich führen: http://www.joomlaportal.de/off-topic/315570-1-und-1-nicht-beauftragte-kostenpflichtige-zusatzleistungen.html

Warum wohl?

vi und Pagedown innerhalb SSH Session in osx-Terminal

PageUp und PageDown steht innerhalb von SSH-Sessions auf OSX leider nicht zur Verfügung. Das macht das Navigieren in Dateien sehr unkomfortabel. Speziell beim Editieren mit vi oder vim unter Linux ist das mehr als nervig.

Eine Abhilfe in vi ist der Shortcut STRG+f für Seitensprung vor und STRG+b für einen Rücksprung.

IPv6-Routing im Telekom-Netz

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.