Netzwerkstörungen / network disruptions


English version below (sent to all customers via e-mail)

Sehr geehrte Damen und Herren,

im folgenden Rundschreiben möchten wir Sie - ergänzend zu den bisherigen Informationen - über die Netzwerkstörungen vom 20. sowie 22.03.2020 informieren, welche für die meisten betroffenen Kunden Erreichbarkeitsprobleme über etwa 20 Minuten am Freitag beziehungsweise 15 Minuten am Sonntag verursachten.

Wie Sie wissen, ist uns eine transparente Kommunikation gerade im Störfall sehr wichtig, weshalb wir um Verständnis dafür bitten, dass die Informationen vergleichsweise umfangreich und technisch ausfallen. Nach der Schilderung der zeitlichen Abläufe beziehen wir Stellung zu den Maßnahmen, die wir getroffen haben und treffen werden.

20.03.2020:

Ab 21 Uhr: Unser Monitoring meldet erhöhte Latenzen zu einzelnen Zielen. Kundenmeldungen gehen keine ein - die Probleme treten noch drei- bis viermal auf, jedoch immer nur für wenige Sekunden und sind daher außerhalb unseres Monitorings praktisch nicht feststellbar. Betroffen sind völlig unterschiedliche IP-Netze und VLANs, insgesamt rund 10% der von uns überwachten Hosts. Wir investigieren.

Ab 22 Uhr: Wir identifizieren zum Zeitpunkt der Probleme sehr kurze Lastspitzen auf dem Core-Router. Allerdings lassen sich diese weder irgendwelchen Logeinträgen noch bestimmten Prozessen zuordnen. Wir entscheiden uns daher dazu, die Last auf dem Router über verschiedene Maßnahmen zu senken, um zunächst zu prüfen, ob sich die Situation dadurch bessert. Dies involviert unter anderem die Umstellung aller internen wie externen Uplinks auf passives LACP sowie das Erhöhen des ARP-Aging-Timers.

22:24 Uhr: Wir committen die angepasste Konfiguration.

22:25 Uhr: Nach Abschluss des Commits verlieren wir die Netzwerkkonnektivität sowohl zu unseren Servern als auch zum Router selbst.

22:26 Uhr: Das Problem wird durch den Bereitschaftshabenden an einen weiteren Netzwerkadministrator eskaliert. Alle kritischen Netzwerkkomponenten sind bei uns über ein unabhängig geroutetes Management-Netz auch dann erreichbar, wenn diese selbst über keine Netzwerkverbindung mehr verfügen. Hierzu nutzen wir die seriellen Schnittstellen der Geräte, die wir über einen unabhängigen Server per SSH erreichbar machen.

22:28 Uhr: Der hinzugezogene Netzwerkadministrator führt über die serielle Konsole einen Rollback auf die vorherige Konfiguration durch. Der Rollback funktioniert und stellt die Erreichbarkeit binnen weniger Minuten wieder her.

22:35 Uhr: Der Geräteverbund zeigt erneute Paketverluste und verliert beim Versuch eines Commits die Verbindung zu beiden Routing Engines. Wir entscheiden uns notgedrungen zu einem Notfallreboot des gesamten Verbundes, da ein Arbeiten auf diesem nicht mehr möglich ist.

22:40 Uhr: Noch während der (sauber entgegengenommene) Reboot läuft, startet eine der Routing Engines wieder, der Verbund führt einen Failover auf die “reaktivierte” Engine durch und der Traffic fließt wieder einwandfrei. Leider lässt sich der Reboot nicht mehr stoppen, sodass je nach Netzbereich weitere fünf bis zehn Minuten Downtime entstehen.

22:50 Uhr: Der Reboot ist abgeschlossen, eines der Geräte startet jedoch nicht mehr und steht im Bootloader. Wir entsenden einen der vor Ort ansässigen Mitarbeiter ins Rechenzentrum. Das Netzwerk ist vollständig stabil, verfügt jedoch nicht über die volle Redundanz. Der Mitarbeiter trifft 15 Minuten später ein.

23:30 Uhr: Nach mehreren Kaltstarts und längerer Stromlosigkeit startet das vermeintlich defekte Gerät wieder, die Eingliederung in den Verbund verläuft absolut fehlerfrei. Alle Port-Channels verfügen wieder über die volle Bandbreite, ebenso unsere Außenanbindung. Aus Sicherheitsgründen lassen wir die aktive Routing Engine auf dem identischen Zweitgerät weiterlaufen und probieren keinen Failover auf das zuvor ausgefallene Gerät.

