Hintergrund zum Border-Austausch-Versuch 1 vom 25.8.

[Daniel Baumann]

Hallo zusammen

Wie berichtet, wollten wir am 25.8. die beiden Cisco Border-Router
durch zwei temporaere Arista-Geraete ersetzen, mehr zum "Warum" des
Wechsels siehe auch unser Announcement dazu:

   https://lists.bfh.science/pipermail/bfh-linux-announce/2021-August
   /000130.html

Im Folgenden einige Hintergrund-Informationen zu unserer
Dokumentation und (fuers Management zum Schluss :) die Massnahmen
aus dem nicht erfolgreichen Austausch-Versuch am 25.8.


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

Das relevante Setup setzt sich aus 3 Komponenten zusammen:

1. die bestehenden Cisco Border:

   * zwei Cisco Catalyst 9500 Switches sind mit je einem Uplink via
     Universitaet Bern ans Internet angeschlossen. Die beiden Uplinks
     sind active-passive, es kann als nur jeweils ein Uplink
     gleichzeitig benutzt werden.

   * die Science DMZ und ein paar weitere kleinere Labor-Netze sind
     direkt via Border ans Internet angeschlossen. Alles andere geht
     vom Border zuerst zur Firewall und danach dann ins interne BFH-
     Netz.

2. die bestehende Linux Firewalls:

   * an den beiden Cisco Switches haengen zwei Standard Supermicro
     Server als Linux-Firewalls mit je 8x 10gbit/s, davon gehen je
     2x 10gbit/s auf den Border. Die beiden Server sind mit LACP
     (802.3ad) als Port-Channel mit active-active angeschlossen.

   * die Server haben pro Firewall (einmal die Haupt-Firewall,
     einmal die AdminRZ-Firewall fuer den Anschluss ans interne
     Verwaltungsnetz des Kanton Berns) jeweils Linux-Container. Diese
     betreiben wir zwischen den beiden Servern in einer
     HA-Konfiguration (active-passive) mit pacemaker/corosync und
     conntrackd.

3. neue Arista Border:

   * zwei Arista 7280SR1 Switches werden manuell konfiguriert (also
     nicht als Teil einer SDN-Fabric) eingesetzt und sollen
     temporaer die beiden Cisco Border ersetzen.

   * nach Abschluss des Lifecycles des bestehenden Rechenzentrums-
     Teil (Cage-B) werden die Arista Switches durch zwei neuere
     7280SR3 als Teil der parallel aufgebauten SDN-Fabric des Cage-B
     diese jetzt manuell konfigurierten Switches nach dem
     Jahreswechsel wieder ersetzen. Die 7280SR1 gehen dann an als
     Spines an einen anderen Standort.

   * Dieser temporaere Einbau ist jetzt notwendig weil wir die
     Funktionen der Arista Switches benoetigen um Cage-B und an den
     neueren Rechenzentrums-Teil (Cage-A) mit aller neuen Basis-
     Infrastruktur und der (bis dahin umgezogenen) Science DMZ
     zusammenschliessen zu koennen. So wird dann endlich BFH.ch und
     BFH.science netzwerktechnisch wiedervereinigt und wir koennen
     den Rest der Netzwerk-Gesamterneuerung an den Standorten
     beginnen.


Verbindungsaufbau mit Link Aggregation (LACP)
=============================================

Wo immer moeglich setzen wir fuer eine Verbindung zwischen Systemen
aus Redundanz-, Performance und operativen Wartungs-Gruenden auf
mehrere physikalische Kabel.

Werden zwei physikalische Links zu einem einzigen logischen Link
aggregiert (auch Bonding oder Teaming genannt), muessen beide Link-
Partner auf ihrer Seite die Moeglichkeit haben, diese eine
aggregierte Verbindung von anderen (ggf. auch aggregierten)
Interfaces unterscheiden zu koennen.

Dazu wird zwischen Server und Switch(es) beim Aufbau der
Aggregation, auf jeder Seite fuer das jeweilige System, eine
ein-eindeutige Nummer ausgehandelt (die eigene und die der
Gegenseite sieht man als "port number" in /proc/net/bonding/bond*).

