Wie organisiert Spanning Tree ein Ethernet-Netzwerk? - Der Baum im Netzwerk

Lesezeit
10 Minuten
Bis jetzt gelesen

Wie organisiert Spanning Tree ein Ethernet-Netzwerk? - Der Baum im Netzwerk

05.06.2014 - 12:38
Veröffentlicht in:

Ethernet ist so beliebt, weil es einfach funktioniert und nicht viel kostet. Doch die Seite des Administrators sieht etwas komplizierter aus: Damit das Netzwerk rundläuft, muss er wichtige Entscheidungen treffen und den Spanning Tree planen.

Spanning Tree ist eins der grundlegenden Protokolle in Ethernet-Netzwerken. Es sorgt dafür, dass keine Netzwerkschleifen (Loops) entstehen, denn durch einen Broadcast-Sturm führen sie innerhalb kürzester Zeit zur Überlastung eines Netzwerksegments. Ethernet-Frames haben im Gegensatz zu IP-Paketen keine maximale Lebensdauer (Time to Live, TTL) und bewegen sich deshalb potenziell unendlich lange im Kreis.

Das Spanning-Tree-Protokoll erreicht die Schleifenfreiheit, indem es bestimmte Verbindungen zwischen Switches deaktiviert. Abbildung 1 zeigt drei Beispiele (A, B, C) für Netzwerktopologien, die ohne die Blockade einiger Switchports durch Spanning Tree zum Zusammenbruch des Netzwerks führen würden.

Abbildung 1: Das Spanning-Tree-Protokoll verhindert Schleifen in Netzwerktopologien.
Abbildung 1: Das Spanning-Tree-Protokoll verhindert Schleifen in Netzwerktopologien.

 

Variante A in Abbildung 1 bringt technisch keinen Vorteil und entsteht normalerweise nur aus Unachtsamkeit, meist über mehrere Switches hinweg. Die Varianten B und C hingegen sind oft gewünscht, um die Bandbreite zwischen zwei Switches zu vergrößern (Variante B), beziehungsweise um eine Redundanz für den Fall eines Kabelausfalls durch äußere Einflüsse – beispielsweise Bauarbeiten zwischen zwei Gebäuden – zu erreichen (Variante C). Die Blockade durch Spanning Tree in Variante B hebt die Bandbreitenbündelung zunächst auf.

Die Switch-Hersteller haben verschiedene, teils zueinander inkompatible Lösungen entwickelt, etwa EtherChannel, PortChannel, virtual PortChannel (Cisco) und Trunk (HP). Diese Technologien bündeln mehrere physische Ethernet-Verbindungen zu einer logischen (Variante D in Abbildung 1). Der Spanning Tree nimmt diese logische Verbindung beispielsweise als eine 2-GBit-Verbindung statt als zwei separate 1-GBit-Verbindungen wahr und blockiert daher keine der beiden.

Variante C lässt sich durch diese Technologien allerdings nicht optimieren. Hier empfiehlt sich der Einsatz einer anderen physischen Verkabelung, die die Dreiecksverbindung zwischen den Switches ersetzt.

Für jedes VLAN, also ein logisches Netzwerksegment, wird ein eigener Spanning Tree berechnet. Dieser Artikel beschränkt sich deshalb auf ein VLAN. Das Spanning-Tree-Protokoll existiert heute hauptsächlich in den Ausprägungen Rapid Spanning Tree (RST) und Rapid per VLAN Spanning Tree oder Multiple Spanning Tree (MST), da die ursprüngliche Form des Spanning Trees zu hohen Konvergenzzeiten und damit in komplexen Topologien zu Ausfällen von 30 bis 50 Sekunden führt.

Wahlen ohne Demokratie

Die Berechnung des Spanning Trees erfolgt in drei wesentlichen Schritten:

  • Wahl der Root Bridge,
  • Wahl der Root Ports,
  • Wahl der Designated Ports.

Es gibt verschiedene Rollen und Zustände (siehe Kasten "Rollen und Zustände der Switchports"), die ein Switchport einnehmen kann. Die Variante Rapid Spanning Tree fasst Disabled, Blocking und Listening zu Discarding zusammen.

Rollen und Zustände der Switchports