21.03.2020: Es finden mehrere Meetings mit den involvierten Kollegen zur Nachbereitung statt, Logeinträge werden gesichtet und Untersuchungen durchgeführt. Das Netzwerk läuft 100%ig stabil. Wir gehen davon aus, dass der mutmaßliche Hardwaredefekt verantwortlich für die Probleme war und planen den Austausch des Gerätes in der Folgewoche.

22.03.2020:

17:30 Uhr: Die Symptome von Freitagabend wiederholen sich; auch hier sind die Lastspitzen so kurz, dass uns zunächst keine Kundenmeldungen vorliegen. Unser Monitoring bemerkt sie jedoch und wir investigieren. Die Vermutung liegt nahe, dass das vermeintlich defekte Gerät für Probleme sorgt. Wir evaluieren sowohl die weitere Umsetzung der am Freitag definierten Maßnahmen als auch die Entfernung des Gerätes aus dem Verbund.

19:15 Uhr: Die Probleme häufen sich schlagartig, plötzlich sind rund 2% der von uns überwachten Ziele nicht mehr erreichbar. Die Störung betrifft drei verschiedene Netzwerksegmente, ein Muster ist nicht erkennbar. Der Bereitschaftshabende eskaliert den Vorfall an alle verfügbaren Kollegen.

19:28 Uhr: Im Rahmen eines sofortigen Notfallmeetings können erstmals konkrete Fehlermeldungen des Kernels der Routing Engine beobachtet werden. Warum diese zuvor nicht auftraten, ist Gegenstand der weiteren Untersuchungen. Die Meldungen decken sich mit dem beobachteten Verhalten, dass die Server, die offline sind (die zuvor benannten 2%), vom Router keine Antwort auf ARP-Requests erhalten. Wir entscheiden uns nach Abwägung aller vorliegenden Informationen zur Deaktivierung von IPv6 in einem Netzwerksegment (betreffend unsere vServer-Generationen SSD G1 und SSD G2), um die Belastung des Routers durch (statische) Routen testweise deutlich zu senken.

19:31 Uhr: Beim Committen der neuen Konfiguration stellen sich entgegen der erwarteten Entlastung und somit Verbesserung Erreichbarkeitsprobleme im gesamten Netzwerk ein.

19:37 Uhr: Das Netzwerk hat sich größtenteils stabilisiert, einige IP-Adressen bleiben jedoch offline. Wir evaluieren die Optionen, die wir haben, und kündigen als “Ultima Ratio” einen Notfallreboot der Geräte an, da ein Arbeiten auf diesen kaum noch möglich ist.

19:43 Uhr: Als letzte Option vor dem Reboot probieren wir einen händischen Failover auf die sekundäre Routing Engine. Der Vorgang funktioniert wie erhofft.

19:46 Uhr: Alle Netzwerkbereiche sind wieder stabil, mit Ausnahme der nun deaktivierten IPv6-Netze der vServer-Generationen SSD G1 und SSD G2. Wir bereiten einen Ersatz-Router vor, um die Netze dorthin zu migrieren.

20:33 Uhr: Die betroffenen IPv6-Netze sind vollständig auf den neuen Router migriert und laufen wieder.

23.03.2020: Das Netzwerk läuft 100%ig stabil, wir planen die nächsten Schritte.

Nachfolgend möchten wir die Fragen beantworten, die Sie und uns beschäftigen, und in diesem Zuge insbesondere darlegen, wie wir kurz- und langfristig mit dem Vorfall umgehen.

Warum traten die Probleme trotz Redundanz auf?

Sämtliches von uns verwendetes Netzwerkequipment stammt vom renommierten Hersteller Juniper Networks. Switches und Router arbeiten bei uns stets in einem Zweierverbund aus identischen Geräten, wobei sich dieser dann wie eine Einheit verhält. In einem solchen Verbund stellt eines der Geräte die primäre (aktive) Routing Engine. Fällt dieses Gerät aus, übernimmt die sekundäre Routing Engine (also das Zweitgerät) den Betrieb innerhalb einiger Sekunden. Dieser Failover-Prozess funktioniert jedoch mitunter nicht mehr wie vorgesehen, wenn es Probleme seitens des Betriebssystems (Junos OS) gibt, was beispielsweise aufgrund eines Firmware-Bugs auftreten kann, oder ein partieller beziehungsweise schleichender Hardwaredefekt vorliegt. In diesem Fall kann ein manueller Eingriff erforderlich sein. Das Gerät, welches Freitagabend nicht mehr bootete, zeigte bei einer Störung im vergangenen Sommer (wir berichteten) schon einmal dasselbe Problem nach einem Neustart. Wir hatten dieses damals selbstverständlich ausgebaut und in die RMA geschickt, repariert zurückerhalten und wieder in den Verbund eingegliedert. Aufgrund des erneuten Auftretens werden wir das Gerät nun vollständig ersetzen. Leider verging seit der Wiedereingliederung so eine lange Zeit, dass ein Defekt aus unserer Sicht nicht zu erwarten war. Wir prüfen, welche Erweiterungen unseres Monitorings insbesondere im Bereich der Logfile-Analyse umsetzbar sind, um mögliche Probleme noch schneller als bisher zu erkennen. Einige Schwellwerte wurden nach Auswertung historischer Daten bereits reduziert.

