Aruba 6405 CX Switch

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 ein Software Upgrade im Cluster deutlich einfacher umsetzen lässt als man es beispielsweise von IRF her kennt. Mit ISSU (In Service Software Upgrade) hat man bei IRF bereits ein seit langer Zeit bewährtes Upgradeverfahren, welches die Aktualisierung von Switches in einem Cluster im laufenden Betrieb ohne Unterbrechung produktiver Datenströme ermöglich. Dies ist technisch nicht trivial, da für einen Clusterbetrieb immer auch eine identische Softwareversion Voraussetzung ist. 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 das VSX Upgrade 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:

Schematische Darstellung

Versuchsaufbau

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.

VSX Status

Um festzustellen, ob es während des Softwareupdates einen Verbindungsabbruch gibt, wird von 2930-1 zu 2930-2 ein “Dauerping” gestartet.

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

VSX Update Start

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.

VSX Update Status 1

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

VSX Update Status 2

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.

VSX Update Status 3

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

VSX Update Status 4

VSX Update Status 5

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

VSX Update Status 6

VSX Update Status 7

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

VSX Update Status 8

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

VSX Status nach Update

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.

Aruba 2930M PoE Switch

ArubaOS: Optimierung der PoE-Leistung mit Hilfe von LLDP

Device-Profile

Wer LLDP-fähige Access Points an einem Aruba switch betreibt, weiß wie sehr die LLDP-Informationen im Arbeitsalltag weiterhelfen können. So liefern sie beispielsweise die Information über Hostnamen, Mac Adresse,IP-Adresse und PoE-Leistung des LLDP-Gerätes pro Switchport. Neben der reinen Informationsübermittlung sind ArubaOS Switches auch in der Lage auf Basis der LLDP-Informationen Portkonfigurationen eigenständig auszuführen. Dazu muss lediglich ein so genanntes „Device Profile“ erstellt werden, unter welchem Sie beispielsweise VLAN-Zuweisungen konfigurieren können. Wird dann ein Access Point an einen Switchport angeschlossen, so erhält der Port automatisch diese VLAN-Konfiguration, solange der Access Point an dem Port angeschlossen bleibt.

Device Profile

Konfiguration einens Device Profiles

PoE – benötigte Leistung

Neben den Netzwerkinformationen liefert LLDP für PoE- und PoE+-Geräte auch Informationen zu der benötigten elektrischen Leistung und der PoE-Klasse. Dabei wird zwischen dem aktuellen Verbrauch und der maximal benötigten Leistung unterschieden. Letztere ist ausschlaggebend für die Berechnung der gesamten benötigten elektrischen Leistung und somit auch für die maximale Anzahl an Access Points, welche am Switch angeschlossen werden können. Dabei kann sich die maximale Leistung von dem eigentlichen Verbrauch drastische unterscheiden. Sind bei einem Access Point gewissen Features, wie zum Beispiel Bluetooth, ausgeschaltet, weil diese nicht benötigt werden, kann der eigentliche Verbrauch auch nur halb so groß sein wie der maximale Verbrauch. Das Resultat wäre die doppelte Anzahl an möglichen Access Points, die mit einem Switch betrieben werden können.

Ein von Aruba häufig verwendeter Access Switch ist der Aruba 2530 J9853A. Dieser stellt auf 48 Ports insgesamt eine PoE-Leistung von 382W zur Verfügung. Damit können bei einem durchschnittlichen Verbrauch von 13W (Durschnitt von einem Aruba AP 515 Access Point mit deaktiviertem Bluetooth und Zigbee) 29 Access Points betrieben werden. Allerdings liefert die LLDP-Information der Access Points eine Maximale Leistung von 25W. Damit sinkt die Anzahl der maximalen Access Points, welche mit demselben Switch betrieben werden können, auf gerade mal 15.

Workaround für ältere Firmwareversionen

Unter den letzten Firmwareversionen von ArubaOS, konnte die Berechnung der gesamten Leistung für PoE+-Geräte, auf Basis des maximalen Verbrauchs nur verändert werden, wenn LLDP deaktiviert worden ist. Danach konnte die gesamte Leistung aus dem tatsächlichen Verbrauch errechnet werden und somit die maximale Anzahl der möglichen Access Points erhöht werden. Diese Prozedur barg leider den Nachteil, dass man auf die sonst so hilfreichen LLDP-Informationen verzichten musste.

Admin Status

Befehl LLDP admin-status

poe-allocated-by

Befehl poe-allocated-by

ArubaOS Firmware Version 16.10.001

Seit dem letzten Firmwareupdate von Aruba auf die Version 16.10.0000, kann der Verbrauch nun auch trotz LLDP-Informationen aus dem tatsächlichen Verbrauch berechnet werden. Dies geschieht, genau so wie bisher für PoE-Geräte, mit dem „poe-allocate-by usage“ Befehl. Dieser kann nun auch innerhalb eines Geräteprofils gesetzt werden, sodass er nicht händisch auf alle Interfaces konfiguriert werden muss.

