Es kommt der Tag, da muss man aufräumen. Und das war nun bei IPTV der Fall. Einige tausend noch Karteileichen sollten nicht mehr versorgt werden. Die Idee dazu ist ganz einfach, nur noch authentisierte Clients bekommen eine IP. Ohne IP kein IGMP, ohne IGMP kein Multicast und ohne Multicast kein Fernsehen. Aber das hat fatale Nebenwirkungen.

Ausgangslage

Es sind knapp 12000 Nutzer im IPTV-Netz eingebucht, bekommen also eine IP Adresse. Die Verteilung der Sender erfolgt dezentral über Multicast-Replikation. Damit sind die Datenleitungen bis runter zum DSLAM nur minimal belastet. Das funktioniert sehr gut.

Die Liste der Kunden, die IPTV vertragsmäßig nutzen dürfen, liegt mittlerweile vor und kann auch von der Hotline/Vertrieb aktualisiert werden. Ein Abgleich der Datenbestände mit der Produktivumgebung erfolgt automatisch. Soweit so einfach.

Die Kunden bekommen aktuelle aus einem großen Pool privater IPs eine DHCP-Lease. Eine Authentisierung erfolgt nicht, weil das der bisherige gewünschte Operationsmodus ist.

Umsetzung

Zur Änderung des Operationsmodus sind einige Vorüberlegungen notwendig:

  • Es dürfen nicht alle Kunden mit einmal gesperrt werden, sondern nur ein Teil, damit die Hotline auf evtl. Fehlsperrungen reagieren kann.
  • Authentisierte und nicht authentisierte Kunden sollten technisch unterscheidbar bleiben, damit der Netzbetrieb Kenntnis von der Vertragslage hat.
  • Der Abgleich der Datenbanken zwischen Vertrieb und Produktion darf nicht angefasst werden, in den Datenbanken des Produktivsystem darf kein Kunde virtuell zugeteilte MAC-Adressen haben, die dem Vertriebssystem fremd sind. Andernfalls ist die Hotline nicht zur Störungsdiagnose und -behebung in der Lage und alle diese Fälle eskalieren in den Netzbetrieb.

Als Lösung werden zwei Pools eingerichtet:

  • ein großer Pool für die authentisierten Kunden und
  • ein kleinerer Pool für die nicht authentisierten Kunden.

Der unauthentisierte Pool kann dann schrittweise verkleinert werden, um für immer mehr Kunden den Zugang zu sperren. Bei Bedarf kann er auch schlagartig wieder vergrößert werden. Dies gestattet die Anzahl der ausgesperrten Kunden rein im operativen Betrieb einzustellen, die Datenbanken bleiben davon unberührt.

Da sich beide Pools hinsichtlich der verwendeten Adressbereiche unterscheiden ist die Diagnose, ob eine fehlende Authentisierung vorliegt auch der Hotline direkt möglich. Diese kann bei Bedarf die Daten auslesen und direkt zur Freischaltung verwenden.

Soweit der Plan.

Überraschungen

Ich müsste nicht darüber schreiben, wenn es so einfach gegangen wäre. Also zuerst einmal die Wirkung der Umschaltung.

poolusage-dhcp.iptv-limit

Nach einem Testlauf kurz vor Mitternacht (bei dem sich herausstellte, dass die Auswertung der Authentisierung gar nicht aktiviert wurde), erfolgte dann wie geplant die Umschaltung und die erste Limitierung der Kunden auf ca. 5000 unauthentisierte Teilnehmer.

Wie leicht zu sehen, hat das dann nach Ablauf der Lease-Zeiten auch funktioniert. Sobald der Pool voll war, sank die Anzahl der IPTV-Teilnehmer ab, bis alle authentisierten plus die glücklichen 5000 Pool-Teilnehmer. In Summe um die 6000 Kunden.

Auch zu sehen ist aber auch, dass diese Reglung wieder aufgehoben wurde. Und das kam so:

In bestimmten Gegenden fiel am nächsten Morgen regelmäßig der komplette Anschluss aus. Einige Switche stellte kurzzeitig, aber effektiv, die Arbeit ein. Zwar erholten sie sich wieder, jedoch blieb ein konstanter Betrieb aus. Stattdessen wiederholte sich der Ausfall in kurzen aber unregelmäßigen Abständen.

Es stellte sich heraus, dass diese Switche mit Bursts von Broadcasts nicht klar kamen, wenn in diesen Burst zu viele unbekannte Quell-MAC-Adressen auftauchten. Offenbar geraten diese Geräte dann an Limits hinsichtlich der Verwaltung von MAC-Adressen. Diese Bursts kommen aus dem DHCP:

poolrate-dhcp.iptv-limit

Als Notlösung wurde erst einmal wieder für alle der Zugang freigegeben. Damit hören die Bursts auf und das System funktioniert wieder.

Diese Bursts bestehen aus den DHCPDISOVER Anfragen der CPEs, für die keine Adressen mehr zur Verfügung stehen. Und die fragen eben alle paar Sekunden per Broadcast rum, ob irgendjemand evtl. doch eine IP für sie übrig hat.

Broadcast heißt aber auch, dass die Anfragen auch die hintersten Winkel des Netzes erreichen, insbesondere diese empfindlichen Switche. Im Normalbetrieb haben diese Switche kein Problem, aber so war's doch etwas zu heftig.

Die Lösung besteht nun darin, die betreffenden Segmente in getrennte Broadcast-Domains zu verfrachten und die Multicast-Streams in alle diese VLANs einzuspeisen. Aber dazu später mal mehr.

Quo usque tandem abutere, Mozilla, patientia nostra? Überaschenende Einblicke in das Zertifikatshandling von Firefox und Thunderbird. Einige wichtige abgelaufene Zertifikate werden defaultmäßig als in der Ausnahmeliste geführt. Und natürlich noch einiges mehr.

Überraschung

Mein Kollege schaute gerade etwas konsterniert, als er im ThunderBird einem Zertifikatsproblem nach jagte.

FireFox Advanced Options

Der Klick auf View Certificates und dann auf den Reiter Servers offenbart Erschreckendes:

FireFox freigeschaltete Zertifikate

Was zur Hölle?!

Was sollen diese Freischaltungen für abgelaufene Zertifikate? Was soll die Zertifikate für mögliche Schadcode-Server?

Usability-Problem

Zumindest die Suche nach dem ominösen MD5 Collisions Inc. Zertifikat bringt eine Erklärung: Allen diesen Zertifikaten wurde das Vertrauen entzogen.