In einem Spanning Tree nimmt jeder Port eines Switches eine von vier möglichen Rollen ein:

  • Root Port: aktiver Switchport, dessen Upstream in Richtung Root Bridge zeigt. Jeder Switch besitzt höchstens einen Root Port.
  • Designated Port: aktiver Port, der weg von der Root Bridge (Downstream) zeigt.
  • Alternate Port (nur bei Rapid Spanning Tree): Zeigt ebenfalls zur Root Bridge, ist aber nicht aktiv (Blocked).
  • Backup Port (nur bei Rapid Spanning Tree): Verbindung zu einem anderen Switch, der über einen anderen Switchport günstiger erreicht werden kann; ebenfalls nicht aktiv (Blocked).

Neben den beschriebenen Rollen gibt es vier Zustände, die ein Port nacheinander einnimmt: Blocking, Listening, Learning und Forwarding. Im zusätzlichen Zustand Disabled verwirft ein Port sämtliche Pakete. Das gilt auch in den ersten drei genannten Zuständen; in ihnen empfängt und verarbeitet ein Port ausschließlich sogenannte BPDUs (Bridge Protocol Data Units), die Informationen über das Netz und den Spanning Tree transportieren. In den Zuständen Listening und Learning überträgt ein Port solche Pakete auch weiter, in letzterem lernt er dazu die Adressen anderer Netzwerkteilnehmer. Nur im Forwarding-Modus schließlich leitet ein Port darüber hinaus auch Datenpakete weiter.

Damit Spanning Tree die Gesamttopologie berechnen kann, wird zunächst die Root Bridge gewählt. Sie bildet den Referenzpunkt des gesamten Spanning Tree und berechnet die Pfade und Einstellungen des Baums. Die Wahl der Root Bridge erfolgt aufgrund der Bridge-ID, die sich aus drei Bestandteilen zusammensetzt:

  • Bridge Priority
  • System-ID-Extension
  • MAC-Adresse

Die Bridge Priority liegt zwischen 0 und 61440 und ist in Schritten von 4096 konfigurierbar. Die System-ID und die MAC-Adresse sind nicht frei wählbar; MAC-Adressänderungen sind zwar möglich, aber nicht empfohlen. Je höher der Wert der Bridge Priority liegt, desto weniger kommt der entsprechende Switch als Root Bridge in Frage. Ein Switch mit der Bridge Priority 0 übernimmt höchstwahrscheinlich die Root Bridge, es sei denn, ein weiterer Switch im Netz hat ebenfalls diesen Wert.

Sollte mehr als ein Switch die gleiche minimale Bridge Priority besitzen, geben System-ID-Extension und MAC-Adresse den Ausschlag bei der Wahl zur Root Bridge. Dabei gewinnt der Kandidat mit den niedrigsten Werten. Erstere entspricht der VLAN-Nummer.

Bei den MAC-Adressen unterbieten ältere Switches oft ihre aktuellen Nachfolger, da viele Hersteller sie aufsteigend vergeben. Dadurch besteht die Gefahr, dass der älteste und potenziell schwächste Switch zur Root Bridge wird. Da Spanning-Tree-Berechnungen in großen Netzen aufwendig ausfallen, sollte hingegen ein möglichst leistungsfähiger Switch die Rolle der Root Bridge übernehmen.

Design-Guides der Hersteller empfehlen, die Root Bridge in der Aggregations- bzw. Distributionsebene zu platzieren, um kurze Konvergenzzeiten bei Ausfällen zu erreichen (Abbildung 2).

Abbildung 2: Die Root Bridge eines Netzwerks sollte in der Aggreations-/Distributionsebene Platz finden.
Abbildung 2: Die Root Bridge eines Netzwerks sollte in der Aggreations-/Distributionsebene Platz finden.

 

Auf Cisco-Switches erfolgt die Konfiguration der Bridge Priority mittels spanning-tree vlan VLAN priority oder alternativ mit dem Root-Bridge-Makro spanning-tree vlan VLAN root [primary | secondary]. Es konfiguriert die Priorität automatisch anhand der aktuell im Netz vorhandenen Root Bridge, läuft aber nur einmalig beim Aufruf und nicht dauerhaft im Hintergrund.

Putsch gegen die Root Bridge

Der Austausch der Informationen über die Spanning-Tree-Topologie zwischen verschiedenen Switches erfolgt über sogenannte BPDUs (Bridge Protocol Data Unit). Grundsätzlich sendet und empfängt jeder Switchport BPDUs. Diese Eigenschaft bietet allerdings Angreifern die Möglichkeit, die Topologie auszulesen und mit gefälschten BPDUs zu verändern. Gegenmaßnahmen heißen BPDU-Guard und -Filter (siehe Kasten "BPDU-Guard und -Filter").

