Hintergrund: Cisco Nexus 5000 Upgrade fehltgeschlagen

Tue Dec 15 08:06:38 CET 2020

Hallo zusammen

Ausgangslage
============

  * Die Cisco Nexus 5000 Switches wurden ca. um 2012 beschafft.

  * Die aktuell darauf eingesetzte Software ist von 2013 und wurde
    seither nie aktualisiert. Die Switches wurden erst einmal im
    Winter 2014 rebootet.

  * Fuer die eingesetzte Software sind viele, besonders kritische
    Sicherheitsluecken offen und bekannt, weshalb wir die Sicherheit der
    Systeme nach Feststellen der Situation letzten Monat, ohne ein
    Upgrade der Software auf eine aktuelle Version nicht gewaehrleisten
    koennen. Deshalb die Dringlichkeit der angesetzten Upgrades.

  * Das tatsaechliche Upgrade ist nicht in einem Schritt machbar,
    sondern muss aufgrund der grossen zeitlichen Differenz zwischen der
    alten, eingesetzten Software und der aktuellen Version ueber mehrere
    Zwischen-Versionen in 5 Teilschritten/Upgrades ausgefuehrt werden.

  * Unser externer Partner der den Betrieb der Cisco Geraete noch bis
    Ende Jahr uebernimmt, hat sich perfekt auf das Upgrade vorbereitet
    und von Cisco die exakten Schritte und Versionsspruenge bestaetigen
    und explizit absegnen lassen.

Cisco Upgrade Bug
=================

  * Die Cisco Nexus-Produktereihe basiert "intern" auf Linux (davon
    merkt man zwar nichts da man keinen Zugriff auf das darunterliegende
    Linux-System haben kann).

  * Beim ersten Zwischen-Versions-Upgrade besteht das Problem, dass es
    ein Henne-Ei Problem zwischen Kernel und Userland gibt. D.h. man
    muss zuerst den Kernel-Updaten, rebooten, und dann das Rest-System
    aktualisieren. Dieser Umstand ist in vielerlei Hinsicht
    problematisch:

    - das Henne-Ei Problem ist von Cisco nicht dokumentiert, haette
      man selbst vorher nicht wissen koennen.

    - das Henne-Ei Problem wurde auch vom Cisco-Engineering bei der
      Pruefung und Freigabe des Drehbuches fuer das Upgrade bei uns
      nicht entdeckt.

    - das Henne-Ei Problem kann aus Betreiberseite gar nicht verhindert
      werden, da man keinen Moeglichkeit hat, selbst nur den Kernel zu
      aktualisieren, sondern man kann nur entweder das gesamte System
      aktualisieren oder gar nichts.

  * Weil es keine technische Dokumentation von Cisco zum Systemaufbau
    gibt, kann man nur mutmassen. Generell sind solche "lock-step"
    Upgrade-Probleme bei Linux-basierten System extrem selten, weil alle
    in der Open Source-Szene immer um genuegend lange
    Rueckwaertskompatibilitaet in ihren Komponenten bemueht sind um
    genau solche unangenehme Situationen zu verhindern.

    Fuer mich hoert sich das Problem nach der Situation wie damals in
    2007 beim Upgrade von Debian 3.1 (sarge) auf Debian 4.0 (etch) an:

    Weil udev aus etch nicht mit Kernel aus sarge ging, musste man
    zuerst auf sarge den Kernel von etch installieren, rebooten, und
    dann udev sowie den Rest des Systems updaten, vergl.:

https://www.debian.org/releases/etch/i386/release-notes/ch-upgrading.en.html#s-upgrading_kernel

Verlauf des Upgrades
====================

  * Nachdem um 22 Uhr mit den Wartungsarbeiten begonnen werden konnte,
    scheiterte das erste Teil-Upgrade, so dass der eine der zwei Nexus
    Switches seit ca. 22:20 ausgefallen ist.

  * Durch das oben geschilderte Problem ist einer der beiden Nexus-
    Switches jetzt "bricked", d.h. irreparabel kaputt und muss auf
    Garantie schnellstmoeglichst ausgetauscht werden.

  * Da nur ein paar wenige Systeme nicht redundant auf beide Nexus-
    Switches angeschlossen sind, gab es nur geringe Auswirkungen:

    - nicht User-relevant (ab 1:40 Uhr wieder da):
      + Management Interfaces eines von zwei redundanten Border Router
      + Management Interfaces eines von zwei redundanten Core Router
      + vc41.bfh.ch (eine von zwei redundanten VPN Appliances)

    - User-relevant (ab 1:50 Uhr wieder da):
      + vpnext.bfh.ch
      + srvesx07.noc.bfh.ch (VMware ESX Node mit VMs drauf)

    - nicht User-relevant (ab 2:15 Uhr wieder da):
      + ddi1.bfh.ch (eine von zwei redundanten Infoblox Appliances)
      + legacy1.its.bfh.ch (eine von drei redundanten, temporaeren
        Linux Container mit "alten" Basis-Services im BFH.ch Netz)

  * Das Kopieren von NetApp Snapshots zwecks offsite-Backup von
    Bern nach Biel hat nicht funktioniert resp. wurde unterbrochen.

    Wir haben Layer 1 geprueft, ist alles korrekt verkabelt und
    alle Interfaces auf den noch funktionierenden Nexus sind aktiv.

    Wird heute vom zustaendigen Team zusammen mit NetApp Support
    angeschaut werden warums trotzdem nicht geht.

Weiteres Vorgehen
=================

  * Nachdem um 02:30 sichergestellt werden konnte, dass mit Ausnahme
    des NetApp Backups alle Systeme und Services im Rechenzentrum Bern
    funktionieren, haben wir um 03:15 die RMA beim zustaendigen Cisco
    Partner ausgeloest.

    Da die SLA-Situation fuer uns nicht klar ist, wissen wir erst im
    Verlauf des Morgen wann wir einen Ersatz erhalten. Wir werden
    demensprechend zeitnah ein weiteres Wartungsfenster planen.

  * Sobald der Ersatz da ist, kann resp. muss das erste Teil-Upgrade
    durch Cisco durchgefuehrt werden, danach sind beide Switches
    wieder da und es kann mit dem normalen Drehbuch fortgesetzt werden.

  * Bis der Ersatz da ist sind die Server im Rechenzentrum Bern nicht
    redundant angeschlossen:

    - auch wenn wir keine Ausfaelle erwarten, so besteht zumindest
      theretisch eine erhoehte Ausfallgefahr saemtlicher Dienste.

    - fuer die Systeme welche active-active LACP machen und nicht
      active-passive/fail-over, ist fuer diesen Zeitraum nur die
      halbe Bandbreite nutzbar. Dies sollte zu keinen weiteren
      Problemen fuehren:

      + die bestehenden Bandbreiten-Engpaesse im Netz befinden sich
        zwischen Bern und Biel, d.h. sind vom Ausfall nicht betroffen
        (und werden im Q1/2021 regulaer angegangen).

      + aufgrund der allgemeinen Home-Office Situation werden die
        Systeme weniger genutzt und es wird weniger interne Bandbreite
        benoetigt.

      + die wirklich grossen Datenstroeme sind nicht im BFH.ch Netz,
        sondern in der Science DMZ und diese ist vom Ausfall nicht
        betroffen weil eigene Netzwerkzone mit eigenen Switches.

Wir halten euch zeitnah auf dem Laufenden ueber das weitere Geschehen.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science