Beiträge

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