Warum verursachten die IPv6-Netze ein derartiges Problem und wie wird damit langfristig umgegangen?

Wir müssen nun zunächst abwarten, ob das Netzwerk nach Migration der IPv6-Netze auf den anderen Router stabil bleibt, und sich die “Schuld” der Netze somit bestätigt. Derzeit ist insbesondere aufgrund der Logeinträge von Sonntag davon auszugehen (die eigentliche Störung am Freitag ist hingegen mit größter Wahrscheinlichkeit auf den beschriebenen Hardwaredefekt zurückzuführen). In dem fraglichen Netzwerksegment befinden sich aus historischen Gründen eine Vielzahl von IPv6-Netzen, die aufgrund einer bestimmten Konfiguration gegenüber später angelegten Netzen mehr Ressourcen benötigen. Zur langfristigen Entlastung haben wir bereits beginnend vor einem Jahr nur noch “ressourcenschonend” konfigurierte Netze vergeben und frei werdende alte Netze dekonfiguriert. Die sogenannte TCAM-Auslastung des Routers, die wir laufend überwachen, hat sich seitdem stets verbessert und befand sich schon lange in keinem kritischen Bereich mehr. Auf Basis des Datenblatts unserer Geräte sowie der überwachbaren Ressourcen lag also keine Überanspruchung vor - die jüngsten Ereignisse lassen aber, wie wir offen kommunizieren möchten, derzeit keinen anderen Schluss als eine temporäre Überlastung der Routing Engine zu. Das nun (offenbar) erreichte Limit kann also in Ermangelung von Informationen in den offiziellen Dokumenten bisher nicht nachvollzogen werden. Es befindet sich daher mit externen Juniper-Spezialisten in Klärung, ob ein Hardware-Upgrade dieses Problem nachhaltig lösen kann, also größer dimensionierte Geräte die hier spezifisch benötigten Ressourcen ebenfalls erweitern oder ob es sich um ein strukturelles Problem des Juniper-Betriebssystems handelt. Sollte sich aus der weiteren Untersuchung die Notwendigkeit einer Konfigurationsanpassung der betroffenen (vergleichsweise wenigen) Netze ergeben, führen wir diese in Zusammenarbeit mit den betroffenen Kunden durch und kontaktieren diese rechtzeitig.

Unabhängig vom Ergebnis der extern beauftragten Untersuchung planen wir gegenwärtig folgende Änderungen an unserer Netzwerkinfrastruktur:

- Upgrade auf Juniper-Router der neuesten Generation, um Ressourcenengpässe langfristig auszuschließen und weiterhin auf dem neuesten Stand der Technik zu arbeiten

- Vollständige Trennung der Routing- und Switching-Infrastruktur zur besseren Identifizierbarkeit von Problemen und weiteren Entlastung aller involvierten Geräte

- Erarbeitung eines Konzeptes, welches bei Störung eines Routers eine schnellere Umschaltung auf ein Ersatzgerät auch dann ermöglicht, wenn der automatische Failover nicht klappt, und die Tragweite einer Routerstörung möglichst auf einzelne Netzwerksegmente beschränkt

Diese geplanten Verbesserungen werden wir in den nächsten Wochen weiter ausarbeiten und Sie über notwendige Arbeiten rechtzeitig informieren. Aufgrund des Umfangs und der Wichtigkeit einer präzisen Planung rechnen wir mit dem Abschluss der Änderungen nicht vor Q3 2020. Der Austausch des vermeintlich defekten Gerätes wird selbstredend bereits in den nächsten Tagen erfolgen - auch dies kündigen wir rechtzeitig an.