Das Problem damit ist, dass man diese Eigenschaft nicht sofort sieht. Da in der Liste auf die individuellen Freischaltungen landen, die man selbst genehmigt hat, ist es nicht so leicht, den Überblick zu behalten. Denn schließlich dient die Liste ja ganz anderen Zwecken:

  • Mozilla stellt eine Liste von Zertifikatsausnahmen bereit, damit der Nutzer lokale Abweichungen der globalen Policy vornehmen kann.
  • Der Nutzer trägt in die Liste Zertifikate ein, denen er vertraut.
  • Mozilla behält sich vor, die Liste der Zertifikatsausnahmen auch selbst zu pflegen.
  • Bisher hat Mozilla zum Schutz der Nutzer dort Zertifikate eingetragen, denen nicht vertraut werden soll.
  • Es ist der Liste nicht anzusehen, ob vertraut oder nicht vertraut wird.

Damit bleibt dem Nutzer nichts anderes übrig, als regelmäßig alle Einträge in der Liste anzuklicken, um die Vertrauenseinstellungen zu überprüfen. Das ist inakzeptabel.

Vor einigen Tagen verloren nach einem Failover auf die Hot-Standby-Maschine ein Großteil dort aktiven Kunden ihre Kommunikationsmöglichkeit. Grund waren divergierende MySQL-Datenbanken, die eigentlich per Replikation in einem synchronen Zustand gehalten werden. Derartige Fehlerzustände werden überwacht und ggf. alarmiert. Aber genau das Monitoring hat versagt.

Was geschehen ist

Eine Appliance für einen klassischen Cloud-Dienst, steht als Hochverfügbarkeitslösung mit zwei Knoten da, von denen der eine den anderen in Sekundenbruchteilen übernehmen kann. Alle laufenden Sessions der Kunden werden dabei übernommen, so dass der Kunde nichts vom Umschalten mit bekommt.

Das hat jahrelang bestens geklappt. Nur eben diesmal nicht. Die Lösung des Problems war einfach: Zurückschalten und Beginn der Fehleranalyse.

Es stellte sich heraus, dass die MySQL-Datenbank auf dem Standby-System schon seit Tagen nicht mehr synchron lief. Sie verweigerte ab einem bestimmten Kommando (Löschen einer Tabelle) das Replay des Replikationslogs. Grund war, dass die Tabelle selbst schon nicht vorhanden war und deswegen nicht gelöscht werden konnte. Die Tabelle selbst war nur ein Überbleibsel eines Tests, also nicht wirklich relevant. Warum sie auf dem zweiten System schon gefehlt hat, ist nicht ganz nachvollziehbar. Vermutlich hat sich irgendwann der Replikations-Filter geändert, so dass die Tabelle erst später Bestandteil der Replikation wurde.

Fakt ist, dass die Replikation nicht mehr lief. Beim Failover traten dann die abstrusesten Effekte auf.

Warum es nicht auffiel

Wesentlich interessanter ist die Frage, warum die fehlerhafte Synchronisation nicht aufgefallen ist. Schließlich gibt es ein Monitoring auf Synchronisations-Diskrepanzen an die ein Alarm angeschlossen ist. Eigentlich hätte es also schon Tage vorher mächtig klingeln sollen.

Das Monitoring lieferte aber immer nur einen Wert von "0" für die Anzahl der Synchronisationsabweichungen. Warum?

Ein Blick in den Quellcode des Monitorings (ein collectd-Plugin) zeigt:

        if ($MK_REPLICATE_CHECK_TABLES && $MK_REPLICATE_CHECK_HOSTS) {
                my $now = time();
                my $fake;
                if ($MK_REPLICATE_CHECK_INTERVAL && $mk_last_run && defined($mk_last_result)) {
                        if ($now - $mk_last_run < $MK_REPLICATE_CHECK_INTERVAL) {
                                $fake = $mk_last_result;
                        }
                }

                if (!defined($fake)) {
                        my @tables = split(/[\s,;]+/, $MK_REPLICATE_CHECK_TABLES);

                        my @fails = do_replication_check(\@tables);
                        my @rechecks = do_replication_check(\@fails, '--wait=60');

                        $fake = scalar(@rechecks);
                        $mk_last_run = $now;
                        $mk_last_result = $fake;
                }

                defined($fake) and plugin_dispatch_values({
                        type => 'mysql_replication_discrepancies',
                        plugin => "XXX",
                        values => [ $fake ],
                        host => $ME,
                });
        } 

Collectd ruft eine read-Funktion regelmäßig auf, um dem Plugin die Möglichkeit zu geben, Daten zu sammeln. Hat das Plugin die Daten ermittelt, schickt es diese mit plugin_dispatch_values an den collectd zurück, der den Messwert an die verschiedenen write-Funktionen der Ausgabe-Plugins übermittelt. Letzteres ist u.a. der RRD-Writer.

In diesem Fall fällt auf, dass das Plugin nur alle $MK_REPLICATE_CHECK_INTERVAL Sekunden überhaupt eine Messung macht. In der Zwischenzeit liefert es den letzten Messwert immer wieder aus.

Weiterhin auffällig ist, dass der Messwert selbst die Anzahl der Tabellen enthält, die nicht synchron sind. Dazu übergibt er die zu überwachenden Tabellen der eigentlichen Messfunktion und diese liefert ihm die Liste der Tabellen, die nicht synchron sind.

In einer zweiten Runde werden – mit einer Wartezeit von bis zu einer Minute – die Tabellen angeschaut, die sich verändert haben. I.d.R. also die Tabellen, die häufigen Änderungen unterliegen. Diese werden nach einem deutlich aufwendigeren Verfahren auf Synchronität untersucht. Es ist offenbar sinnvoll, die statischen Tabellen in einer schnellen ersten Runde schon auszusortieren.

Was dann immer noch nicht synchron ist, bleibt übrig und erhöht den Rückgabewert um eins.

Dieser Teil der Funktion schaut auf den ersten Blick ganz normal aus.

Wie funktioniert aber nun die Messung?

