STP Edge Ports

In diesem Artikel beschäftigen wir uns mit dem Thema STP Edge Ports bei HPE Aruba Switches. Gemeinsamkeiten und Unterschiede sollen ebenso deutlich gemacht werden wie “Best Practice” Ansätze in diesem Bereich.

Ausgangspunkt

Zunächst zur Problemstellung: Spanning Tree Protocol (STP) stellt eines der ältesten Protokolle in der Netzwerktechnik dar, und es ist noch immer in den meisten Unternehmensnetzen im Einsatz, da sich alle über die Zeit entwickelten Alternativen aufgrund diverser Nachteile (meist herstellerproprietäre Ansätze) nicht durchsetzen konnten. Mittlerweile liefern uns die immer häufiger genutzten Virtualisierungstechniken wie – im HPE Umfeld – IRF (Comware), VSF (ArubaOS-Switch und ArubaOS-CX) und VSX (ArubaOS-CX) zwar den Schlüssel, um redundante Netzwerke ohne STP zu bauen. Dennoch verbleibt das Risiko versehentlich oder mutwillig herbeigeführter Schleifen mit den bekannten, katastrophalen Auswirkungen auf das Netz. Insofern ist selbst dann, wenn aufgrund der logischen Struktur des Netzes theoretisch auf STP verzichtet werden könnte, allein aus Gründen der Sicherheit ein Einsatz zu erwägen. Dies soll an anderer Stelle diskutiert werden.

STP im Edge

Der Begriff Edge (engl. “Rand”) wird meist in der HPE Welt verwendet. Bei anderen Herstellern ist eher der Begriff “Access” gängig. Da wir hier uns hier aber auf den HPE/Aruba Bereich konzentrieren, wird im Folgenden von “Edge” die Rede sein. Der Edge definiert sich durch die hier angeschlossenen Endgeräte wie PCs, IP-Telefone, WLAN Access Points, Kameras usw. Hierfür werden häufig vergleichsweise einfache und kostengünstige Switches mit 24 oder 48 Ports und PoE (Power over Ethernet) eingesetzt, da es in diesem Bereich vorwiegend darum geht, eine große Anzahl von Geräten an das Netz anzubinden. Die hier benötigten Funktionen und Protokolle sind im Vergleich zu übergeordneten Bereichen im Netz überschaubar. VLANs und Quality of Service wären etwa Beispiele hierfür.

Der “klassische” Spanning Tree 802.1D in seiner frühen Form unterschied nicht zwischen Edge Ports und Interswitch Links. Insofern wurden die Edge Ports wie alle anderen Ports auch den Zustandsübergängen im STP unterworfen. Wurde etwa ein an den Switch angeschlossener PC angeschaltet, so befand sich der zugeordnete Switchport nach dem “LINK UP” event zunächst per STP Protokoll im Status “BLOCKING”. Über die bekannten STP Timer wurde er dann “LISTENING” – “LEARNING” und schließlich “FORWARDING” und damit aktiv. Durch die timergesteuerten Übergänge entstand eine erhebliche Latenz von 30 bis 50 Sekunden, bevor der Port tatsächlich produktiv für den PC nutzbar war. Neben diesem unschönen bis problematischen Effekt kam es auch bei jedem Bootvorgang zu einer Topologieänderung, die aufgrund derSTP Mechanismen alle Switches in der STP Domäne veranlasste, ihre MAC-Adresstabellen zu löschen. Spätestens dieses Verhalten ist in größeren Netzen nicht tragbar, weshalb man schon früh nach Möglichkeiten gesucht hat, damit sinnvoll umzugehen.

Mit RSTP (802.1w, Seit 2004 Bestandteil von 802.1D-2004 und damit der Standard STP) wurde das Problem gelöst, indem die Möglichkeit vorgesehen wurde, die Edge Ports entweder durch den Administrator festlegen (also konfigurieren) zu lassen (sogenannter Admin Edge Port), oder die Ports automatisch zu erkennen (Auto Edge Port). Einzelheiten dazu legt der Standard nicht fest, sondern überlässt sie den jeweiligen Herstellerimplementierungen.

Auto-Edge

