ArubaOS-CX Unterbrechungsfreie Firmware-Updates

Die ArubaOS-CX Switches der Serien 6400, 8300 und 8400 bringen das Feature VSX (Virtual Switching Extension) mit, bei der zwei Switches in einem Cluster eingesetzt werden können. Im Gegensatz zu den aus der Aruba-Welt bekannten Clustertechnologien wie IRF (Comware Switches) und VSF (ArubaOS-S Switches) bilden die Komponenten dabei nicht vollständig eine logische Einheit, sondern erscheinen nur auf Layer 2 als solche. Dies ermöglicht beispielsweise die redundanztechnisch wichtige Multichassis Link Aggregation (MLAG, auch VSX LAG genannt). Control- und Management Planes der Switches bleiben jedoch getrennt. Hierdurch sind insbesondere beide Switches separat zu verwalten, was durchaus als Nachteil dieser Lösung gegenüber den oben genannten Technologien betrachtet werden kann. Einer der wichtigsten Vorteile der geringeren Integration zwischen Komponenten ist jedoch, dass sich im ArubaOS-CX Cluster unterbrechunsfreie Firmware Updates deutlich einfacher umsetzen lassen als man es beispielsweise von IRF her kennt.

Mit ISSU (In Service Software Upgrade) hat man bei IRF bereits ein Upgradeverfahren, welches die Aktualisierung von Switches in einem Cluster im laufenden Betrieb ohne Unterbrechung produktiver Datenströme ermöglicht. Dies ist technisch nicht trivial, da für einen Clusterbetrieb immer auch eine identische Softwareversionen Voraussetzung sind. Diese Bedingung muss im Rahmen eines Upgrades jedoch zwangsläufig zumindest temporär verletzt werden. ISSU ermöglicht ein solches Upgrade, jedoch sind die Prozeduren dahinter kompliziert und, insbesondere im Fall eines incompatible ISSU, fehleranfällig.

VSX ermöglicht nun eine viel einfachere Vorgehensweise, da hier nicht die Notwendigkeit gemeinsamer Control- und Managementplanes besteht. Vielmehr sind diese logischen Einheiten vor, während und nach einem Upgrade jeweils ohnehin separiert. Für das Upgrade wurde ein einfaches CLI-Kommando vorgesehen, der Rest geschieht automatisch.

Wir wollen hier einen Überblick über ArubaOS-CX Firmware Updates geben und überprüfen, inwieweit man dabei wirklich von einem „hitless“ Upgrade, also ohne den Verlust produktiver Daten während des Upgrades, sprechen kann.

Hierzu haben wir zwei Aruba 8325 Switches in ein VSX Setup gebracht. An die 8325 wurden zwei Aruba 2930F-8G als Access Switches für den Test angeschlossen.

In der folgenden Darstellung ist der Versuchsaufbau zu sehen:

VSX-Konfiguration auf den 8325:

8325-1(config)# interface lag 128
8325-1(config-lag-if)# no routing
8325-1(config-lag-if)# no shutdown
8325-1(config-lag-if)# lacp mode active
8325-1(config-lag-if)# exit
8325-1(config)# interface 1/1/47
8325-1(config-if)# no shutdown
8325-1(config-if)# lag 128
8325-1(config-if)# interface 1/1/48
8325-1(config-if)# no shutdown
8325-1(config-if)# lag 128

8325-2(config)# interface lag 128
8325-2(config-lag-if)# no routing
8325-2(config-lag-if)# no shutdown
8325-2(config-lag-if)# lacp mode active
8325-2(config-lag-if)# exit
8325-2(config)# interface 1/1/47
8325-2(config-if)# no shutdown
8325-2(config-if)# lag 128
8325-2(config-if)# interface 1/1/48
8325-2(config-if)# no shutdown
8325-2(config-if)# lag 128

8325-1(config)# vsx
8325-1(config-vsx)# inter-switch-link lag 128
8325-1(config-vsx)# role primary

8325-2(config)# vsx
8325-2(config-vsx)# inter-switch-link lag 128
8325-2(config-vsx)# role secondary

Auf einen Keepalive-Link haben wir verzichtet, da dieser keinen Einfluss auf die Versuchsanordnung bzw. den durchzuführenden Test hat.

Die 2930er wurden über die MLAGs LAG1 und LAG2 jeweils an beide Chassis angeschlossen. Hier zunächst die MLAG Konfiguration der 8325er:

8325-1(config)# interface lag 1 multi-chassis
8325-1(config-lag-if)# no routing
8325-1(config-lag-if)# no shutdown
8325-1(config-lag-if)# lacp mode active
8325-1(config-lag-if)# exit
8325-1(config)# interface 1/1/1
8325-1(config-if)# no shutdown
8325-1(config-if)# lag 1

8325-1(config)# interface lag 2 multi-chassis
8325-1(config-lag-if)# no routing
8325-1(config-lag-if)# no shutdown
8325-1(config-lag-if)# lacp mode active
8325-1(config-lag-if)# exit
8325-1(config)# interface 1/1/2
8325-1(config-if)# no shutdown
8325-1(config-if)# lag 2

8325-2(config)# interface lag 1 multi-chassis
8325-2(config-lag-if)# no routing
8325-2(config-lag-if)# no shutdown
8325-2(config-lag-if)# lacp mode active
8325-2(config-lag-if)# exit
8325-2(config)# interface 1/1/1
8325-2(config-if)# no shutdown
8325-2(config-if)# lag 1

8325-2(config)# interface lag 2 multi-chassis
8325-2(config-lag-if)# no routing
8325-2(config-lag-if)# no shutdown
8325-2(config-lag-if)# lacp mode active
8325-2(config-lag-if)# exit
8325-2(config)# interface 1/1/2
8325-2(config-if)# no shutdown
8325-2(config-if)# lag 2

Und hier die LACP Trunk Konfiguration der 2930er:

2930-1(config)# trunk 9,10 trk1 lacp

2930-2(config)# trunk 9,10 trk1 lacp

Allen Switches wurde im VLAN 1 eine IP Adresse im Bereich 192.168.1.0/24 zugeteilt:

8325-1(config)# interface vlan 1
8325-1(config-if-vlan)# 192.168.1.10/24

8325-2(config)# interface vlan 1
8325-2(config-if-vlan)# 192.168.1.11/24

2930-1(config)# vlan 1
2930-1(vlan-1)# ip address 192.168.1.1/24

2930-2(config)# vlan 1
2930-2(vlan-1)# ip address 192.168.1.2/24

An den 2930F Switch mit der IP Adresse 192.168.1.1 wurde dann ein PC mit TFTP Server mit der IP Adresse 192.168.1.100 angeschlossen.

Vorbereitung

In diesem Ausgangszustand liefen die ArubaOS-CX Switches mit der Softwareversion 10.04.0030.

Auf dem TFTP Server wurde die Softwareversion 10.05.0011 hinterlegt.

Auf dem Screenshot ist zu sehen, dass VSX In-Sync ist.

Um festzustellen, ob es während des Softwareupdates einen Verbindungsabbruch gibt, startet man von 2930-1 zu 2930-2 einen „Dauerping“.

Während des laufenden „Pings“ wird nun auf dem primären 8325 das „vsx update“ Kommando gestartet:

8325-1# vsx update-software tftp://192.168.1.100/ArubaOS-CX-10-05-0011.swi

Nach dem Start ist zu sehen, dass beide Switches den Download der Datei gestartet haben. Außerdem sieht man, dass der Link zwischen beiden Switches noch aktiv ist.

Nachdem beide Switches die Software heruntergeladen haben, initiiert der secondary VSX Switch einen Reboot.

Während des Reboots sieht man, dass der Inter Switch Link auf „Down“ geht. Der Secondary ist nun im Boot Prozess. Es sind keine Ping Verluste zu beobachten.

Nachdem der Secondary das Update erfolgreich durchgeführt hat, wartet der Primary auf einen abgeschlossenen VSX Sync.

Nachdem der Sync erfolgreich beendet wurde, initiiert nun seinerseits der Primary Switch einen Reboot.

Während des Update Prozesses rebootet der Switch 3 Mal. Es sind leicht schwankende Antwortzeiten, aber nach wie vor keine Ping Verluste zu erkennen.

Nach dem Reboot steht der Switch wieder zum Login zur Verfügung.

VSX ist wieder im Sync und beide Switches sind voll einsatzbereit.

Ergebnis

VSX Upgrade stellt eine einfach anzuwendende Prozedur dar, um in einem VSX Cluster ein Upgrade durchzuführen. Wir konnten demonstrieren, dass ein Upgrade ohne Verlust produktiver Daten in einfachen Szenarien möglich ist.