BPDU-Guard und -Filter
  • BPDU-Guard deaktiviert einen Switchport, sobald er ein BPDU-Paket empfängt. Die Ursache kann in einem Angriff oder im unerlaubten Anschließen eines Switches liegen. Optional aktiviert der BPDU-Guard einen abgeschalteten Switchport mit einem Timer nach Ablauf einer gewissen Zeit automatisch wieder. BPDU-Guard sollte auf jedem Access-Switchport konfiguriert sein. Das geschieht im Interface mit spanning-tree bpduguard enable oder global mit spanning-tree portfast bpduguarddefault.
  • BPDU-Filter verhindert, dass ein Switch BPDUs über einen Switchport verschickt. Auch dieses Feature sollte auf jedem Access-Port aktiviert sein mit spanning-tree bpdu-filter enable im Interface oder global mit spanning-tree portfast bpdufilter default.

Auch nachdem die Root Bridge gewählt und der gesamte Spanning Tree aktiv ist, können weitere Switches dem Netzwerk beitreten, beispielsweise bei der Installation eines neuen Stockwerk-Switches. Hat eins der neuen Geräte eine niedrigere Bridge Priority, würde es dann zur neuen Root Bridge. Das zöge allerdings eine Änderung der gesamten Netzwerktopologie und damit möglicherweise suboptimale Pfade sowie Performance-Engpässe nach sich.

Schutz gegen eine versehentliche oder auch böswillige Änderung der Root Bridge bietet der Root Guard [1].

Abbildung 3 zeigt eine Ausgangslage, in der Switch D zum Netzwerk hinzukommt. Unterbietet dessen Bridge Priority aus einem der genannten Gründe die der bisherigen Root Bridge, ändert sich die Topologie daraufhin wie in Abbildung 4.

Abbildung 3: Hat der neue Switch D eine niedrigere Bridge-Priority als Switch A…
Abbildung 3: Hat der neue Switch D eine niedrigere Bridge-Priority als Switch A…
Abbildung 4: … ändert Spanning Tree die Netzwerktopologie.
Abbildung 4: … ändert Spanning Tree die Netzwerktopologie.

 

Um diese Umstellung zu verhindern, konfiguriert man den Root Guard auf dem in Richtung Switch D weisenden Port von Switch C. Das Feature deaktiviert den betreffenden Switchport, sobald er eine BPDU mit einer zu niedrigen Bridge Priority empfängt.

Kosten, Kosten, Kosten

Beim Betrieb des Netzwerks stehen neben der Zuweisung der Root Bridge weitere Berechnungen an. Bei der Wahl der Root Ports und der Designated Ports, spielen die Verbindungskosten eine wichtige Rolle. Die Spanning-Tree-Standardkosten für unterschiedliche Bandbreiten stellt Tabelle 1 dar. Die vordefinierten Werte führen allerdings dazu, dass eine 40- und eine 100-GBit-Verbindung die gleichen Spanning-Tree-Kosten ergeben wie auch ein PortChannel aus zwei 10-GBit-Verbindungen, bei dem sich die Kosten aus der Gesamtbandbreite aller zusammengefügten Verbindungen berechnet. Um in solchen Situationen detaillierter zu reagieren, sind die Spanning-Tree-Verbindungskosten falls nötig pro Port einzeln konfigurierbar.

Tabelle 1
Verbindungskosten

Bandbreite

Kosten

10 MBit/s

100

16 MBit/s

62

100 MBit/s

19

200 MBit/s

12

622 MBit/s

6

1 GBit/s

4

10 GBit/s

2

20+ GBit/s

1

Abbildung 5 stellt eine Beispieltopologie aus vier 100-MBit-Switches dar, in der Switch 4 die Root Bridge übernimmt. Da alle Verbindungen eine Geschwindigkeit von 100 MBit pro Sekunde haben, belaufen sich die Kosten für jeden Port gemäß Tabelle 1 auf 19. Die einzige Ausnahme bildet der PortChannel zwischen Switch 3 und Switch 4, der in Summe 200 MBit pro Sekunde und damit einen Kostenwert von 12 vorweist.

Abbildung 5: Bei 100-MBit-Leitungen zwischen allen Ports ergeben sich für alle Wegkosten Werte von 19, außer für die gebündelten Leitungen zwischen den Switches 3 und 4.
Abbildung 5: Bei 100-MBit-Leitungen zwischen allen Ports ergeben sich für alle Wegkosten Werte von 19, außer für die gebündelten Leitungen zwischen den Switches 3 und 4.

 