In der ArubaOS-Switch Familie (früher ProCurve) werden beide Möglichkeiten unterstützt. Wird STP in der Variante RSTP oder MSTP (der Default) aktiviert, so ist standardmässig auch das Feature Auto-Edge aktiv. Auto-Edge erkennt STP Edge Ports, indem es unmittelbar nach Aktivwerden des Ports dort auf die STP Dateneinheiten (BPDUs) lauscht. Die Logik sagt, dass wenn auf dem Switchport ein Switch mit aktiviertem STP läuft, innerhalb von 3 Sekunden eine BPDU eintreffen wird. Umgekehrt wird das Ausbleiben von BPDUs innerhalb dieser 3 Sekunden so interpretiert, dass kein STP “sprechendes” Device (also ein Switch) dort angeschlossen ist. Folglich wird der Port nach 3 Sekunden in den Status “FORWARDING” übergehen, denn auf einem Endgerät kann nie eine für STP relevante Schleifenbedingung entstehen.

Im Event Log des Switches ist gut nachvollziehbar, dass zwischen dem Blockieren eines Edge Ports durch STP und dem Verfügbarwerden nur knapp 5 Sekunden vergehen, wenn Auto-Edge aktiviert ist (zu lesen sind die Einträge von unten nach oben):

I 21/03/09 20:30:10 00076 ports: port 1 is now on-line
I 21/03/09 20:30:05 00435 ports: port 1 is Blocked by STP
I 21/03/09 20:30:00 00077 ports: port 1 is now off-line

Ob ein Port als STP Edge Port erkannt wird, ist in der Ausgabe des “show spanning-tree” Kommandos bei der Portübersicht zu sehen:

Switch# sh spanning-tree

Multiple Spanning Tree (MST) Information

STP Enabled : Yes
Force Version : RSTP-operation

(Ausgabe verkürzt)

| Prio | Designated Hello
Port Type | Cost rity State | Bridge Time PtP Edge
----- ---------- + --------- ---- ------------ + ------------- ----- ---- -------
1 100/1000T | 20000 128 Forwarding | e0071b-4c4aa0 2 Yes Yes
2 100/1000T | Auto 128 Disabled | 2 Yes No

Wie bereits erwähnt ist das Feature auto-edge per Default aktiv. Es lässt sich mit dem Kommando

Switch(config)# no spanning-tree 1-8 auto-edge-port

abschalten. Dies ist in den meisten Fällen jedoch nicht notwendig.

Um zu verifizieren, ob das Feature aktiv ist, kann das Kommando “show spanning-tree <Portlist> config” verwendet werden. Es zeigt neben Auto-Edge auch noch den Status weiterer, portspezifischer STP Features an:

Switch(config)# sh spanning-tree config

Multiple Spanning Tree (MST) Configuration Information

STP Enabled [No] : Yes
Force Version [MSTP-operation] : RSTP-operation
Default Path Costs [802.1t] : 802.1t
Port State Events Logging : Disabled
MST Configuration Name : e0071b4c4aa0
MST Configuration Revision : 0 Switch Priority : 32768
Forward Delay [15] : 15 Hello Time [2] : 2
Max Age [20] : 20 Max Hops [20] : 20

| Path Prio Admin Auto Admin Hello Root TCN Loop BPDU
Port Type | Cost rity Edge Edge PtP Time Grd Grd Grd Flt
---- ---------- + --------- ---- ----- ---- ----- ------ ---- --- ---- ---
1 10/100TX | Auto 128 No No True Global No No No No
2 10/100TX | Auto 128 No No True Global No No No No
3 10/100TX | Auto 128 No No True Global No No No No
4 10/100TX | Auto 128 No No True Global No No No No
5 10/100TX | Auto 128 No No True Global No No No No
6 10/100TX | Auto 128 No No True Global No No No No
7 10/100TX | Auto 128 No No True Global No No No No
8 10/100TX | Auto 128 No No True Global No No No No
Trk1 | Auto 64 No No True Global No No No No

Admin-Edge

Auch die zweite im 802.1D-2004 Standard vorgesehene Variante, die Admin-Edge Ports, wird von HPE Aruba Switches unterstützt. Im Gegensatz zu Auto-Edge muss diese jedoch per Kommando durch den Administrator aktiviert werden.

