News Bahnfunk-Störung: Wenn ein Update den Bahnverkehr stoppt

[Child]

Na gut. Mal abgesehen davon, dass wir alle (also alle deutschen Staatsbürger) Teil des Staates sind, ist das Ergebnis hier ein Resultat aller Wahlen über die letzten 30 Jahre (und mehr). Nie war "die Schiene" unter den Wählern so wichtig, dass eine Partei diese zu einem zentralen Thema gemacht hätte und dann damit auch tatsächlich Stimmen einsammeln konnte. Die Bahn war so immer ein von der Politik stiefmütterlich behandeltes Feld mit wechselnden Prioritäten.

 

[eYc]

Das haben wir jetzt glaube ich schon oft genug gehört.

Die Bahn konzentrierte sich in den letzten Jahren meiner Meinung nach mehr darauf, kostenloses WLAN zur Verfügung zu stellen, Steckdosen zu verbauen zum Handy-aufladen überall da wo's keiner braucht, und Züge bei 18 °C Außentemperatur auf 15 °C runterkühlen zu können, so dass man selbst bei den jetzigen Temperaturen immer ein Sweatshirt oder ein Jäckchen mitnehmen muss.

Aber Personen befördern ... geht gar nicht (mehr)!?
Wenn's dann mal heiß ist fällt die Klimaanlage aus (am letzten Samstag wieder erlebt, zusätzlich zu "Zug fällt aus" bei den Verbindungen mit RE1 zwischen Nürnberg u. München, und PLUS 2 Stunden für die Rückfahrt).

 

[Child]

heiß ist fällt die Klimaanlage aus

Auch komm. Das ist ja märchenhaft. Der Standard ist doch eher: Klima kaputt, Wagen fehlen (nur einer von normalerweise drei) und außerdem tut nur eine Tür Mal abgesehen davon, dass der Zug heute von Gleis 2 anstatt 8 abfährt und an der übernächsten Station aufgrund eines medizinischen Notfalls (Fahrgast umgekippt im unklimatisierten und total überfüllten Zug) die Fahrt für längere Zeit unterbricht. Wobei hier Grüße rausgehen an @Averio. Das hat jetzt erstmal nichts mit der deutschen Bahn an sich zu tun

 

[Kowa]

Die Boomer sind weg und die Gen-X geht langsam in Rente. Vor 25 Jahren hat man bei uns im Datacenter die Server aufgebaut und genau überlegt, welchen Dienst man einrichten will, was ist verzichtbar, welche Single points of failure sind zu befürchten. Die technischen User wurden noch in die passwd eingetragen und die IP-Adressen in die hosts-Datei, die Platten waren zwar in separaten Boxen untergebracht, aber noch direkt per Glasfaser an die Server gesteckt, über Kreuz mit 2 Switches.
Dann folgte die Enshitification. Zentrales DNS, was prompt eine Woche nach Einführung eine Störung hatte und für einen langen, nächtlichen Noteinsatz sorgte. Die Platten wurden zum software defined storage und die damit verbundenen langen Latenzen bremsten die Datenbank aus. Lediglich an einen Ausfall vom LDAP kann ich mich nicht erinnern. Irgendwann versagte das Storagesystem, obwohl die Prod-systeme gespiegelt sind und wir verloren 2 Tage bis wir den Ausfall wieder aufgeholt hatten. Nach einem Desaster Recovery hinen unsere Platten an einem anderen Standort und die Performance der Datenbank sank auf 1/5 und verursachte stundenlange verzögerungen.
Dann kam die Seuche der Middleware. Bea-Weblogic. Ständige Updates im Framework, in Verantwortung des Middleware-Teams. Mindestens 3x ging dabei die LDAP-Authentifizierung in die Brüche. Heute haben wir Container, Openshift und Deploy-Pipelines, welche einen Fehler in der Nacht regelmäßig zu einem unlösbaren Problem machen, bis tagsüber der Entwickler erreichbar ist.
Bei der nachwachsenden Projektmanager-Generation scheint Agile auch in Vergessenheit zu geraten. Es werden jahrelange Wasserfallprojekte geplant, die niemand mehr überblicken und testen kann.
Genau so scheint es hier auch gelaufen zu sein, wenn eine kritische Infrastruktur im ganzen Land gleichzeitig ein Update erfährt.

 