Aus diesen Kosten ergibt sich, dass der Root Port (in der Abbildung abgekürzt als RP) von Switch 1 in Richtung Switch 3 zeigt. Der gegenüberliegende Switchport wird zum Designated Port (abgekürzt als DP), weil die Kosten auf diesem Weg nur 31 (19+12) betragen, auf dem Weg über Switch 2 jedoch 38 (19+19). Gäbe es zwischen Switch 3 und Switch 4 keinen PortChannel, ergäben sich zwei gleich teure Wege von Switch 1 zur Root Bridge (Switch 4). Dann würden zur Berechnung des Weges die Bridge-IDs herangezogen, wobei die niedrigere ID den Ausschlag gibt.

Alle Switchports der Root Bridge (Switch 4) sind Designated Ports, ebenso wie alle Ports, die einem Root Port gegenüberliegen. Bei der Verbindung zwischen Switch 1 und Switch 2 erfolgt die Bestimmung der Port-Rollen – die möglichen Optionen lauten hier Designated und Blocked – durch die Wegkosten zur Root Bridge. Bei Switch 2 betragen sie 19, bei Switch 1 hingegen 31. Somit werden die Ports zwischen Switch 1 und 2 zu Blocked beziehungsweise Designated Ports. Dies gilt analog auch für die Verbindung zwischen den Switches 2 und 3: Die Wegkosten von Switch 3 zur Root Bridge betragen 12, deshalb wird der Port Richtung Switch 2 zum Designated Port.

Aus der beschriebenen Spanning-Tree-Berechnung ergeben sich in Abbildung 5 die Blockaden zwischen den Switches 1 und 2 sowie zwischen 2 und 3. Die Kommunikation zwischen 1 und 2 erfolgt deshalb über den Umweg über die Switches 3 und 4.

Die in Abbildung 5 gezeigte Topologie demonstriert, dass die Position der Root Bridge im Netzwerk eine wichtige Rolle spielt. Dies gilt auch für Spanning-Tree-Weiterentwicklungen, die die Zahl blockierter Switchports minimieren. Denn neben den optimalen Wegen gilt es auch die Notwendigkeit eventueller Spanning-Tree-Neuberechnungen bei Switch-Ausfällen zu bedenken, die für optimale Geschwindigkeit ein möglichst leistungsfähiger Switch ausführen sollte.

Weitere Gefahren

Scott Hogg, Technologiechef der Netzwerktechnikfirma GTRI, beschreibt in seinem Blog [2] weitere häufige Fehler im Zusammenhang mit Spanning-Tree-Konfigurationen. Einer davon betrifft nicht beachtete Größenbegrenzungen eines Spanning Trees, also der maximalen Anzahl hintereinandergeschalteter Switches. Im Idealfall verhindert eine sternförmige Verkabelung hintereinandergehängte Switches vollständig, aber dies ist beispielsweise bei einem Campus mit mehreren Gebäuden oft unmöglich.

Eine weitere grundsätzliche Schwäche von Spanning Tree besteht darin, dass der Algorithmus beim Ausbleiben von BPDUs auf einem Port davon ausgeht, dass daran kein Switch angeschlossen ist. Doch dieser Schluss ist potenziell falsch und Fehlkonfigurationen oder Software-Fehler führen so möglicherweise dazu, dass es trotzdem zu Schleifen im Netzwerk kommt.

Eine mögliche Ursache für ausbleibende BPDUs liegt in einem Hardware-Fehler. Bei Glasfaserverbindungen kann einer der beiden Kanäle Schaden nehmen, sodass die Verbindung zwar weiterhin BPDUs empfangen, aber nicht senden kann. Gegen diese Probleme im Layer 1 des Netzwerkschichtenmodells hilft die Unidirectional Link Detection (UDLD) [4]. Diese Methode ergänzt der LoopGuard [3], der Software-Bugs mit der gleichen Folge aufspürt.

Dem Trugschluss, aus dem Spanning Tree aus dem Ausbleiben eingehender BPDUs folgert, es sei kein Switch angeschlossen, begegnet außerdem die Bridge Assurance. Diese Technik sollte deshalb auf allen Switchports, die eine Verbindung zu anderen Switches herstellen, aktiviert sein. Ausnahmen bilden verschiedene Ausprägungen von Multichassis-Etherchannels, beispielsweise ist Bridge Assurance nicht für Ciscos virtual PortChannels (vPC) empfohlen.

Damals und heute