Switch(config)# spanning-tree 1-8 admin-edge-port

Admin-Edge überspringt auch die 3 Sekunden Wartezeit, die mit Auto-Edge verbunden sind, und überführt die gewünschten Ports sofort in den FORWARDING Status. Die Verfügbarkeit der Ports wird also nochmals beschleunigt. Wenn Admin-Edge aktiviert wird, wird die Auto-Edge Einstellung durch den Switch nicht mehr beachtet.

Admin-Edge ist in der Lage, auf eintreffende BPDUs zu reagieren, die anzeigen, dass ein STP-aktivierter Switch angeschlossen wurde. In diesem Fall verliert der betreffende Port die Edge Eigenschaft und wird ein Non-Edge Port, der von STP verwaltet wird.

BPDU-Protection

Die zuletzt erwähnte Eigenschaft von Admin-Edge, die konfigurierten Edge Ports nach Erkennung einer BPDU in einen “regulären”, von STP verwalteten Switchport zu konvertieren, birgt Risiken. Wird ein Switch an einen Port angeschlossen, der als Edge Port vorgesehen war, so wird dies in den meisten Fällen ohne Kenntnis des Administrators erfolgen. Läuft auf dem angeschlossenen Switch eine STP Implementierung, deren Interoperabilität mit den übrigen Switches nicht gegeben ist, kann dies netzwerkweite Effekte nach sich ziehen, die die Verfügbarkeit des gesamten Netzes gravierend beeinträchtigen können.

Daher wird Admin-Edge meist mit BPDU-Protection kombiniert, einem weiteren STP Portfeature. BPDU-Protection “lauscht” auf den hierfür aktivierten Ports auf eintreffende BPDUs. Wird eine solche BPDU erkannt, fährt BPDU-Protection den Port herunter.

Switch(config)# spanning-tree 1-8 bpdu-protection

Der Port bleibt deaktiviert, bis er vom Administrator wieder aktiviert wird. Alternativ kann mit dem folgenden Kommando ein Timeout gesetzt werden, nach dem der Port wieder automatisch hochgefahren wird.

Switch(config)# spanning-tree 1-8 bpdu-protection-timeout 60

Der Timeout wird im Beispiel auf 60 Sekunden gesetzt. Das Timeout-Kommando ist nicht auf allen Plattformen verfügbar (beispielsweise nicht auf Aruba 2530).

Diskussion und Best Practice

Ein aktives Management der Edge Ports im Netzwerk ist notwendig, und zwar nicht nur um die Ports während ihrer Aktivierung schneller verfügbar zu machen, sondern auch um häufige Topologieänderungen zu vermeiden. Dies gilt insbesondere für Umgebungen mit einer großen Anzahl von Endgeräten wie PCs, die täglich gestartet werden.

Grundsätzlich kann das bei den Aruba Switches automatisch aktivierte Feature Auto-Edge hierzu eingesetzt werden. Die verzögerte Verfügbarkeit von 3 Sekunden liegt unterhalb der Dauer eines Bootvorgangs für einen typischen PC. Wird stattdessen Admin-Edge konfiguriert, kann die Verfügbarkeit nochmals beschleunigt werden. Admin-Edge sollte jedoch immer zusammen mit BPDU-Protection eingesetzt werden. So wird effektiv verhindert, dass an Edge Ports von Anwendern mitgebrachte, unbekannte Switches angeschlossen werden, auf denen STP läuft. Dies kann unvorhersehbare, katastrophale Effekte auf die STP Domäne haben und muss daher unterbunden werden.

Admin-Edge mit BPDU-Protection kann allerdings nicht effektiv den Anschluss von Switches OHNE aktiviertes STP verhindern, denn diese versenden keine BPDUs. Da STP ein Enterprise-Feature ist, welches nur in höherwertigen Switches überhaupt verfügbar ist, wird dies leider den Regelfall für dieses Szenario darstellen. Um auch diesen Fall abzufangen, kann z.B. Port Security mit einer Restriktion auf die Anzahl der MAC-Adressen pro Port eingesetzt werden.

Aruba NetEdit – Grafische Geräteorchestrierung für ArubaOS-CX