[DX8]

Wie das erst tin Zukunft alles abgehen wird.. ja gute Nacht...

 

[Ranayna]

Der Durschnitt (über die letzten 20 Jahre) der jährlichen Investitionen in die Schiene liegt in Deutschland bei der Hälfte von dem, was Japan pro Kopf jedes Jahr investiert hat. Schweiz und Österreich liegen da nochmal deutlich darüber.

Das irritiert mich bei so vielen Presseberichten zu dem Vorfall...
So viele sagen einfach nur: Andere Laender - und Japan und die Schweiz sind da die haeufigsten genannten - koennen das besser, warum scheitert Deutschland?
Das diese Laender wesentlich mehr Geld in die Bahninfrastruktur investieren wird mit keiner Silbe erwaehnt...

Ich kann mich an einen Artikel erinnern wo berichtet wurde das in den ICE‘s Systeme mit Win3.11 laufen und das man „Experten“ sucht um diese System zu warten….wo war er denn nur gleich….

Na klar reisst man quasi die gesamte Bordtechnik aus den ICEs, um ein modernes Betriebsssytem auf den Steuerrechnern zu installieren...
So einen Zug kann man dahingehend gut mit einer Industriemaschine vergleichen. Da laufen oft auch absolut veraltete Betriebssysteme auf den Steuerrechnern. Die Steuerungen sind in der Regel derartig speziell programmiert, dass sie auf die "Eigenheiten" des jeweiligen Betriebsystems angewiesen sind und man nicht einfach upgraden kann. Einige Hersteller verbieten sogar Patches.

Was in der Regel auch garnicht so ein massives Problem ist, wenn die Maschinen im Netzwerk sauber isoliert werden koennen.
Es bringt aber halt mit, dass wenn der Lebensyklus der Maschinen lang genug ist, dass man halt Leute braucht die sich damit auskennen. Und wenn deren Windows 3.11 Hauptexperte kurz vor der Rente steht... Dann wird halt ein neuer gesucht.

 

[PhiE]

Artikel-Update: Die Deutsche Bahn hat die Ursache der bundesweiten Funkstörung inzwischen konkretisiert. Demnach kam es am Dienstagabend bei planmäßigen Instandhaltungsarbeiten zum Tausch eines Switches, also einer Netzwerkkomponente. Dabei sei ein „singulärer Softwarefehler“ aufgetreten, der keine Fehlermeldung erzeugte. Bei dem in den letzten Tagen gerne zitierten Begriff handelt es sich allerdings nicht um eine gebräuchliche Wortwahl aus dem IT-Wörterbuch – gut klingen tut er aber. Gemeint ist vermutlich ein (bisher) einzigartiges Problem. Die Redundanz des GSM-R-Systems war laut DB jedenfalls vorhanden und funktionsfähig, wurde wegen der fehlenden Fehlermeldung aber nicht automatisch aktiviert.

Die Erklärung ist aus technischer Sicht bemerkenswert: Ein einzelner Softwarefehler konnte offenbar dazu führen, dass eine sicherheitsrelevante Funktion ausfiel. Die Rückfallebene stand zwar bereit, wurde aber erst nach manuellem Eingriff aktiv. Zuvor musste nach Angaben der DB regelkonform ein Cyberangriff ausgeschlossen werden. Nach rund 90 Minuten wurde manuell auf die Rückfallebene umgeschaltet.

Dafür, dass sich so etwas nicht wiederholt, hat die DB neue Regeln eingeführt. Künftig werden Instandhaltungsarbeiten nur noch nachts zwischen 0 und 4 Uhr sowie ausschließlich in der inaktiven Redundanz durchgeführt und erst danach in die produktive Umgebung übernommen.

 