Die eigentliche Messfunktion ist folgende:

        sub do_replication_check {
                my ($tables, $add_args) = @_;

                $add_args or $add_args = '';

                my %results;
                for my $t (@$tables) {
                        my $arg = ($t =~ /\./) ? "--tables=$t" : "--databases=$t";
                        my $out = `mk-table-checksum --algorithm=ACCUM $arg $add_args --tab $MK_REPLICATE_CHECK_HOSTS 2>&1`;
                        my @out = split(/[\n\r]+/, $out);
                        my @headers = split(/\t/, $out[0]);
                        for my $i (1 .. $#out) {
                                $out[$i] or next;
                                my @c = split(/\t/, $out[$i]);
                                scalar(@c) == scalar(@headers) or next;
                                my $h = { map {$headers[$_], $c[$_]} (0 .. $#headers) };
                                $results{$h->{DATABASE} . '.' . $h->{TABLE}}->{$h->{HOST}} = $h;
                        }
                }

                my @fails;
                for my $k (values(%results)) {
                        ref($k) eq 'HASH' or next;
                        my @r = values(%$k);
                        @r > 1 or next;
                        my $h = $r[0]->{CHECKSUM};
                        for my $j (1 .. $#r) {
                                my $i = $r[$j];
                                $h eq $i->{CHECKSUM} and next;
                                push(@fails, $i->{DATABASE} . '.' . $i->{TABLE});
                                last;
                        }
                }

                return @fails;
        }

Man kann sicher über den Stil der Perl-Programmierung lästern, aber das ist nicht das Thema. Interessanter ist die Frage, was der Code tut.

Er lässt sich vom Programm mt-table-checksum die Liste der Prüfsummen über die einzelnen Tabellen geben. Diese parst er und vergleicht anschließend, ob die Prüfsummen pro gefundener Tabelle auf beiden Systemen überein stimmt.

Hat er unterschiedliche Prüfsummen für die Tabellen gefunden, so wird die Tabelle als unsynchronisiert zurück gemeldet.

Was kann daran schon schief gehen?

Ich schaue mir die Ausgabe des Programms mal direkt an:

# mt-table-checksum ...
-bash: mt-table-checksum: command not found

WTF?!

Der Programmcode ignoriert die erste Zeile (die mit der Fehlermeldung) und liest dann die Liste der Tabellen mit ihren Prüfsummen ein (die ist leer). Anschließend vergleicht er, ob er für die gefundenen Tabellen (also keine) Unterschiede bei den Prüfsummen feststellen kann (was nicht möglich ist). Also kommt er zum Schluss, dass keine Unterschiede vorliegen.

Keine Unterschiede zwischen den beiden MySQL-Instanzen heißt also, nach Logik des darüber liegenden Monitorings, dass die Synchronisation in Ordnung ist.

Was wirklich schief gelaufen ist

Der eigentliche Fehler der Messfunktion besteht darin, dass sie keine Validitätsprüfung der Ausgabe gemacht hat.

Sie bekommt eine Liste von Tabellen und hat dann zumindest zu prüfen, ob diese Tabellen überhaupt Prüfsummen geliefert haben! Würde das geprüft, wäre das Fehlen des externen Programms instantan aufgefallen.

Man kann natürlich auch argumentieren, dass der Errorcode des Programmaufrufs zu prüfen gewesen wäre. Oder die Existenz des Programms selbst. Oder, oder ... Am Ende läuft es darauf hinaus, dass die erwartete Ausgabe vorliegt. Schließlich gibt es ja auch noch viele andere Möglichkeiten, warum das externe Programm seinen Job nicht erledigen konnte.

Es wäre nun leicht, diesen Test hinzu zufügen. Allerdings ist das eine fremde Appliance und da geht der Weg über den Hersteller-Support.

Was wir tun können, ist das fehlende Programm nachzuinstallieren. Es ist im Rahmen eines Updates verschwunden, als die Datenbank dieses Programm durch das wesentlich flexiblere und robustere pt-table-checksum ersetzt hat. Ja, das ist schon eine ganze Weile her.

Überraschende Nicht-Lösung

Nachdem nun das betreffende Programm mk-table-checksum installiert war (wobei der Alarm an sprang) und manuell die Datenbank wieder in Sync gebracht wurde (so dass der Alarm verstummte), schien alles soweit in Butter.

Allerdings zeigte sich in der darauf folgenden Nacht, dass da noch ein anderer Fehler drin steckt.

Über einige Stunden schwankte der Messwert, den collectd einsammelte, zwischen 0.1666, 0.25, 0.3333 und 0.5. Alle paar Minuten ergab sich ein anderer Wert.

Zur Erinnerung: Der Messwert ist die Anzahl der unsynchronisierten Tabellen!

Erst die Dokumentation von collectd brachte die Lösung: Wenn mehrere Messwerte in einem sehr kurzen Zeitfenster eingehen, werden sie von collectd gemittelt und dieser Mittelwert wird an die write-Funktionen übermittelt. Die Messwerte sind klare Brüche: Einer von zwei, drei, vier, ... Messungen hatte eine Eins, der Rest Null geliefert.

Wie können aber viele Messwerte in so kurzer Zeit eingehen?

Zur Erinnerung: collectd ruft die read-Funktion regelmäßig auf. Also auch dann, wenn die schon aufgerufene Funktion sich noch nicht beendet hat!

Es liefen also zwei oder mehr Prüfungen parallel. Und vermutlich war zu dem Zeitpunkt die Datenbank mächtig belastet. Es hat alles gedauert, auch die Tests. Als die Last nachließ, wurden alle Prüfungen zusammen fertig.

Logischerweise hinkt eine schwer belastete Datenbank auch in der Replikation hinterher. Es ist also nur natürlich, wenn einer der Messungen dieses feststellt.

Also Ticket Nummer zwei beim Hersteller: Verhindern der Doppelausführung.

Manchmal muss man Dinge tun, die nicht direkt in den eigentlichen Aufgabenbereich fallen. Aufgrund von Abwesenheit der üblichen Verdächtigen musste ich heute beim Updaten von Windows Servern aushelfen. Und das war mal ein spannendes Erlebnis, weil ein Update so richtig Ärger gemacht hat.

Gleich vorweg: Ja, man kann da viel automatisieren. Deswegen sieht man auch lokales Management der Updates. Unsere Spezialität im Cloud-Geschäft besteht aber darin, individuelle Lösungen mit dem Kunden zusammen zu erstellen und nicht ausschließlich identische Maschinen von der Stange zu nehmen oder den Kunden mit dem Updateproblem allein zu lassen. Also ist einiges an Handarbeit nach wie vor notwendig, um nach dem Update sicher zu stellen, dass die benötigten Dienste auch wirklich laufen.

Es hängt und hängt und hängt

Wenn besonders viele Systeme auf einmal angefasst werden müssen, ist es besonders nervig, wenn es nicht schnell genug vorwärts geht.

windows-update-stalled

An der Stelle kann man warten und warten. Manchmal geht's nach einer halben Stunde spontan weiter. Manchmal aber auch nicht.

Nein, natürlich sitzt da niemand davor und wartet, sondern die Updaterei erfolgt parallel. Man sieht halt nur, dass einige Kisten nicht weiter machen.

Also mal in den Taskmanager geschaut und festgestellt, dass ein Updateprozess nicht weiter macht. Den kann man manuell abschießen.

windows-update-kill

Ein beherzter Kill des Prozesses zeigt unmittelbare Wirkung.

windows-update-running

Beim späteren Reboot wird der Update dann korrekt installiert. Insofern ist das kein Problem.

Interessanter ist die Frage nach der Ursache dieses Phänomens. Und da hatte ich Glück.

windows-update-ursache

Wie man sehen kann, ist der aktiv laufende Prozess die alte Version des Tools, das aktualisiert werden soll.

Da das Tool zur Entfernung bösartiger Software sicherlich auch Signaturen solcher Software enthält, besteht eine gewisse Wahrscheinlichkeit, dass eine ältere Version diese neuen Signaturen als bösartig einstufen kann. Wenn das der Fall ist, wird sie die Ausführung der bösartigen Software verhindern.

Und damit steht der Update-Prozess.

Zur Gegenprobe kille ich den alten Prozess und siehe an: Das Update läuft sofort und ohne Fehler durch.

Heute flog mal wieder eine seltsame Fehlermeldung durchs Log bei der auch normales Googlen keine sinnvollen Ergebnisse brachte. Deswegen möchte ich sie hier dokumentieren.

bestmx_map_lookup: MX host 2001:4420:f501:0400::2. includes map delimiter character 0x3A 

Der Übeltäter war schnell gefunden: Eine E-Mail an eine taiwanische Adresse.

550 5.1.2 <xxx@ems.shiyeu.gov.tw>... Invalid MX record for recipient host ems.shiyeu.gov.tw 

Also schauen wir uns mal den MX genauer an:

$ host ems.shiyeu.gov.tw
ems.shiyeu.gov.tw has address 117.56.237.218
ems.shiyeu.gov.tw has address 192.168.5.252
ems.shiyeu.gov.tw has address 192.168.56.1
ems.shiyeu.gov.tw has IPv6 address 2001:4420:f501:400::2
ems.shiyeu.gov.tw mail is handled by 10 117.56.237.218.
ems.shiyeu.gov.tw mail is handled by 10 2001:4420:f501:0400::2.

Autsch! Da ist wohl jemanden aufgefallen, dass man keine IP-Adressen in den MX schreiben darf, weil dann Namen wie 117.56.237.218.ems.shiyeu.gov.tw. entstehen. Aber anstatt den Fehler zu verstehen und den Namen eines Servers hin zuschreiben, hat man einfach einen Punkt an die IP-Adresse angehängt und so den DNS-Namen verkürzt.

Der MTA interpretiert aber den Doppelpunkt (0x3A) als Trennzeichen in Maps (Hilfetabellen) und beschwert sich dann darüber.

Würde nur legacy IP(v4) benutzt, käme nicht mal eine so deutliche Fehlermeldung. Denn grundsätzlich könnte eine IP(v4)-Adresse auch ein gültiger DNS Name sein: Er hat alphanumerische Texte, die durch Punkte getrennt sind. Das zu der IP als Name interpretiert dann keine IP existiert, macht die Fehlersuche allerdings nicht einfacher.

Spielereien

Also spielen wir mal:

$ORIGIN donnerhacke.de.
broken-mx    MX  0  1.2.3.4
broken-mx2   MX  0  1.2.3.4.

Das ergibt dann bei der Abfrage im DNS:

$ host broken-mx.donnerhacke.de
broken-mx.donnerhacke.de mail is handled by 0 1.2.3.4.donnerhacke.de.

$ host broken-mx2.donnerhacke.de
broken-mx2.donnerhacke.de mail is handled by 0 1.2.3.4.

Und damit versuche ich jetzt mal E-Mails zu verschicken.

from=<test@broken-mx.donnerhacke.de>, size=40, nrcpts=1, proto=ESMTP, daemon=MTA, relay=... 

Das geht? Ja, natürlich. Ich habe ja einen Wildcard Eintrag. Der passt auch auf 1.2.3.4.donnerhacke.de. Und damit sieht das aus wie ein korrekter Absender.

550 5.1.2 <test@broken-mx2.donnerhacke.de>... Illegal MX record for recipient host broken-mx2.donnerhacke.de

Der andere Eintrag funktioniert aber nicht. Wie erwartet gibt es keine schwerwiegende Fehler-Meldung über irgendwelche Map-Zeichen, sondern nur eine blanke Ablehnung. Der Grund ist einfach, dass es für 1.2.3.4. keine IP Adresse im DNS gibt.

Beim Versenden der E-Mail an diesen Empfänger schaut es noch anders aus:

rcpt to: <test@broken-mx.donnerhacke.de>
250 2.1.5 <test@broken-mx.donnerhacke.de>... Recipient ok
rcpt to: <test@broken-mx2.donnerhacke.de>
250 2.1.5 <test@broken-mx2.donnerhacke.de>... Recipient ok
DATA
...
250 2.0.0 u4I8Kv6c010237 Message accepted for delivery 

Und was passiert genau?

to=<test@broken-mx.donnerhacke.de>, relay=1.2.3.4.donnerhacke.de. [217.17.193.188], stat=User unknown
to=<test@broken-mx2.donnerhacke.de>, relay=1.2.3.4., stat=Deferred: 1.2.3.4.: No route to host

In einem Fall greift der Wildcard-Eintrag, aber der Server nimmt keine E-Mail für solch einen Nutzer an.

In dem anderen Fall kann keine Adresse ermittelt und deswegen kann auch der Zielserver erreicht werden. Da eine solche Situation von externen Diensten abhängig ist und diese auch mal fehlerhaft sein können (die Namensauflösung kann schlicht auch mal scheitern), wir die E-Mail zurück gelegt und später nochmal versucht.

May 18 10:22:49 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host
May 18 10:23:49 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host
May 18 10:24:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host
May 18 10:25:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host
May 18 10:26:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host
May 18 10:27:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host
May 18 10:28:50 to=<test@broken-mx2.donnerhacke.de>, stat=Deferred: 1.2.3.4.: No route to host
...

Für den Admin ist die Meldung allerdings fehlerträchtig. Es ist leicht zu übersehen, das es sich um einen DNS-Namen und nicht um eine IP-Adresse handelt. Man kann Stunden damit zubringen, den Fehler überhaupt zu erkennen.

Die Seite https://ssl-tools.net/ ist eine Webseite, die vieles rund um Zertifikate prüft. Das macht sie gut, wenn auch Verbesserungsbedarf bei z.B. internen CAs besteht. Aber das ist Geschmackssache. Reale Fehler als valid auszuzeichnen ist allerdings keine Geschmacksfrage, sondern ein ernstes Problem. Akut führt die Seite es an sich selbst vor.

Zertifikate laufen aus

Im Gegensatz zu OpenPGP laufen die Zertifikate unter X.509 (aka SSL) nach einer festen Zeit aus. Bei DNSSEC ist das auch so, aber da ist der Erneuerungsprozess der Signaturen i.d.R. voll automatisiert, weil es alle Signaturen lokal erzeugt werden können. Bei X.509 muss man mit einem externen Partner regelmäßig zusammen arbeiten, um ein Zertifikat zu erneuern. https://letsencrypt.org schlägt deswegen ein Verfahren vor, diese Interaktion zu automatisieren und damit ähnlich leicht handhabbar zu machen, wie DNSSEC.

Aber bislang ist man meist immer noch mit den klassischen Zertifikaten unterwegs. Und hat sich um den regelmäßigen Austausch manuell zu kümmern. Das klappt nicht immer.

Heute schrie mein Webbrauser über fehlerhafte, weil abgelaufene Zertifikate von ssl-tools.net.

Reflexionen

Aber wie sieht sich die Seite selbst? Wird sie ebenfalls laut schreien und Warnungen anzeigen?

Oh, wirklich?

Das Zertifikatskästchen ist grün und vertrauenswürdig, aber in den Details steht was von seit 13 Stunden abgelaufen.

Ebenfalls witzig ist die Diskrepanz zwischen dem DANE-Kästchen (rot und böse) und den Details dort: valid.

Was ist denn nun bei DANE wirklich los? Alles rot oder alles grün? Was ist denn mit DNSSEC los?

Na das schaut ja gar nicht gut aus: Die gesamten DNSSEC-spezifischen Records (Signaturen) fehlen in der Zone!

Wie kann man da nur ein grünes valid hinschreiben?

Andere Sicht

Andere Testseiten wie https://www.ssllabs.com/ sind da wesentlich restriktiver:

In einem früheren Beitrag hatte ich anhand eines graphischen Beweises gezeigt, wie man sich den Satz des Pythagoras herleiten kann. Leider enthält der Beweis einige Ungereimtheiten, die ich geflissentlich ignoriert hatte. Welche Bedeutung diese Ungereimtheiten haben können, sei an einem konkreten Beispiel demonstriert.

Überraschung

In dem täglich durchfliegenden Datenstrom war heute ein Prachtstück des missratenen Beweises.

dreieck-fail

Wie man klar erkennen kann, liegen zwei verschiedene Zerlegungen ein und desselben Dreiecks in identische Teile vor. Aber irgendwie hat sich da eine Lücke aufgetan!

Ganz offensichtlich handelt es sich um einen Scherz, der deutlich macht, wie genau man auf seine Voraussetzungen achten muss.

Also rekapitulieren wir mal:

  • Handelt es sich um ein und dasselbe Dreieck?
  • Sind die Teilstücke identisch?
  • Haben die Stücken die Form, die sie vorgeben?
  • Ist die Zerlegung universell, oder handelt es sich um einen Spezialfall?

Beginnen wir mir der zweiten Frage: Sind die Teilstücken identisch?

Das ist leicht zu prüfen: Man zählt die Kästchen, die jedes Teilstück in jede Richtung einnimmt und schaut, ob alle Linien wirklich gerade sind. Das ist in beiden Bildern auf die gleiche Art der Fall.

Die zweite Frage ist also mit Ja zu beantworten.

Nun zu ersten Frage. Auch hier ist die Überprüfung genauso leicht: Man zählt wieder die Kästchen 13 breit und 5 hoch. Die Linien sind auch alle gerade, oder?

So ganz klar ist das nicht, denn das große Dreieck wird ja zusammen gestückelt. Es wäre also durchaus möglich, einer Täuschung zu unterliegen.

Also legen wir das rote und das türkisfarbene Dreieck mal direkt aufeinander und zeichnen die Linien dünn.

dreieck-overlap

Huch?! Da ist ja eine kleine Abweichung!

Wenn man die Dreiecke mal genau aufeinander malt, gibt es folgende Form:

dreieck-bereich

So richtig dreieckig sieht das nicht aus!

Damit ist die Frage drei mit einem eindeutigen Nein zu beantworten: Die Form ist nicht das, was sie zu sein vorgibt. Die dick gezeichneten Linien sind der Quell der Täuschung.

Und somit ist auch die fehlende Fläche gefunden: Der schmale, aber lange Bereich hat genau den Flächeninhalt des fehlenden Kästchens.

Hausaufgabe

Damit ist der Fall aber noch nicht beendet. Denn es bleibt Frage vier: Handelt es sich um einen Spezialfall?

Aber wo könnte denn der Spezialfall vorliegen? In der Zerlegung des Rechtecks.

Wer möchte, kann mal selbst knobeln, wann man das Rechteck nach der Vertauschung der Dreiecke auf die angegebene Weise zerlegen kann. Ist diese Zerlegung nämlich generell möglich, so müsste sie bei Verwendung eines richtigen Dreiecks keine Lücke lassen.

Ich freue mich über Eure Erfolgsmeldungen in den Kommentaren.

Heute morgen begann eine ClamAV Installation bei einem Kunden zu spinnen. Freshclam, der Updater von ClamAV, weigert sich die Aktualisierungen vorzunehmen. Wenn man den Grund dann kennt, ist alles wohl dokumentiert. Wenn auch die Ursache in einer schlechte Pflege der Produktionsumgebung von ClamAV liegt.

Der Morgen

Eine E-Mail vom cron berichtete Schlimmes vom Versuch die Datenbank des ClamAV zu aktualisieren.

ERROR: getpatch: Can't download daily-21465.cdiff from db.DE.clamav.net
ERROR: getfile: Download interrupted: Operation now in progress (IP: 62.27.56.14)
ERROR: Can't download daily.cvd from db.DE.clamav.net
ERROR: getpatch: Can't download daily-21465.cdiff from database.clamav.net
ERROR: getfile: Download interrupted: Operation now in progress (IP: 62.27.56.14)
ERROR: Can't download daily.cvd from database.clamav.net

Unglücklicherweise hörten diese Fehler nicht auf. Also muss man auf der Maschine schauen, was falsch läuft.

Ein händisch angeworfener Update produziert eine lange Liste von Fehlversuchen:

ClamAV update process started at Thu Mar 17 11:14:42 2016
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
WARNING: getfile: daily-21465.cdiff not found on remote server (IP: 62.27.56.14)
WARNING: getpatch: Can't download daily-21465.cdiff from db.DE.clamav.net
Trying host db.DE.clamav.net (88.198.17.100)...
connect_error: getsockopt(SO_ERROR): fd=4 error=111: Connection refused
Can't connect to port 80 of host db.DE.clamav.net (IP: 88.198.17.100)
Trying host db.DE.clamav.net (178.63.73.246)...
nonblock_connect: connect timing out (30 secs)
Can't connect to port 80 of host db.DE.clamav.net (IP: 178.63.73.246)
Trying host db.DE.clamav.net (84.39.110.99)...
nonblock_connect: connect timing out (30 secs)
Can't connect to port 80 of host db.DE.clamav.net (IP: 84.39.110.99)
WARNING: getpatch: Can't download daily-21465.cdiff from db.DE.clamav.net
WARNING: getpatch: Can't download daily-21465.cdiff from db.DE.clamav.net
WARNING: getpatch: Can't download daily-21465.cdiff from db.DE.clamav.net
WARNING: getpatch: Can't download daily-21465.cdiff from db.DE.clamav.net
WARNING: Incremental update failed, trying to download daily.cvd
nonblock_recv: recv timing out (30 secs)
WARNING: getfile: Download interrupted: Operation now in progress (IP: 62.27.56.14)
WARNING: Can't download daily.cvd from db.DE.clamav.net
Trying again in 5 secs...

Bei jedem Versuch schaut das ähnlich aus. Egal, ob man es einige Minuten später oder gleich nochmal probiert.

Manchmal klappt aber auch eine Verbindung und der Download ist extrem langsam. Es dauert mehrere Minuten, bis 1% der Daten angekommen sind. Aber dann hat freshclam schon wieder aufgegeben.

Also einen Sniffer angeworfen und geschaut, was da eigentlich abgeht: Es wird z.B. die URL http://db.DE.clamav.net/daily.cvd abgerufen.

Mit einem wget auf der gleichen Maschine gibt es aber keinerlei Schwierigkeiten, diese Datei zu laden. Es geht richtig schnell.

Vielleicht hat ja die Maschine ein Durchsatzproblem in Richtung Festplatte? Nein, auch nicht. Selbst ein wget parallel zu einem langsamen dahin kriechenden freshclam ins das gleiche Verzeichnis, in das freshclam auch reinschreibt, ist rattenschnell.

Ein Blick ins DNS zeigt, dass das Problem auch auf Serverseite liegen kann. Also mal testen:

$ dig +short db.DE.clamav.net |
 while read a; do
   echo $a;
   wget -Y off -O /dev/null http://$a/daily.cvd;
 done

Ergebnis:

IP Datenrate
88.198.17.100 Connection refused
130.133.110.67 22.3 KB/s
144.76.28.11 404 Not Found
176.9.115.53 301 Moved Permanently
178.63.73.246 Connection timed out
193.27.49.165 781 KB/s
195.30.97.3 503 Service Temporarily Unavailable
212.227.138.145 Connection timed out
213.174.32.130 404 Not Found
62.27.56.14 600 Byte/s (3 KB/s mit langen Pausen)
62.201.161.84 2.41 MB/s
62.245.181.53 1.71 MB/s
84.39.110.99 Connection timed out

Das ist ja großes Kino! Die Qualität des Servernetzwerkes ist durchaus noch etwas ausbaufähig.

Ursache und Fehlerbehebung

Um mit solchen Ausfällen im Content Delivery Network umgehen zu können, hat freshclam einen Verfügbarkeitscache: Die Datei mirrors.dat.

Ein Blick in die Datei zeigt

$ freshclam --list-mirrors | fgrep Ignore | sort | uniq -c
      5 Ignore: No
     10 Ignore: Yes

Der größte Teil der Server wird also schon komplett ignoriert. Die paar Server, die noch zulässig sind, tauchen aber nicht mehr in der DNS-Auslösung mit auf. Im Endergebnis gibt es kaum noch zulässige Server, die freshclam benutzen darf und die sind extrem langsam oder funktionslos.

Nach dem Löschen der mirrors.dat fluscht der Update wieder.

Und jetzt fällt mir auch der Hinweis am Ende der freshclam Ausgabe wieder ein: Update failed. Your network may be down or none of the mirrors listed in /etc/freshclam.conf is working. Check http://www.clamav.net/doc/mirrors-faq.html for possible reasons.

Natürlich hatte ich schon am Anfang auf diesen Link geklickt. und war bei der Installationsanleitung gelandet. Jetzt habe ich mir die Mirrors-FAQ nochmal heraus gesucht und folgendes gefunden: It is also possible that you recently had a prolonged network outage and freshclam blacklisted all the mirrors: remove mirrors.dat from the DatabaseDirectory and try again.

Na prima. Könntet ihr bitte Eure Links und Eure Mirrors fixen? Danke.

In den letzten Tages ist etwas geschehen, von dem ich nicht erwartete, es überhaupt zu erleben. Entsprechend erschüttert war ich, so erschüttert, dass mich die Kinder fragten, was denn los sei. AlphaGo hatte das dritte Spiel gegen Lee Sedol gewonnen. Aber nicht der Gewinn des Spiels war mein Problem, sondern die Art und Weise: Der Mensch hat anscheinend fehlerfrei gespielt, die Maschine dagegen hat mit unerklärlichen Zügen gewonnen.

Künstliche Intelligenz

Was ist das Besondere an einer Maschine, die Go spielt?

Im Gegensatz zu vielen anderen Spielen (auch Schach), sind die Varianten des Spieles so unüberschaubar, dass man Go eher aus dem Gefühl heraus spielt, als einem logischen Weg zu folgen. Man bewertet eine komplexe, unübersichtliche Situation nach intuitiven Maßstäben und handelt aus dem Bauch heraus.

Go_board

Von Donarreiskoffer - Selbst fotografiert, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=43383

Im Go zu brillieren heißt also, über eine hervorragende Intuition zu verfügen und mit sicherem Bauchgefühl zu spielen. Das sind normalerweise nicht die Merkmale, die man einem Computerprogamm zuschreibt.

In diesem Sinne ist AlphaGo auch nicht programmiert, sondern trainiert worden. Das Programm ist so aufgebaut, dass es eine Art Gehirn nachbildet und dieses Gehirn lernt dann über eine längere Zeit anhand von Beispielen und konkreten Vorgaben.

Die Vorgaben waren bei AlphaGo der Schlüssel zum Erfolg. Man hatte dem Programm eine Art Instinkt eingesetzt, der es ihm ermöglichte die Spielzüge zu verstehen, die normalerweise nie ausgespielt werden.

Denn Go ist ein Spiel der Andeutung: Man spielt praktisch nie die Konsequenzen bis zum bitteren Ende. Die Spielstellungen bleiben halbfertig auf dem Brett, Gebiete werden nicht gesichert, Angriffe nicht zu Ende gespielt. Ohne Konsequenzen ist aber das Lernen schwierig, denn die Korrektur falschen Verhaltens fehlt.

Das ist durchaus ein Problem der klassischen Pädagogik: Man muss sich nicht die Finger an der heißen Herdplatte verbrennen, mit der Gabel in die Augen stechen, oder mit dem Fahrrad vor die Hausmauer fahren, um gefährliches Handeln zu unterlassen. Dieser Teil des Lernprozesses ist rein abstrakt, er spielt allein mit der Vorstellung möglicher Folgen.

Bisherige Modelle der künstlichen Intelligenz, d.h. nach gebauten Gehirnen, wurden trainiert, indem sie ein komplettes Handlungsbeispiel vorgesetzt bekamen und für die korrekte Handlung belohnt, für eine fehlerhafte Handlung bestraft wurden. Das simulierte Gehirn hat dann die günstigen Verbindungen bevorzugt und die ungünstigen Vernetzungen abgebaut. Ganz wie in einem menschlichen Gehirn.

Bei AlphaGo wurde das Programm mit Beispielpartien von Go-Wettkämpfen gefüttert. Um das Spiel der Andeutungen verstehen zu können, ist es aber notwendig, den angedeuteten Gedanken zu Ende führen zu können und das wurde dem Programm für eine Reihe elementarer Fälle fest einprogrammiert. Auf diese Weise konnte die Software eine völlig klare Spiel-Situation final und korrekt beurteilen. Allein aus dem Training heraus wäre das mangels zu Ende gespielter Beispielpartien nicht erlernbar gewesen.

Künstliche Intelligenz ist also eine Gehirnsimulation, die in der Lage ist, Verhalten durch Training zu erlernen.

Verstehen, was passiert

AlphaGo ist bei weitem nicht der erste Versuch, mit einer künstlichen Intelligenz zu arbeiten. Das Forschungsgebiet ist schon sehr alt. Es wird normalerweise betrieben, um zu verstehen, wie Denkprozesse ablaufen.

Ein Beispiel: Google versucht – wie viele andere Unternehmen auch – Bilder zu verstehen. Dabei geht es darum, in Worte zu fassen, was auf dem Bild dargestellt ist. Für uns Menschen eine einfache Aufgabe. Für einen Computer ein ernsthaftes Problem.

Das entsprechende Forschungsprojekt von Google zeigte prima Ergebnisse: 

dog_with_hat

Wofür man das brauchen kann, ist auch völlig logisch: Ein autonomes Fahrzeug muss seine Umgebung wahrnehmen können.

traffic_google

Das eigentlich Interessante daran, ist die Art, wie der Computer zu diesen Ergebnissen gekommen ist. Dazu wird das simulierte Gehirn genau untersucht.

Es stellte sich heraus, dass die Bilderkennung in mehreren Schichten abläuft:

  • Zuerst werden Kanten ermittelt
  • dann werden die Kantenlinien zu bestimmten Mustern gruppiert, wobei die Orientierung nicht mehr wichtig ist
  • die Muster werden zu größeren Gruppen zusammengefasst
  • und die Gruppen im Verhältnis des Gesamteindrucks (was ist alles auf dem Bild?) kategoriersiert

Witzigerweise kann man die ersten Schritte auch vernünftig visualisieren und verstärken. Dabei entstehen ästhetisch ansprechende Bilder (in einem frühen Stadium) oder verstörendende Überlagerungen (in die späteren Schritten). Gerade letztere haben dem Algorithmus den Namen DeepDream eingegeben. Es hat nämlich den Eindruck, als ob Computer träumen.

ibis

Wirklich nützlich dagegen sind die überraschenden Einsichten, was so ein Computer genau gelernt hat. Am Beispiel einer Hantel hatte die Maschine nämlich ganz andere Dinge für wichtig erachtet als der Mensch.

dumbbells

Man sieht deutlich, dass der Computer den Arm des Kraftsportlers als integralen Bestandteil der Hantel ansieht. Schließlich hat man das Programm mit hunderten Fotos aus Fitness-Studios trainiert. Und dem Computer fehlt das notwendige Verständnis, den Arm als irrelevant weg zu lassen.

Im Ganzen gesehen, ist bis hierher nichts besonders überraschend. Der Mensch hat sich Hilfsmittel gebaut, die schnell und zuverlässig eine Aufgabe erledigen. Er versteht, was dabei passiert und kann im Zweifel die Vorgänge im Einzelnen überprüfen.

Der Schreck

Schon nach den ersten Partien zwischen AlphaGo und Lee war die Überraschung groß. Denn AlphaGo spielte ungewöhnlich.

Eine Maschine, die Millionen von Partien gegen sich selbst gespielt hat, kann durchaus feststellen, welche Züge bisher nicht genügend Beachtung gefunden haben und diese einfach mal ausprobieren. Das Ergebnis ist dann ein ungewöhnlicher Spielzug, der einen menschlichen Gegner verunsichern kann. Der Mensch beurteilt die Situation dann falsch und verliert. An dieser Stelle kann man von dem Programm lernen, den menschlichen Erfahrungsschatz erweitern und die neuen Züge analysieren.

Im dritten Spiel trat aber etwas mehr als ungewöhnliches auf: Die Kommentatoren war plötzlich der Meinung, die Maschine spiele fehlerhaft, während der Mensch korrekt handle. Allerdings verlor der Mensch kurz darauf.

Das qualitativ Neue an der Situation ist, dass der Mensch nicht mehr erklären kann, was da eigentlich passiert ist. Und das macht Angst.

Eine künstliche Intelligenz, deren Entscheidungen sich unserem menschlichen Verständnis entziehen, hat etwas bedrohliches. Sie greift direkt die geistige Vormachtstellung des Menschen (in seinem eigenen Selbstverständnis) an.

Die Kommentatoren flüchten sich in emotionale Gebiete. Die Formulierung "Sie spielt wie eine Göttin" muss man sich auf der Zunge zergehen lassen. Der Kommentator hat die Maschine vermenschlicht und bewundert ihre Intelligenz. Man hört ebenfalls heraus, dass die Maschine "wusste, dass sie gewinnen werde".

Unplanbare Schritte

Völlig unabhängig davon, ob es gelingt diese Partien im Detail zu analysieren und die neuen Spielzüge zu verstehen, muss ein anderer Gesichtspunkt berücksichtigt werden.

Die Zwischenschritte, die eine künstliche Intelligenz durchschreitet, um an ihr Ziel zu kommen, sind nicht durch Training erlernt worden. Der Mensch hat der Maschine also nicht beigebracht, auf welchem Wege das Ziel zu erreichen ist. Die Maschine hat sich selbst den Weg zum Ziel überlegt.

Solange es sich um ein Brettspiel handelt, ist es unerheblich, wie eine Maschine handelt. Verlässt man aber das Spielfeld und kehrt in die reale Welt zurück, so muss man sich wirklich Gedanken machen.

Wenn eine solche künstliche Intelligenz damit beauftragt wird, autonom ein Auto zu fahren, welche Reaktionen soll sie in bestimmten, unübersichtlichen Situationen zeigen? Muss dann der Computer über Leben und Tod entscheiden? Diese Debatte läuft, aber sie behandelt den Fall immer noch unter dem Gesichtspunkt, wir könnten der Maschine an dieser Stelle Vorschriften machten. Das werden wir voraussichtlich nicht können. Weil wir die Maschinen dafür nicht mehr genau genug verstehen.

Wenn eine solche künstliche Intelligenz damit beauftragt wird, in einem Krankenhaus die Patienten zu überwachen (ja, das ist DeepMind) und zu medikamentieren, genügt uns dann eine 15% höhere Überlebenswahrscheinlichkeit als Erfolg? Oder wollen wir auch verstehen, warum bestimmte Patienten nicht durchgekommen sind? Vielleicht war deren Tod Voraussetzung für das Überleben anderer Kranker. Vielleicht deshalb, weil der Computer dort Anzeichen einer Infektionskrankheit gesehen hat, die sich im gesamten Klinikum auszubreiten drohte. Und da er über keine anderen Mittel verfügte, als die Medikamente zu dosieren, hat er diesen Zwischenstand in Kauf genommen.

Wenn eine solche künstliche Intelligenz damit beauftragt wird, die begehrten Studienplätze in Deutschland gerecht zuzuteilen, warum sollte sie nur auf den Notendurchschnitt schauen? Warum sollte sie nicht auch ein gesamtgesellschaftliches Ziel berücksichtigen und damit die jungen Leute an den Ort schicken, wo sie aus Sicht des Computers am nützlichsten sind. Oder warum sollte nicht auch in die Entscheidung einfließen, wie hoch die Wahrscheinlichkeit eines Studienabbruchs ist? Wer kann denn hinterher kontrollieren, auf welche Weise die Maschine zu dieser Auswahl gekommen ist?

Was mir also ernsthafte Bauchschmerzen bereitet, ist eine Tatsache: Die von der künstlichen Intelligenz angesteuerten Zwischenschritte unterliegen keiner ethischen Kontrolle, sondern ausschließlich der Nützlichkeit bei der Erreichung des Zieles.

Genau dieser Punkt hat die Kommentatoren des dritten Spiels von AlphaGo gegen Lee Sedol verunsichert. Während Herr Lee die Komplexität des Go-Spiels anhand langer Traditionen auf einige wenige zulässige Gassen einschränkt, kennt die Maschine keine solchen Skrupel.

die_human

Und wir erleben soeben den Punkt, an dem wir unsere eigene Schöpfung nicht mehr verstehen. Ein Punkt, den ich nicht zu erleben glaubte.

Ich habe also Asimov gelesen.

Der Bug mit fragmentieren IPSec Paketen in der ASA war ja laut genug durch die Presse gegangen. Aber nicht alle Systeme lassen sich so einfach aktualisieren.

Wo's klappt und wo nicht

Kein Problem stellen die Failover-Systeme da, die noch in der 8er Reihe verharren. Der Update des erfolgt ganz planmäßig

  • Software auf Standby-Gerät spielen
  • Standby booten
  • Failover tiggern
  • Testen, ob alles geht
  • Software auf (nun anderes) Standby-Gerät spielen
  • (anderes) Standby booten

Kunde merkt davon gar nichts. Das war machbar, sobald die neue Firmware zur Verfügung stand.

Schwieriger wurde es bei Geräten, für die keine Software mehr existiert (PIX) oder noch die neue Software nicht korrekt funktionierte (CSCuy28710).

Als Notlösung wurde dort die ACL auf der Control-Plane so gesetzt, dass UDP/500 und UDP/4500 nicht mehr schaden konnten:

object-group service ike-udp
 service-object udp destination eq isakmp
 service-object udp destination eq 4500
!
object-group network ike-peers
 network-object host b.c.d.e
!
access-list to_cpu extended permit object-group ike-udp object-group ike-peers any
access-list to_cpu extended deny object-group ike-udp any any log warnings
access-list to_cpu extended permit ip any any log warnings
!
access-group to_cpu in interface outside control-plane 

In der Object-group iks-peers stehen die bekannten Gegenstellen, die noch VPN-Tunnel aufbauen dürfen. Das skaliert natürlich nicht besonders gut für VPN-Einwahl, reicht aber für alles aus, was nur Lan2Lan-Tunnel hat. In jedem Fall nimmt es Druck aus dem Problem.

Schrittweiser Upgrade

Cisco empfiehlt bestimmte Versionenpfade einzuhalten, um automatische Übernahmen der alten Konfigurationen zu ermöglichen. Da das Ergebnis dieser Übernahmen meist zu schrecklich ist, um es so zu lassen, ziehe ich es vor, eine minimale Konfiguration zum Upgrade zu verwenden. Diese lässt auch größere Sprünge zu, solange nur die IP Konfiguration der Interfaces und der SSH Zugang erhalten bleiben.

Beim Versuch von 9.1(1) auf 9.1(7) zu springen, scheitert das an der Fehlermeldung

asa# copy /noconfirm tftp://2001:db8::67/asa917-smp-k8.bin flash:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
No Cfg structure found in downloaded image file 

Diese Meldung kommt also, bevor das Image aufs Flash geschrieben werden soll. Da er das Image nicht in den Flash legt, kann er auch nicht davon booten.

Dieses Problem ist aber wohl dokumentiert, man muss eben einen bestimmten Upgrade-Pfad einhalten.

asa# copy /noconfirm tftp://2001:db8::67/asa912-smp-k8.bin flash:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
No Cfg structure found in downloaded image file 

Was jetzt? Das ist genau das Image, das verwendet werden soll, um diesen Fehler nicht zu bekommen. Auch andere Versuche mit neueren Images führen zu keinem Erfolg: Das aktuell laufende System weigert sich, ein neues Image abzuspeichern! Der Fehler ist seit gestern auch bei Cisco bekannt: CSCuh25271

Aber Moment mal: Das aktuell laufende Image?

Was wäre denn, wenn ich das Image einfach so laden würde. Also irgendwie in die Box reinmogeln (per USB?) und dann davon booten. Das sollte doch gehen?!

Konkreter gefragt: Was wäre, wenn das aktuell laufende Image nicht da wäre? Dann würde sich auch niemand darüber aufregen, dass irgendwelche Strukturen fehlen. Oder etwa doch?

Wenn kein laufendes Image da ist, fällt man auf den ROMMON zurück. Aber den kann man beim Booten auch direkt aufrufen und dann ein Image vom TFTP laden und starten.

Gesagt getan: Es funktioniert.

Einfach so. Und dann kann man auch alle anderen Images aufs Flash installieren.