In älteren Ethernet-Netzwerken ist eine Topologie wie in Abbildung 6 denkbar. Darin hat Spanning Tree im Layer-2-Bereich die Hälfte aller Links deaktiviert und der Server (unten) nutzt nur eine von zwei Verbindungen. Die Rolle der Root Bridge übernimmt der Switch AGG1. Er bildet mit AGG2 die Grenze zwischen Layer 2 und Layer 3, die beiden heißen deshalb Layer-3-Switches, obwohl laut des OSI-Schichtenmodells ein Switch in Layer 2 arbeitet. Auf den beiden Layer-3-Switches läuft ein First Hop Redundancy Protocol (FHRP), entweder mit dem offenen Standard VRRP oder beispielsweise über Ciscos proprietäres Pendant HSRP. Das Protokoll ist allerdings nur auf AGG2 aktiv. Der First Hop ist das IP-Standard-Gateway des Servers.

Abbildung 6: Der ursprüngliche Spanning-Tree-Algorithmus führt in diesem Setup zu einem suboptimalen Pfad vom Server zum Gateway.
Abbildung 6: Der ursprüngliche Spanning-Tree-Algorithmus führt in diesem Setup zu einem suboptimalen Pfad vom Server zum Gateway.

 

Das Problem des suboptimalen Weges der IP-Pakete vom Server zum Gateway (AGG2) in Abbildung 6 entsteht, weil aufgrund der durch Spanning Tree blockierten Verbindungen alle gerouteten Pakete den Umweg über AGG1 nehmen. Um das Problem zu beheben, müsste im Beispiel entweder AGG2 die Root Bridge übernehmen, oder das FHRP-Protokoll auf AGG1 aktiviert werden. In einer komplexeren Topologie fallen die Auswirkungen einer solchen ungünstig platzierten Root Bridge wie in Abbildung 6 oft noch wesentlich gravierender aus.

Non-Blocking-Architektur

Aufgrund der hohen Port-Preise und Performance-Anforderungen bei Data-Center-Switches ist das Blockieren von Links durch Spanning Tree generell nicht wünschenswert. Deshalb bieten verschiedene Hersteller Abhilfe, um mehrere physische Verbindungen zwischen zwei Switches oder zwischen einem Switch und einem Server zu jeweils einer logischen Verbindung zusammenzufassen (Abbildung 7). Einige Lösungen ermöglichen sogar die Zusammenfassung von mehr als zwei Switches.

Abbildung 7: Multichassis-Etherchannel fasst Switches und Netzwerkverbindungen zu logischen Einheiten zusammen.
Abbildung 7: Multichassis-Etherchannel fasst Switches und Netzwerkverbindungen zu logischen Einheiten zusammen.

 

Die Aggregations-Switches AGG1 und AGG2 verhalten sich in Abbildung 7 nun wie ein großer Switch AGG und die beiden Access-Switches ACC1 und ACC2 bilden den logischen Switch ACC. Dafür sorgt beispielsweise die Multichassis Etherchannel-Technik. Das Betriebssystem des Servers fasst wiederum die beiden Verbindungen zu ACC1 und ACC2 zu einer logischen Verbindung zusammen (Netzwerk-Bonding), sodass die volle Bandbreite zur Verfügung steht. Letzteres ermöglicht beispielsweise das Link Aggregation Control Protocol (LACP).

Skalierbarkeit von Layer 2

Die in Abbildung 7 dargestellte Topologie skaliert grundsätzlich gut, allerdings ergeben sich in großen Netzen einige neue Herausforderungen durch die Möglichkeiten der Virtualisierung. Abbildung 8 zeigt eine Beispieltopologie. Rack 1 und Rack 2 verwenden darin das gleiche VLAN, was die Migration einer virtuellen Maschine von Rack 1 in Rack 2 im laufenden Betrieb erlaubt, etwa mit VMotion von VMWare. Andererseits steht pro Rack häufig nur ein VLAN zur Verfügung, um auch bei einer großen Anzahl virtueller Maschinen die Broadcast-Domäne möglichst klein zu halten – wie bei den Racks 3 und 4.

Abbildung 8: Virtuelle Umgebungen schaffen auch fürs Netzwerk neue Herausforderungen.
Abbildung 8: Virtuelle Umgebungen schaffen auch fürs Netzwerk neue Herausforderungen.

 