Zusammen mit den ArubaOS-CX Switches bietet Aruba mit NetEdit eine Software an, die die klassische CLI-basierte Switchkonfiguration weiterentwickelt. Noch immer ist diese Art der Verwaltung für die meisten professionellen Netzwerk Admins Mittel der Wahl. Ein wichtiger Kritikpunkt am CLI ist jedoch die mangelnde Skalierbarkeit, welche sich vor allem in größeren Switchumgebungen nachteilig auswirkt. Das Ausrollen von Änderungen auf einer großen Anzahl Switches kann hierdurch zu einer langwierigen und fehleranfälligen Angelegenheit werden. Hier setzt NetEdit an, indem es ermöglicht, Konfigurationen auf Switches parallel und entlang eines standardisierten Workflows vorzunehmen.

Es lassen sich Konfigurationsregeln festlegen, Switches anhand von Topologiedarstellungen beobachten, ausgerollte Konfigurationen automatisierten Tests unterziehen, damit Sie eine korrekte Funktion sicher stellen können. Darüber hinaus glänzt NetEdit mit vielen weiteren Features. Und bei all diesen Funktionen und der modernen grafischen Benutzeroberfläche schafft es Aruba dennoch ein wenig von dem guten alten CLI-Gefühl aufrecht zu erhalten. Wir wollen euch Aruba NetEdit in diesem Blogbeitrag vorstellen und auf die wesentlichen Features des Programms eingehen.

NetEdit Geräteverwaltung

Die von NetEdit verwalteten Geräte werden in der Benutzeroberfläche entweder tabellarisch oder in einer grafischen Darstellung der physikalischen Netzwerktopologie angezeigt.

Aruba NetEdit Topologie

Abbildung 1: Physikalische Netzwerktopologie in Aruba NetEdit

Abbildung 1 stellt die Topologieansicht mit zwei Switches dar. Die Ansichten liefern neben der reinen Anzeige eine Reihe an Filterfunktionen, um nur bestimmte Geräte anzeigen zu lassen. Den Filter können Sie dafür mit logischen Ausdrücken oder anhand grafisch dargestellter Auswahlmöglichkeiten beschreiben. Die von NetEdit verwalteten Geräte können Sie entweder einzeln hinzufügen oder sogar einen Netzabschnitt bestimmen, welcher von NetEdit in regelmäßigen Abständen durchsucht wird. In dem Netzabschnitt gefundenen Geräte werden so automatisch hinzugefügt. So behalten Sie immer den Überblick über Ihr Netzwerk. Die Stärken der Topologiedarstellung werden insbesondere in sehr großen Netzwerkumgebungen deutlich. Tabellarische Darstellungen bilden im Gegensatz zu grafischen Darstellungen häufig nur Teilinformationen ab. Einfache Zusammenhänge wie Clusterzugehörigkeiten oder nicht vorgesehene Unterschiede in der Konfiguration sind durch die Linienführung und farbliche Gestaltung in der topologischen Darstellung einfacher zu erfassen.

Häufig genutzte Teilabschnitte des Netzwerks können Sie über die Filterfunktion abspeichern und so in wenigen Schritten exklusiv im Fenster darstellen. Den Filter beschreiben Sie mithilfe von Key-Value-Paaren, welche Sie beliebig mit den Operatoren “AND”, “OR” und “NOT” verketten können. Ein Filter für alle Geräte aus dem Netzwerk 10.1.1.0/24 würde ausgedrückt als “ip:10.1.1.*”. Das * ist eine sogenannte Wildcard und steht für eine nicht definierte Anzahl beliebiger Zeichen. Neben der IP-Adresse existieren zahlreiche weitere Label, auf Basis derer das Netzwerk nach konkreten Switches durchsucht werden kann.

NetEdit Gerätekonfiguration

Mit Netedit sind Sie in der Lage, nicht nur Gerätekonfigurationen für einzelne Switches zu tätigen, sondern direkt für mehrere Geräte gleichzeitig oder gar den kompletten Netzabschnitt.

Abbildung 2: Editor von Aruba NetEdit