Die Release-Notes zu ArubaOS Version 16.10.0001 finden Sie unter: https://support.hpe.com/hpesc/public/docDisplay?docId=a00090303en_us

Schulungen zum Thema ArubaOS finden Sie unter: https://www.ingentive.net/schulungen/alle-schulungen/aruba-switches

VSF auf Aruba 5406R zl2 Switches

Mit VSF (Virtual Switching Framework) bietet HPE bzw. Aruba seit der Software Version 16.01 (5400R) bzw. 16.03 (2930F) eine leistungsstarke Virtualisierungslösung für Ihr Switchportfolio an. Technologisch wurde VSF von den Comware Switches übernommen, dort ist es als IRF bekannt und seit mehr als 10 Jahren bewährt. VSF ist eine sogenannte Frontplane Stacking Technologie, d.h. sie verwendet die produktiven Netzwerkinterfaces für die Stackverbindung, demgegenüber verwendet Backplane Stacking, wie es etwa bei den 2930M oder 3810M Switches eingesetzt wird, separate Module und Kabel.

Vorteile

VSF bietet große Vorteile bezüglich Design und Betrieb des Netzes. Die virtualisierten Switches sind hoch integriert und erscheinen “nach außen” als ein einziges logisches Chassis. Dies ermöglicht, redundante Uplinks als LACP Trunks auszuführen, so dass gegenüber einem klassichen Design die redundante Leitung nicht mehr durch Spanning Tree blockiert wird. Zudem existiert nur noch eine einzige running-config für die Member Switches, so dass weniger Verwaltungsaufwand entsteht.

Voraussetzungen

Grundsätzlich verfügbar ist VSF im Bereich der klassischen Aruba Switches nur auf den Aruba 2930F und 5400R zl2. Letztere müssen dabei im v3 only Mode gefahren werden, d.h. es dürfen keine v2 Module im Switch sein und der Compatibility Mode ist abzuschalten. Daneben gelten die folgenden Voraussetzungen:

  • Derzeit wird VSF für zwei Switches (5400R) oder acht Switches (2930F, ab 16.06) unterstützt.
  • Die Switches in der Fabric (d.h. dem Stack) müssen aus der gleichen Serie sein, jedoch nicht zwingend gleich ausgestattet. So kann man etwa auch 24-Port 2930Fmit 48-Port Switches in einer Fabric betreiben. Voraussetzung ist eine Software Version ab 16.06.
  • Der Aruba 5400R hat zwei Slots für Management Module. HPE empfiehlt den VSF Betrieb nur dann, wenn pro Switch nur ein Management Modul aktiv ist. Ein evtl. vorhandenes zweites Modul wird automatisch heruntergefahren.
  • VSF und folgende Features schließen sich aus: Distributed Trunking, Meshing, QinQ.

Topologien

Es werden die folgenden Topologien unterstützt.

  • 5400R zl2 oder 2930F, jeweils mit 2 Switches im Stack: Nur Chain (einfache Verkettung)
  • 2930F mit 3-8 Switches im Stack: Chain oder Ring.

Terminologie

VSF Fabric: Virtueller Switch, dessen Management- und Control Plane auf dem Commander liegt, und dessen Forwarding Plane aus Commander und Standby gebildet wird.

Member Switch: Mitglied einer VSF Fabric.

Commander: Auf diesem Switch laufen Control- und Management Plane Protokolle. Er verwaltet die Forwarding Database, synchronisiert sie mit dem Standby und kontrolliert alle Module inklusive die des Standby Members. Der Commander wird innerhalb der Fabric anhand einer konfigurierbaren Priorität bestimmt (1..255, Default = 128, höhere Priorität gewinnt).

Standby: Ein Standby ist ein Stateful Backup für den Commander. Er kann die Kontrolle über das virtuelle Chassis übernehmen, wenn der Commander ausfällt.

VSF Link: In Kupfer oder LWL ausgeführte Standard Ethernetverbindung zwischen Member Switches. Auf den 5400R können nur 10G und 40G Verbindungen einem VSF Link zugewiesen werden, die 2930F unterstützen hingegen auch 1G.

Konfiguration

Im folgenden zeigen wir eine VSF Konfiguration anhand zweier 5406R zl2 Switches in einer Chain Topologie. Wir verwenden dabei den sog. Discovered Configuration Mode, bei dem nur der Commander aktiv konfiguriert wird. Der Standby wird in den Werkszustand gebooted und dann auf den VSF Ports mit dem Commander verbunden. Dieser entdeckt daraufhin den leeren Standby Switch und übernimmt ihn automatisch in die Fabric. Dies stellt die einfachste Methode zum Aufbau einer VSF Fabric dar. Im Ausgangszustand kann der Commander bereits mit einer beliebigen Konfiguration versehen sein, diese wird später vom Standby übernommen.

1. Commander mit Member ID 1 versehen und physikalische VSF Ports definieren:

Switch(config)# vsf member 1 link 1 A21-A22
All configuration on this port has been removed and port is placed in VSF mode.

2. VSF Member Priorität > 128 setzen, damit Member 1 der Commander wird:

Switch(config)# vsf member 1 priority 160