Neben der genannten Einschränkung bei der Mobilität virtueller Maschinen bildet bei Multichassis-Etherchannel die Beschränkung auf zwei Switch-Paare einen limitierenden Faktor. Dazu kommt die teils lange Konvergenzzeit von Spanning Tree, auch wenn sie mit Rapid Spanning Tree kürzer als im ursprünglichen Protokoll ausfällt. Sind mehrere hundert VLANs im Einsatz, dauert die Neuberechnung des Spanning Tree beim Ausfall der Root Bridge dennoch etwas.

Um diesen Herausforderungen zu begegnen, erlauben einige proprietäre Protokolle Topologien wie in Abbildung 9. Das Fundament dafür legt der offizielle IETF-Standard Trill (Transparent Interconnection of Lots of Links). Er ermöglicht Equal Cost Multipathing auch in Layer-2-Netzwerken, statt wie zuvor nur in Layer-3-Netzen.

Abbildung 9: Der Trill-Standard und Ciscos FabricPath-Protokoll erlauben die Aggregation von Netzwerkverbindungen.
Abbildung 9: Der Trill-Standard und Ciscos FabricPath-Protokoll erlauben die Aggregation von Netzwerkverbindungen.

 

Auch das Cisco-eigene FabricPath basiert auf Trill, bietet aber erweiterte Möglichkeiten. So lernt bei FabricPath jeder Switch nur die MAC-Adressen, die er wirklich benötigt – in klassischen Layer-2-Netzen und bei Trill hingegen speichert jeder Switch alle MAC-Adressen. Die verkleinerten Adresstabellen führen bei FabricPath zu einer besseren Performance und vermeiden, dass Switches an die Speichergrenzen ihrer Hardware stoßen.

Alle Verbindungen zwischen den einzelnen Switches in Abbildung 9 werden beim Einsatz von Cisco-Geräten im FabricPath-Modus betrieben, aktiviert wird dieser durch den Befehl switchport mode fabricpath. Das Fabric Shortest Path First-Protokoll bewerkstelligt das Layer-2-Routing und verwendet im Hintergrund wiederum IS-IS (Intermediate System to Intermediate System). Der Einfluss von Spanning Tree endet an dieser Stelle – es handelt sich nicht mehr um Ethernet-Verbindungen, sondern um bloßes FabricPath.

Die Verbindung zu klassischen Ethernet-Switches ist aber weiterhin möglich. An der Schnittstelle betritt Spanning Tree wieder die Bühne. Es betrachtet die gesamte FabricPath-Instanz wie einen einzigen großen Switch, wird dabei aber nicht durch den FabricPath hindurch propagiert. Alle FabricPath-Switches mit Verbindung zu einem Ethernet-Switch erhalten die gleiche Bridge Priority, empfohlen ist der Wert 8192.

Der Anschluss eines Servers ans FabricPath-Netzwerk erfolgt über Ethernet. Die Switchports für Server sind entsprechend als Ethernet-Ports konfiguriert und nicht als FabricPath-Ports. VLANs, die über FabricPath transportiert werden sollen, konfiguriert der Befehl mode fabricpath als FabricPath-VLANs.

Fazit

Spanning Tree bildet einen grundlegenden Bestandteil eines Ethernet-Netzwerks. Seine Konfiguration erfordert deshalb große Sorgfalt, um auch im Fehlerfall die Stabilität des Netzwerks zu garantieren.

Der Autor Hannes Kasparick ist Solution-Designer für Rechenzentrumsinfrastruktur und Virtualisierung. Im Urlaub erkundet er fremde Länder.

Autor: Hannes Kasparick Artikel aus dem Admin Magazin Ausgabe 3/2014: Disaster Recovery Seite 112

Ähnliche Beiträge

Netzwerkverwaltung an der Medizinischen Universität Wien

Die IT-Abteilung der Medizinischen Universität Wien betreibt das Netzwerk der Universität, wozu die Betreuung von rund 10.000 Anschlüssen sowie Hunderten Endgeräten und Servern gehört. Für diese Aufgabe wurde eine neue Informations- und Planungssoftware für Kabelmanagement und Netzwerkdokumentation implementiert. Das neue Werkzeug ist flexibel, skalierbar und deckt die steigenden Sicherheitsanforderungen voll ab.

Im Test: Sunbird DCIM

Das DCIM-Werkzeug Sunbird verspricht die umfassende Verwaltung von Assets im Rechenzentrum mit vielen nützlichen Funktionen, ansprechender Oberfläche und maximalem Komfort. Dies gelingt mit der Software auch in geografisch verteilten Landschaften. Dabei liefert Sunbird wertvolle Daten zum Zustand und Energieverbrauch, und schafft somit einen guten Einblick in das RZ-Geschehen.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.