Der dafür zur Verfügung gestellte Editor befindet sich mit in der Browseroberfläche, wie in Abbildung 2 zu sehen ist. Dieser stellt Ihnen ganz im Stile der CLI-Konfiguration eine Befehlsvervollständigung zur Verfügung. Darüber hinaus schlägt er Ihnen auch alle weiteren Befehlsmöglichkeiten vor und markiert eventuelle Fehler. Sollten Sie mehr als nur einen Switch konfigurieren wollen, bietet der Editor ebenso die Möglichkeit, die eingegebenen Wert pro Switch zu variieren. Werte, bei denen eine solche Möglichkeit besteht, highlightet der Editor, um Ihnen den Umgang mit diesem Feature zu erleichtern. Des Weiteren werden im sogenannten Insights-Fenster kontextbasierte Informationen zu den einzelnen Konfigurationsmöglichkeiten dargestellt. Konfigurieren Sie z.B Einstellungen für ein Interface, werden im Insights-Fenster per LLDP Informationen zu den am Interface angeschlossenen Geräten dargestellt.

NetEdit Gerätekonformität

Mithilfe der Konformitätskriterien, die Sie mit NetEdit definieren können, vereinfacht NetEdit die Pflege einer homogenen Konfigurationsstruktur. So können Sie beispielsweise Mindestanforderungen für getätigte Konfigurationen schaffen, welche Sie vor dem Ausrollen einer neuen Konfiguration automatisch überprüfen lassen. Alle von NetEdit verwalteten Switches werden auf Basis dieser Kriterien beobachtet. Erfüllt ein Switch ein Kriterium nicht, alarmiert Sie NetEdit. Durch homogene Konfigurationsstrukturen behalten Sie einfacher den Überblick über ihre Switch-Konfigurationen. Das kommt besonders dann zum Tragen, wenn Ihre Switches durch mehr als eine Person verwaltet werden. Die daraus folgende Zeitersparnis wirkt sich besonders positiv während des Troubleshootings aus.

NetEdit Konfigurationsvalidierung

Nachdem Sie eine Konfiguration getätigt haben, kann NetEdit das Netz durch automatisierte Tests überprüfen. So sind Sie in der Lage, mithilfe von NetEdit sicherzustellen, dass durch die veränderte Konfiguration noch alle Funktionen im Netzwerk verfügbar sind.

Aruba NetEdit Dashboard ArubaOS-CX

Abbildung 3: Plandetails in Aruba NetEdit

Abbildung 3 zeigt das Kontextmenü eines Plans, indem Sie die Validierungsergebnisse betrachten können und Aktionen wie Ausrollen, rückgängig Machen und Abschließen des Plans tätigen können. Die Konfigurationsvalidierung erfolgt in dem Zusammenhang, noch bevor die Konfiguration komplett ausgerollt wurde. So ist es möglich, ein Troubleshooting zu betreiben, noch bevor es zu den eigentlichen Problemen kommt. Als Validierung lassen sich beliebige Befehle auf allen ssh-fähigen Geräten ausführen. Auf diese Art können Shellskripte auf Server ausgeführt werden oder beispielsweise Routingstrecken überprüft werden. Die Validierungen werden jeweils vor und nach dem Ausrollen der Konfigurationen ausgeführt, sodass Sie im Anschluss die jeweiligen Ausgabewerte miteinander vergleichen können.

 

 

NetEdit arbeitet neben den Konfigurationsfeatures Hand in Hand mit Aruba NAE und ist so in der Lage, auf Basis von Python-Skripten System- und Netzwerkdaten zu sammeln, auf deren Basis es automatisierte Fehlerbehebungen ausführen kann. Entstehen Fehlersituation kann NetEdit auf Basis der jeweiligen Fehler den Operator mittels Tools wie ServiceNow oder Slack informieren.

NetEdit wird von Aruba in Form einer virtuellen Maschine angeboten, welche bis zu einer Zahl von 25 verwalteten Geräten mit vollem Funktionsumfang kostenlos nutzbar ist. Bei mehr als 25 verwalteten Geräte fallen pro Gerät Kosten an.

Haben wir Ihr Interesse an Aruba NetEdit wecken können? Unser Team freut sich schon drauf, Sie bei Ihren Projekten mit ArubaOS-CX und NetEdit unterstützen zu können. NetEdit ist unter anderem Bestandteil unserer ArubaOS-CX Schulungen. Alle aktuellen Schulungen finden Sie hier.