Um die Kommunikation bei globalen Störungen zu verbessern, werden wir kurzfristig eine externe Statusseite online nehmen. Bisher erfolgt diese primär über unseren Twitter-Kanal - dieser ist zwar auf unserer Webseite in den Neuigkeiten eingebunden, allerdings ist diese bei einer allgemeinen Netzwerkstörung natürlich nicht zu erreichen. Nichtsdestotrotz wollen wir die Kommunikation per Twitter voraussichtlich (zusätzlich) beibehalten, da unsere Kunden dies seit über acht Jahren gewohnt sind, uns die direkte Kommunikation mit Ihnen bei Rückfragen sehr am Herzen liegt und wir so letztendlich auch mit Abstand am schnellsten eine erste Störungsmeldung absenden können (maximal wenige Minuten).

Wir bedanken uns für Ihre Aufmerksamkeit und stehen für eventuelle Rückfragen gerne zur Verfügung.

English version (CET timestamps):

Dear customers,

in the following circular letter we would like to inform you - additionally to the information already provided in German - about the network failures of 20. / 22.03.2020 which caused about 20 minutes downtime on Friday respectively 10 minutes on Sunday for most of the affected customers.

As you know, transparent communication is very important to us, especially in the event of a disruption, so we ask for your understanding that the information is relatively extensive and technical. After describing the incidents chronologically, we will inform you about the measures we have taken and will take in the future.

20.03.2020:

From 9 pm: Our monitoring system reports increased latencies to individual targets. No customer complaints are received - the problem occurs 3-4 times, but always only for a few seconds and are therefore practically undetectable outside our monitoring. Completely different IP networks and VLANs are affected, in total about 10% of the hosts we monitor. We are investigating.

From 10 pm: We identify very short load peaks on the core router everytime the problem occurs. However, it cannot be assigned to any log entries or specific processes. We therefore decide to reduce the load on the router by various measures to analyze if the problems disappear. This involves, among other things, switching all internal and external uplinks to passive LACP and increasing the ARP aging timer.

10:24 pm: We commit the customized configuration.

10:25 pm: After the commit has completed, we lose network connectivity to both our servers and the router itself.

10:26 pm: The problem is escalated to another network administrator by the on call employee. All critical network components are accessible via an independently routed management network, even if the components themselves lose their network connection. For this we use the serial interfaces of the devices, which we make accessible via SSH via an independent server.

10:28 pm: The network administrator rolls back to the previous configuration via the serial console. The rollback works and restores the availability within a few minutes.

10:35 pm: The router shows packet loss again and loses the connection to the routing engine while we commit a configuration change. We inevitably decide to perform an emergency reboot of the devices as we cannot work on them anymore.

10:40 pm: While the reboot is already running, one of the routing engines starts again, the unit performs a failover to the "reactivated" engine and the traffic flows again. Unfortunately, the reboot cannot be stopped anymore, so another five to ten minutes of downtime will occur (depending on the network segment).

10:50 pm: The reboot is completed, but one of the devices does not start anymore and is stuck in the bootloader. We send one of our own technicians to the data center. The network is completely stable, but does not have full redundancy. The colleague arrives 15 minutes later.

11:30 pm: After several cold starts, the supposedly defective device starts up again, and the integration into the router unit works absolutely flawless. All port channels have the full bandwidth again, as does our external connection. For safety reasons, we let the active routing engine continue running on the identical second device and do not try a failover to the previously failed device.

21.03.2020: There are several meetings with the involved colleagues for follow-up work, log entries are viewed and investigations are performed. The network runs 100% stable. We assume that the suspected hardware defect was responsible for the problems and plan to replace the device in the following week.

22.03.2020:

5:30 pm: The symptoms of Friday evening are repeating, the load peaks are so short that we do not receive any customer reports at first. However, our monitoring system notices them and we investigate. The assumption is that the supposedly defective device is causing problems. We evaluate both the further implementation of the measures taken on Friday and the removal of the device from the network.

7:15 pm: The problems accumulate, suddenly about 2% of the targets we monitor are no longer reachable. The disruption affects three different network segments, a pattern is not recognizable. The colleague on call escalates the incident to all available colleagues.

7:28 pm: In an immediate emergency meeting, concrete error messages from the routing engine kernel can be observed for the first time. Why these did not occur before is the subject of further investigations. The messages match the observed behavior that the servers that are offline (the previously mentioned 2%) do not receive a response to ARP requests from the router. After weighing all available information, we decide to disable IPv6 in a specific network segment (regarding our vServer generations SSD G1 and SSD G2) in order to reduce the load on the router caused by (static) routes significantly.

7:31 pm: When committing the updated configuration, packet loss in the entire network occurs (instead of the reduced load we were expecting in order to stabilize the network).