Beispiel:

   * Ein Server hat 4 Interfaces (eno1, eno2, eno3 und eno4).
     Je 2 Interfaces sollen aggregiert werden (bond0=eno1+eno2,
     bond1=eno3+eno4).

   * Beim Aufbau der Aggregation wird fuer bond0 eine zufaellige
     aber ein-eindeutige LACP Nummer auf der Seite des Servers
     bestimmt, z.B. 101

   * Auf der Switch-Seite wird fuer bond0 ebenfalls eine zufaellige
     aber ein-eindeutige LACP Nummer auf der Seite des Switches
     bestimmt, z.B. 1234.

   * Switch und Server tauschen dann die LACP Nummern aus und wissen
     nun, dass die logische Verbindung bond0 fuer die Interfaces
     eno1+eno2 auf Server-Seite die Nummer 101 und auf Switch-Seite
     1234 haben.

   * Fuer die zweite Aggregation im Beispiel (bond1=eno3+eno4) werden
     analog neue LACP Nummern gewaehlt, z.B. 102 (Server) und 1235
     (Switch).

   * Faellt nun ein Kabel aus oder wird (am gleichen oder an einen
     anderen Switch) umgesteckt, stimmen die LACP Nummern nicht
     ueberein (oder sind gar nicht vorhanden). So kann verhindert
     werden, dass versehentlich falsche Interfaces zusammengefasst
     werden, resp. das Netzwerk-Pakete von "ausserhalb" der
     Aggregation in die Aggregation hinein leaken. Das funktioniert
     auf beiden Seiten der Aggregations-Partner, hier
     z.B. 101 != 102 (Server-seitig) und 1234 != 1235 (Switch-seitig)

   * Kollisionen von LACP Nummern sind moeglich, aber praktisch
     ausgeschlossen (der 802.3ad Standard ist nur kostenpflichtig
     einsehbar, aber.. im Linux Kernel ists ein u16, d.h. die
     positiven Ganzzahlen startend mit 0 bis 65'535).


Border-Austausch, Versuch 1
===========================

Da die Firewalls mit je 2 Kabel an die zwei Switches angeschlossen
sind, erschien es plausibel je ein Kabel pro aggregiertem Link auf
den neuen Switch umzustecken.

Dadurch wurden die aggregierten Links "halbiert" und waren komplett
down:

   * das eine Kabel der LACP Verbindung mit dem Cisco Border hatte
     eine LACP Nummer und LACP Partner Nummer, das andere Kabel (der
     zuvor gleichen Aggregation) sah mit dem Arista Switch eine
     andere, neue LACP Nummer.

   * wenn bei LACP mit mehreren Teil-Links keine Mehrheit von Teil-
     Verbindungen mit gleichen LACP Nummern mehr vorhanden ist, kann
     das System (hier Linux) grundsaetzlich nicht mehr wissen, welche
     Verbindung nun "korrekt" ist und kann/soll diese auch nicht
     erraten duerfen, z.B. mit IDs aus obigem Beispiel:

     - bond0 aus eno1 und eno2 hat die LACP Nummer-Kombination aus
       101 und 1234.

     - wenn eno2 vom Cisco auf den Arista Switch umgesteckt wird,
       sieht Linux auf eno2 eine andere LACP Nummer, z.B. 9876.

     - was ist nun korrekt: 101<->1234 vs. 101<->9876 ?

     - wuerde 101<->1234 genommen, wuerde ja das beabsichtige
       Failover auf eno2 nicht passieren, so dass beim weiteren
       Umstecken von eno1 ein Unterbruch entstuende.

     - wuerde 101<->9876 genommen, wuerde die bestehende noch
       funktionierende Verbindung zum Cisco unterbrochen.

     - in beiden Faellen kann nie das gewuenschte Resultat fuer
       dieses Szenario erreicht werden.

   * Alle "kreativen" Vorschlaege wie man das loesen kann sind nicht
     geeignet fuer ein deterministisches System-Verhalten weil von
     beliebigen Annahmen ausgegangen werden muesste. Linux macht in
     diesem Fall daher das einzige Richtige: gar nichts. D.h. beide
     Verbindungen werden unterbrochen und es obligt dem Admin das
     "Richtige" zu tun und die "korrekte" Verbindung
     wiederherzustellen (es ist generell ein gutes Programier-
     Paradigma lieber nichts zu tun als (mit hoher
     Wahrscheinlichkeit) das Falsche).

Diese Situation trat gleich zu Beginn des Wartungsfensters am 28.8.
um 19 Uhr. Danach gelang es nicht, die Aggregation auf den
Interfaces wiederherzustellen.

Aufgrund der Ungewissheit wegen einer (davon unabhaengigen)
Unerreichbarkeit der an den Switchen vorort arbeitenden Person ging
ein Linux-Admin um 19:50 los ins Rechenzentrum um Unterstuetzung
anzubieten. Er traf um 20:05 vor dem System ein.

Da bis dahin das gesamte BFH.ch Netz bereits fuer 1h down war, wurde
sofort und am schnellstmoeglichsten die Migration auf die neuen
Border rueckgaengig gemacht. Das Wiederherstellen der LACP
Interfaces und durch andere Operationen verwirrten HA-Setup der
beiden Firewalls konnte am schnellsten durch ein vollstaendiges
Abschalten beider Linux-Server, zurueckstecken der Kabel von den
Arista Switches auf die Cisco Switches und Neustarten der Linux-
Server erreicht werden (das wir Neustarten muessen haengt u.a. mit
der Stapelung von bond->vlan->bridge auf den Container-Servern und
der Funktionsweise von ifupdown zusammen; eine Geschichte fuer ein
anderes Mal..). Um 20:14 waren alle Systeme und Services wieder
vollstaendig hergestellt/wie gewohnt erreichbar.


Massnahmen
==========

Wir haben folgende Massnahmen getroffen:

   * bei Netzwerk-Migrationen bei denen irgendwo Basis-Infrastruktur
     (sprich: eines unserer Linux-Systeme) involviert ist,
     muss zwingend immer ein Linux-Admin bei der Migration dabei sein
     und fuehrt gegebenfalls notwendige Arbeiten an den Linux-
     Systemen selbst durch.

   * das "Drehbuch" bei Netzwerk-Migrationen wird vorgaengig im
     Gesamt-Team ueberblicksmaessig vorbesprochen (die
     konzeptionellen Vorgehensweise, kein Micro-Management) so dass
     "konzeptionell nicht Funktionierendes/Moegliches" verhindert
     werden kann.

   * die unmittelbare Erreichbarkeit auf dem Mobiltelefon von
     Personen waehrend einer Migration muss sichergestellt sein.

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