Erste Hilfe fürs Netzwerk II
Fehler: DAU in Aktion
Wie recht Becker mit seinem Ratschlag zur ersten Analyse auf Netzebene 0 hat, zeigt auch ein Blick in das COMPUTERWOCHE-Forum "Aufgehängt - Das Problem sitzt vor dem Rechner". Dort schildert ein Leser, wie er wegen dem Netzproblem "Internet geht nicht mehr" gerufen wurde. Vor Ort war das Problem schnell gelöst: Alle LEDs des Switch waren aus, denn man hatte die 220 Volt Steckdose für das Handy-Ladegerät benötigt.
Fehler: Netzdesign
Die konsequenteste Fehlervermeidung beginnt für Becker allerdings bereits im Vorfeld beim Netzdesign: "Komplexe Netze mit VoIP und anderen Echtzeit-Anforderungen lassen sich nicht einfach mit einem gesunden Halbwissen aufbauen." Hier sei eine konsequente Bedarfsanalyse gefordert, die sich dann im Design niederschlagen müsse. Und dieses sei dann später bei der Umsetzung akribisch zu dokumentieren, denn gerade vergessene Komponenten oder Altlasten würden später häufig für unerklärliche Phänomene sorgen: "Sie ziehen etwa ein Kabel und dürften eigentlich keine Netzanbindung mehr haben, der Rechner bleibt aber weiter munter im Netz." Im vorliegenden Beispiel entpuppte sich ein längst vergessener Hub als Übeltäter.
Fehler: Loop im Netz
Ein anderer typischer Fallstrick lauert für Becker in den so genannten gewachsenen Netzen - also LANs oder Corporate Networks, die je nach Bedarf von Zeit zu Zeit erweitert werden. Oft werden hier nachträglich Kabel gezogen, die dann später zu den krudesten Phänomen führen, wenn die Installation nicht sauber dokumentiert wurde. So können etwa Schleifen (Loops) im Netz entstehen, die dann ein Switched Network, das eigentlich auf dedizierten Verbindungen basiert, ausbremsen. Denn ein solcher Loop verursacht einen Broadcast-Sturm, der ein ganzes Netzsegment lahmlegen kann. Um das Problem zu vermeiden, hat der Netzbetreuer zwei Optionen: Das Aktivieren des Spanning Tree Protcols (STP), das aber oft von Unmanaged Switches nicht unterstützt wird, oder die Verwendung einer Loopback Detection (LBD), wie sie von verschiedenen Herstellern unter diversen Bezeichnungen offeriert wird.
Becker bevorzugt das LBD-Verfahren, denn der Spanning Tree wartet noch mit einigen Tücken auf - doch dazu später mehr. Bei der Loopback Detection ist dann zwischen einem Port- und VLAN-basierenden Verfahren zu unterscheiden. Während ersteres den Port komplett abschaltet, blockiert letzteres den Verkehr nur im VLAN, ohne den ganzen Port zu sperren.
Fehler: Fehlende Segmentierung
Gerade diese Segmentierung ist ein Grund, warum Becker den Einsatz von VLANs empfiehlt: "Sie erhöhen nicht nur die Sicherheit, sondern begrenzen Störungen auf ein Netzsegement." So blieben beispielsweise Broadcast-Stürme auf ein virtuelles LAN-Segement begrenzt und zögen nicht die gesamte Infrastruktur in Mitleidenschaft.
Allerdings bergen die VLANs in Kombination mit dem Spanning Tree Protocol (STP) auch eine Gefahr. Wie D-Link-Mann Becker aus der Praxis weiß, kommt es durchaus vor, dass das STP ein VLAN deaktiviert, wenn es um Redundanzen zu vermeiden eine physikalische Netzverbindung abschaltet. Auf den ersten Blick erschient dieses Phänomen unverständlich, doch die Erklärung fällt einem wie Schuppen von den Augen, wenn man sich das theoretische Konzept hinter STP verdeutlicht. Ursprünglich wurde STP entwickelt, um in geswitchten Umgebungen zwei sich widersprechende Anforderungen zu realisieren: Zum einen die Vermeidung mehrfacher Netzpfade zum Ziel, um eine Verdoppelung der Datenpakete zu verhindern; zum anderen die gleichzeitige Redundanz der Netzpfade; um beim Ausfall einer Strecke eine alternative Verbindung zu haben.
Genau diese Steuerung übernimmt STP beziehungsweise das Rapid Spanning Tree Protocol (RSTP) als neuere Variante. Hierzu kommunizieren die Switches über das Bridge-Protokoll miteinander. Zuerst wird eine sogenannte Root Bridge bestimmt, die das Oberkommando übernimmt und Startpunkt des Verbindungsbaumes (Tree) ist. Root wird normalerweise die Bridge mit der niedrigsten ID, die sich aus Priorität und MAC-Adresse ergibt. Existieren redundante Wege, so nehmen die Switches den Port mit den geringsten Pfadkosten zur Root Bridge und deaktivieren die anderen Ports, darunter eventuell auch ein VLAN.
Zudem weist das Konzept, sieht man einmal von Umschaltzeiten von bis zu 30 Sekunden ab (RSTP etwa eine Sekunde), im Fall einer Störung noch zwei andere gravierende Nachteile auf: kommt etwa ein neuer Switch in das Netz, dann kann dieser eventuell aufgrund seiner ID die Aufgabe der Root Bridge automatisch übernehmen und die ursprünglichen Verbindungszuordnungen stimmen nicht mehr, was zu Performance-Problemen führen kann. Ebenso kann es passieren, dass bei einem Ausfall ein Switch die Root-Bridge-Funktion übernimmt, der so ungünstig positioniert ist, dass das Netz zusammenbricht. Eine weitere Gefahr stellen in gewachsenen Netzen neue, ergänzende Kabel dar, die womöglich die Struktur des Spanning Trees zerstören, da sich keine eindeutigen Pfadkosten berechnen lassen.
Angesichts dieser Fallstricke rät der Consultant, "den Spanning Tree nicht sich selbst zu überlassen, sondern etwa für einen Ausfall eine Ersatz-Root-Bridge selbst festzulegen." Wer mit VLANs arbeitet, sollte zudem überlegen, ob er nicht mit dem Multiple Spanning Tree Protocol (MSTP) arbeitet. Dieses wird den Anforderungen der VLANs besser gerecht, da es in einem LAN mehrere Instanzen des Spanning Tree erlaubt. Für Anwender, die mit Hilfe des Spanning Tree einen Ring zur Erhöhung der Ausfallsicherheit nachbilden wollen, hat Becker noch einen anderen Ratschlag: Statt auf STP oder RSTP zu setzen, empfiehlt er herstellerspezifische Verfahren - bei D-Link etwa das Rapid Ethernet Ring Protection (RERP) - zu verwenden, da diese teilweise mit Umschaltzeiten von 200 Millisekunden aufwarten und die spezifischen STP-Nachteile nicht haben.