Arubas offizielles Datenblatt zu NetEdit finden Sie hier.

 

Aruba 2930M PoE Switch

Aruba und HPE Befehlsübersichten

Aruba und HPE Befehlsübersichten

Unsere Aruba und HPE Befehlsübersichten sind wieder online. Egal ob alter Hase oder Neuling in der Netzwerkwelt – die Menge an Befehlen auf Netzwerkkomponenten ist so hoch, da behält kaum jemand den Überblick. Wer dazu noch herstellerübergeifend in heterogenen Netzwerken arbeitet, muss auf noch mehr Befehle zurückgreifen. Selbst bei unterschiedlichen Produktfamilien eines einzigen Herstellers, siehe ArubaOS und ArubaOS-CX, kann die Syntax bereits variieren.

In unseren Schulungen arbeiten wir deshalb mit Befehlsübersichten, um einen strukturierten Überblick zu schaffen und ein Gefühl für Zusammenhänge und Befehlshierarchien zu vermitteln. So wird selbst Neulingen in der Netzwerkwelt der Zugang zu diesen komplexen Thematiken erleichtert. Unsere Aruba und HPE Befehlsübersichten stellen wir Ihnen gerne zum Download zur Verfügung. Falls Ihnen beim Blick auf die Befehlsübersicht auffällt, dass Sie bei bestimmten Themen noch Nachholbedarf haben, helfen wir Ihnen in unseren Schulungen gerne weiter.

Apropos Schulungen: Um Ihnen in Zeiten der Corona-Pandemie maximale Flexibilität zu gewähren, können Sie diese jetzt auch als virtuelle Schulung bequem im Heimbüro absolvieren. Unsere aktuellen Termine finden Sie hier.

Aruba und HPE Befehlsübersichten

Unsere aktuellen Befehlsübersichten für HPE Comware Switches sowie für ArubaOS und ArubaOS-CX Switches findet ihr hier .

Für einen Vergleich der Syntax unterschiedlicher Netzwerkgeräte und Produktfamilien, stellt euch Aruba einen Reference-Guide zur Verfügung. Diesen findet ihr hier.

 

Weitere Dokumente

Den aktuellen Aruba AOS und AOS-CX Transceiver Guide können Sie hier herunterladen.

Alle unterstützten Software-Features können Sie hier in der Support-Matrix nachlesen.

Für eine Tabelle mit allen möglichen Kommandos unter ArubaOS 16.10 können Sie den Feature Command Index hier herunterladen.

 

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 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:

Schematische Darstellung

Versuchsaufbau ArubaOS-CX Fimrware Update

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, startet man von 2930-1 zu 2930-2 einen “Dauerping”.

ArubaOS-CX Fimrware Update

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 ArubaOS-CX Fimrware Update

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

VSX Update Status 2 ArubaOS-CX Fimrware Update

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.

ArubaOS-CX Fimrware Update

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

VSX Update Status 3 ArubaOS-CX Fimrware Update

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

VSX Update Status 4 ArubaOS-CX Firmware Updates

VSX Update Status 5 ArubaOS-CX Firmware Updates

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 ArubaOS-CX Firmware Updates

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

VSX Update Status 8 ArubaOS-CX Firmware Updates

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

VSX Status nach ArubaOS-CX Firmware Updates

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 ArubaOS LLDP PoE-Leistung

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 ArubaOS LLDP PoE-Leistung

Befehl LLDP admin-status

poe-allocated-by ArubaOS LLDP PoE-Leistung

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

Aruba Switches VSF

VSF auf Aruba 5406R zl2 Switches

Mit VSF (Virtual Switching Framework) bietet HPE beziehungsweise Aruba seit der Software Version 16.01 (5400R) bzw. 16.03 (2930F) eine leistungsstarke Virtualisierungslösung für Ihre Switches an. Technologisch wurde VSF als Technik auf Aruba Switches 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 das Ausführen redundanter Uplinks als LACP Trunks, 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 Aruba 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 gleicht er diese automatisch an. 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

 

Chassis Aruba 2930F

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.

Front Aruba 2930F

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

Das offizielle Datenblatt zu der Switchserie finden Sie hier.