[msv]

Artikel-Update: […] Die Rückfallebene stand zwar bereitstand, wurde aber erst nach manuellem Eingriff aktiv. […]

Ein „stand“ zu viel.

 

[Manegarm]

Die Boomer sind weg und die Gen-X geht langsam in Rente.

Die Zeiten harter und viel Arbeit sind vorbei. Das merkt man auch täglich wenn man Baustellen beobachtet, Stück Straße von vielleicht 100m dauert mittlerweile ein 3/4 Jahr. Die Bauarbeiter sind täglich da. Es passiert aber nichts.
Wir sind heute das was Spanien, Italien, Marroko, China usw vor 30 Jahren war. Langsam, keine Lust auf Arbeit.
Und natürlich stand heute zu wenig Leute. Deutschland wird noch richtig am Arsch sein, da ist das von heute nichts dagegen.

 

[PC-Zocker]

Typisch Deutschland...
Wir sind am Ende. Bald bekommen wir Fresspakete aus dem Kongo.

 

[LucasAppelmann]

Künftig werden Instandhaltungsarbeiten nur noch nachts zwischen 0 und 4 Uhr sowie ausschließlich in der inaktiven Redundanz durchgeführt und erst danach in die produktive Umgebung übernommen.

Genau das hätte ich doch bereits als die Standard-Vorgehensweise angenommen? Erst wird der "Backup"-Teil aktualisiert, bei Erfolg darauf umgeschaltet (PROD ist danach BACKUP) und dann die ursprüngliche Produktionsumgebung mit dem Update versehen. Wenn schon keine Testumgebung bereitsteht.

 

[PhiE]

Ein „stand“ zu viel.

Danke ;-)

 

[PhiE]

Genau das hätte ich doch bereits als die Standard-Vorgehensweise angenommen?

So kenne ich es aus meiner hauptberuflichen Tätigkeit auch nicht anders ^^
Schon bemerkenswert. Was es genau für ein Switch war stand nirgends, aber es muss irgendwas Hohes in der Hierarchie gewesen sein. Dass sich der Netzwerkverkehr dann nicht trotzdem einfach eine andere Route sucht, finde ich auch merkwürdig.

 

[von Keks]

Es ist keine Fehlermeldung erzeugt worden und deshalb das Backupsystem nicht angesprungen. Es mag an der Hitze liegen das mein Hirn langsamer arbeitet, aber wenn doch keine Antworten von dem Zug / Stellwerk / etc. mehr an das System geleitet werden ist das doch ein Fehler...

Für mich sind hier die Fälle wann das BU-System einspringt nicht dediziert genug hinterlegt worden.. Keine Antwort, schalte mal lieber um anstatt keine Antwort? Who cares..

Und komisch das das Verfahren JETZT umgestellt wird, dachte das wäre schon Standard.

 

[LucasAppelmann]

Was es genau für ein Switch war stand nirgends, aber es muss irgendwas Hohes in der Hierarchie gewesen sein. Dass sich der Netzwerkverkehr dann nicht trotzdem einfach eine andere Route sucht, finde ich auch merkwürdig.

Das kann einiges gewesen sein - wir hatten mal eine falsche Zuordnung im STP und das ging dann auch "ohne Fehlermeldung" aus, weil einfach ein neuer Baum aufgebaut wurde - Traffic lief danach trotzdem keiner, weil wir verschiedene STP-Domains hatten, aber für den Switch sah das eben so aus, als wäre das so gewollt.

 

[xexex]

@PhiE

Die Erklärung ist aus technischer Sicht bemerkenswert: Ein einzelner Softwarefehler konnte offenbar dazu führen, dass eine sicherheitsrelevante Funktion ausfiel. Die Rückfallebene stand zwar bereit, wurde aber erst nach manuellem Eingriff aktiv.