7:37 pm: The network has largely stabilized, but some IP addresses remain offline. We evaluate the options we have and announce an emergency reboot of the devices as "ultima ratio", since working on them is nearly impossible.

7:43 pm: As the last option before the reboot, we try a manual failover to the secondary routing engine. The procedure works as hoped for.

7:46 pm: All network segments are stable again, with the exception of the now deactivated IPv6 subnets of the vServer generations SSD G1 and SSD G2. We prepare another router to migrate the affected subnets to this replacement router.

8:33 pm: The affected IPv6 subnets are migrated to the new router successfully and are running again.

23.03.2020: The network is running 100% stable, we plan the next steps.

In the following we would like to answer the questions that are now on your mind (and ours as well), and we also want to give you an overview of the measures that has been taken but also those we plan for the future.

Why did the problems occur regardless of the redundancy?

All the network equipment we use comes from the well-known manufacturer Juniper Networks. Our switches and routers always work in a group of two physical identical devices, which then act as one unit. In such an unit, one of the devices provides the primary (active) routing engine. If this device fails, the secondary routing engine (i.e. the secondary device) takes over operation within a few seconds. However, this failover process may no longer work as intended if there are problems on the part of the operating system (Junos OS), which can occur due to a firmware bug, for example, or a partial or creeping hardware defect. In such a case a manual intervention might be necessary. The device that did not boot anymore on Friday had already shown this behaviour after an outage last summer, however, we got it back repaired and it worked flawlessly since then. Unfortunately, it has been such a long time since reintegration that, in our view, we could not expect a defect again. However, we will replace the device completely now. We evaluate which improvements can be made within our monitoring especially regarding log file analysis in order to identify problems even faster in the future. Some thresholds have already been reduced after analyzing historical data.

Why did the IPv6 networks cause such a problem and how is it dealt with in the long term?

We now have to wait and see whether the network remains stable after migration of the IPv6 subnets to the other router, and so the “fault” of the networks is confirmed. At the moment, especially due to the log entries from Sunday, we assume that this is the case (however, the actual disruption on Friday was most likely caused by the defective device). For historical reasons, the network segment in question contains a large number of IPv6 subnets which, due to a certain configuration, require more resources than subnets created later. To ensure long-term release of resources we started deconfiguring old subnets that became free already one year ago and only assigned subnets with the new configuration to new servers. The so-called TCAM utilization of the router, which we monitor continuously, has improved since then and has not been in a critical area for a long time. Based on the data sheet of our devices and the resources that can be monitored, there was no overuse - however, as we want to communicate openly, the recent events currently do not allow any other conclusion than a temporary overload of the routing engine. In the absence of information in the official documents, the limit that has now (apparently) been reached cannot yet be traced. It is therefore in the process of investigation with external Juniper specialists whether a hardware upgrade can solve this problem sustainably, i.e. larger-sized devices also expand the resources specifically required here or whether it is a structural problem of the Juniper operating system. If the further investigation reveals the need to adjust the configuration of the affected (comparatively few) subnets, we will carry out this in cooperation with the affected customers and contact them in good time.

Regardless of the result of the externally commissioned investigation, we are currently planning the following changes to our network infrastructure:

- Upgrade to Juniper routers from the latest generation to eliminate resource shortages in the long term and continue to use the latest technology

- Complete separation of the routing and switching infrastructure for better identification of problems and further relief for all devices involved

- Development of a concept that enables a faster failover to a replacement device in case of a failing router (and a non-working automatic failover) and, if possible, it should be made sure that a disruption does not affect the entire network

We will continue to work on these planned improvements over the next few weeks and inform you in good time about any work required. Due to the scope and importance of precise planning, we do not expect the changes to be completed before Q3 2020. The replacement of the supposedly defective device will of course take place in the next few days - we will announce this maintenance as soon as possible.

In order to improve communication in the case of global disruptions, we will shortly set up an external status page. So far, this work has primarily been done via our Twitter channel - which is embedded in the news section of our website, but of course our website cannot be reached in the event of a general (network) disruption. Nevertheless, we probably want to (additionally) keep communicating disruptions via Twitter, since our customers have been used to this for over eight years, direct communication with you is very important to us and Twitter is definitely the fastest way to send a first fault report (maximum of a few minutes).

We thank you for your attention and are available for any questions.

Mit freundlichen Grüßen / Best Regards

PHP-Friends GmbH . Duisburger Straße 375 . 46049 Oberhausen
Hotline: 0201 857 938 01

Amtsgericht Duisburg, HRB 28335
Geschäftsführer: Tim Schneider

Reply · Report Post