3. VSF wird auf diesem Member eingeschaltet und die Domain ID gesetzt.

Switch(config)# vsf enable domain 10
To enable VSF, the REST interface will be disabled.
This will save the current configuration and reboot the switch.
Continue (y/n)? y

Der Switch startet daraufhin neu und kommt als Standalone Fabric (also eine VSF Fabric mit nur einem einzigen Switch) hoch. Der Bootvorgang dauert etwas länger als gewöhnlich.

4. Der zweite Switch wird im Werkszustand an die VSF Ports des Commanders angeschlossen. Die Konfiguration muss vollständig dem Factory Default entsprechen. Nach einiger Zeit (ca. 60 Sek.) booted der zweite Switch austomatisch:

Rebooting to join VSF fabric with domain ID 10

Besitzt der zweite Switch eine vom Commander abweichende Software, so wird diese automatisch angeglichen. Dies erfordert dann einen zweiten Reboot. Bei der Übernahme wird dann auch die running-config wird mit der des Commanders überschrieben. Der Stack ist damit komplett. Dies ist auch auf der Konsole des Standby Members zu erkennen:

…
Crypto powerup selftests all passed
..initialization done.
Press any key to connect to the commander.

Der Status des Stacks überprüft man wie folgt:

Switch# show vsf
VSF Domain ID     : 10
MAC Address     : 3464a9-b2533f
VSF Topology     : Chain
VSF Status     : Active
Uptime     : 1d 4h 28m
VSF Oobm-MAD     : Enabled
Software Version : KB.16.02.0008
Mbr
ID  Mac Address   Model                        Pri Status
--- ------------- ---------------------------- --- ----------
*1   3464a9-b24300 HP J9850A Switch 5406Rzl2    160 Commander
 2   5820b1-9b6000 HP J9850A Switch 5406Rzl2    128 Standby

Das “*” bezeichnet hierbei den Switch, auf dessen Konsole man sich gerade befindet. Der Stack bzw. die Fabric ist damit aufgebaut. Beide Member verhalten sich wie ein einziger Switch. Insbesondere können nun LACP Trunks auf beiden Chassis terminiert werden und das Netzwerk damit hochverfügbar gemacht.

Diese Anleitung basiert auf unserem Seminar “Aruba Switches”, das wir regelmässig als Präsenzschulung in Düsseldorf oder Virtuelle Schulung anbieten.

Ingentive Blog Aruba Switches

Neues Aruba Switchmodell Aruba 2930F-12G-PoE-2G/2SFP+

Vor wenigen Wochen hat Aruba das neue Switchmodell Aruba 2930F-12G-PoE-2G/2SFP+ (JL693A) herausgebracht und wir konnten es nun zum ersten Mal in den Händen halten. Der Switch schließt die Lücke zwischen dem 8 Port und dem 24 Port Modell und ist ideal geeignet für kleine Verteiler zur Anbindung von Access-Points oder IoT Geräten. Durch das integrierte Netzteil und die geringe Tiefe von nur 25,4 cm ist der Switch sehr kompakt. Mit 2 x 10GB Uplnik lassen sich Access-Points performant anbinden.

Das Gerät bietet folgende Highlights:

  • 12 Gigabit Ports mit PoE Class 4 Versorgung
  • 139 Watt PoE Leistung
  • 2 zusätzliche Gigabitports
  • 2 SFP+ Uplink Ports für 1 oder 10GB
  • Integriertes Netzteil
  • Lüfterloser Betrieb
  • 25,4 cm Einbautiefe
  • Geringe Leistungsaufnahme (20 Watt im Leerlauf)
  • Stacking mit VSF Technologie

 

Die Ports 1-12 können mit PoE+ gespeist werden, wobei maximal 139 Watt zur Verfügung stehen. Die Ports 13 und 14 können zusätzlich verwendet werden, allerdings hier ohne PoE. In die Ports 15 und 16 lassen sich die handelsüblichen Aruba Transceiver einsetzen und können somit eine Anbindung über 1 oder 10GB Lichtwelle herstellen.

Damit besteht die 2930F Serie nun aus folgenden Switchmodellen:

  • JL259A Aruba 2930F 24G 4SFP Switch
  • JL260A Aruba 2930F 48G 4SFP Switch
  • JL253A Aruba 2930F 24G 4SFP+ Switch
  • JL254A Aruba 2930F 48G 4SFP+ Switch
  • JL258A Aruba 2930F 8G PoE+ 2SFP+ Switch
  • JL693A Aruba 2930F 12G PoE+ 2G/2SFP+ Switch
  • JL261A Aruba 2930F 24G PoE+ 4SFP Switch
  • JL262A Aruba 2930F 48G PoE+ 4SFP Switch
  • JL255A Aruba 2930F 24G PoE+ 4SFP+ Switch
  • JL256A Aruba 2930F 48G PoE+ 4SFP+ Switch
  • JL557A Aruba 2930F 48G PoE+ 4SFP 740W Switch
  • JL558A Aruba 2930F 48G PoE+ 4SFP+ 740W Switch