Nichts ist daran "bemerkenswert". Aus 30 Jahren IT Erfahrung kann ich locker behaupten, bei redundanten Systemen kommt es mehr als häufig vor, dass gerade diese Redundanz für die Nüsse ist.

Ich hatte schon Server mit redundanten Netzteilen, bei denen reihenweise die Netzteilbackplanes ausgefallen sind. Clustersysteme die meinten mitten im Betrieb einen Failover ausführen zu müssen, weil irgendwelche Netzwerkstrecken gestört waren und natürlich auch Systeme die beharrlich meinten es sei alles in Ordnung, ein Failover sei nicht notwendig obwohl das System nicht mehr antwortete. Von redundanten Storage Systemen, die sich bei einem Rebuild oder Failover komplett weggeschossen haben, reden wir gar nicht erst.

Redundanz ist kein Garant für Hochverfügbarkeit, und ein automatisches Failover versagt gerne dann wenn es um was geht, selbst wenn man meint schon alle Szenarien regelmäßig durchgespielt zu haben.

 

[LucasAppelmann]

Redundanz ist kein Garant für Hochverfügbarkeit, und ein automatisches Failover versagt gerne dann wenn es um was geht, selbst wenn man meint schon alle Szenarien regelmässig durchgespielt zu haben.

Ja, eher die Hoffnung auf Hochverfügbarkeit.

Und das mit "schon alle Szenarien durchgespielt" - dann schafft es im Ernstfall ein Szenario einzutreten, an das vorher trotz aller Mühen niemand gedacht hatte. Oder das, was nach allen Erkenntnissen eben so unwahrscheinlich war, dass für die 0,01% niemand nochmal zigtausend Euro investiert hätte. Murphy eben, man kann an alles denken und dann kommt trotzdem noch das Undenkbare.

 

[Sebbi]

Dabei sei ein „singulärer Softwarefehler“ aufgetreten, der keine Fehlermeldung erzeugte. Bei dem in den letzten Tagen gerne zitierten Begriff handelt es sich allerdings nicht um eine gebräuchliche Wortwahl aus dem IT-Wörterbuch – gut klingen tut er aber. Gemeint ist vermutlich ein (bisher) einzigartiges Problem. Die Redundanz des GSM-R-Systems war laut DB jedenfalls vorhanden und funktionsfähig, wurde wegen der fehlenden Fehlermeldung aber nicht automatisch aktiviert.

ich als ITler ließt sich das so:

Der Switch hat empfangene Packete korrumpiert oder hat selbst Packete versendet, die anderen Netzwerkgeräte aus dem Tritt gebracht haben.
Das passiert gerne bei billig China Schrott haben wir bei uns festgestellt, als wir nach Alternativen für die bisher verwendeten D-Link und Cisco Desktop Switche, bei den Anwendern gesucht hatten, da diese höhere Ausfallraten gezeigt haben. Schlussendlich sind wir bei Netgear gelandet und ersetzen nun nach und nach

 

[LucasAppelmann]

Schlussendlich sind wir bei Netgear gelandet und ersetzen nun nach und nach

Bei uns wurden aus ähnlichen Gründen Netgear-Switches ersetzt, auch hier ist wieder keine Lösung für Alle passend.

Das passiert gerne bei billig China Schrott haben wir bei uns festgestellt

ZyXel, anyone? Die haben wir aus Gründen mal angeschafft, danach durfte man sie aber quasi nicht mehr anfassen, weil sie gerne mal überraschend reagiert haben. Die darf ich jetzt auch ersetzen, aber Achtung: im laufenden Betrieb (bzw. im Wartungsfenster) mit Beibehaltung der Redundanz.

Hoffentlich kommt da nicht mein Bahn-Moment ;-)

 

[Shio]

Das es 90 Minuten dauert bis der Failover MANUELL aktiviert wurde, sollte eigentlich Grund genug sein in dem Verantwortungsbereich das Personal und die Workflows aufzuräumen.
Das geht echt überhaupt nicht in meinen Kopf wie das überhaupt so lange dauern kann.