Leistungs- und Fehlermanagement

Mit Hilfe des Leistungs- und Fehlermanagements wird die Überwachung und Fehlerdiagnose des Switch durchgeführt. Besonders in Netzen mit mehreren Switches kann es bedingt durch den Spanning-Tree Algorithmus (siehe dazu [ID97,Hal92,BRIa,BRIb]) zu Problemen oder Leistungseinbußen kommen. Dies ist dann der Fall, wenn der Spanning-Tree Algorithmus versagt. Ein Grund hierfür kann zum Beispiel ein Switch sein, der den Spanning-Tree Algorithmus nicht versteht, was eher selten der Fall sein dürfte, oder der per Hand an die Bedürfnisse des geswitchten Netzes angepaßt wurde. Die vorgestellten Attribute und Methoden dienen dem Auffinden von Störungen oder Engpässen und sollen helfen, den Switch durch Veränderung seiner Attribute dem gewünschten Einsatzgebiet optimal anzupassen.

Kommen mehrere Switchen in einem Rechnernetz zum Einsatz, so müssen folgende Attribute eines Switch definiert werden, die Eigenschaften des Spanning-Tree Algorithmus beschreiben:

• designated root (8.5.3.1) Der eindeutige Verweis auf den Switch, der als root akzeptiert wird. Dieser Wert wird in allen BPDU's, die der Switch verschickt, versendet.
• root path cost (8.5.3.2) besitzt den Wert, den es kostet den root-Switch zu erreichen. Der root-Switch selber erhält den Wert null.
• root port (8.5.3.3) verweist auf den Port des Switch, der den niedrigsten Wert (root path cost (8.5.3.2)) auf dem Weg zum root-Switch annimmt.
• hello time (8.5.3.5) zeigt das Zeitintervall an, das zwischen dem Verschicken von BPDU's vergeht, wenn der Switch selbst der root-Switch ist oder versucht dieser zu werden.
• forward delay (8.5.3.6) bezeichnet die Zeit, die ein Port im listening oder learning state verbringt, bevor er in den learning bzw. forwarding state übergeht.
• bridge hello time (8.5.3.9) zeigt das Zeitintervall an, das zwischen dem Verschicken von BPDU's vergeht, die dem Anzeigen von Topolgieänderungen dienen.
• bridge forward delay (8.5.3.10) nimmt den Wert von forward delay an, wenn der Switch selbst der root-Switch ist oder versucht dieser zu werden.
• flags kann den Wert TOPOLOGY_CHANGE_DETECTED (8.5.3.11), TOPOLOGY_CHANGE (8.5.3.12) oder NONE annehmen. Ersterer Wert gibt an, daß eine Topologieänderung auf- oder angezeigt wurde; zweiterer, ob die letzte empfangene BPDU eine Topologieänderung angezeigt hat (im Falle eines root-Switch), oder ob eine solche während einer definierten Zeit, der sogenannten Topology Change Time (8.5.3.13), entdeckt wurde. Ist beides nicht der Fall, so steht das Flag auf NONE.

Mit der Methode debug() läßt sich der PC-basierte Switch dazu veranlassen, mehr über seine Tätigkeit auszugeben. So kann er bspw. Statusmeldungen über den Empfang und Versand von Ethernet-Frames an einem bestimmten Port mit Quell- und Zieladresse ausgeben oder das Senden einer BPDU anzeigen. Dies dient der Fehlersuche und dessen Behebung. Aus Sicht der Top-Down Modellierung wäre eine Ausgabe dieser Meldungen an einen event channel (siehe Kapitel 2.3.1) eine geeignete Methode, da somit die erzeugten Meldungen durch das Konzept der Entkopplung von Sender und Empfänger durch den event channel optimal in eine verteilte Managementlösung eingebunden werden. Durch den Einsatz der Filterungsmöglichkeiten bei der Eventbehandlung können die Debugmeldungen von anderen Statusmeldungen des Switch getrennt werden. Betrachtet man den PC-basierten Switch hingegen aus Sicht des Bottom-Up Ansatzes, so ist eine Ausgabe der Debugmeldungen an den klogd sinnvoll, der die Meldungen aufgrund ihrer Kernelherkunft entgegennimmt. Grund hierfür ist die vorhandene Implementierung des Switchingcodes (siehe hierzu Kapitel 5.1.1), der die Ausgabe von Debugmeldungen an den klogd vorsieht. Bei der späteren Implementierung wird deswegen zweiterer Ansatz gewählt. Eine -- auch parallele -- Erweiterung um das event channel-Konzept ist jedoch durchaus denkbar.

Mittels der Methode stats() lassen sich im Hinblick auf das Leistungsmanagement die Anzahl der Pakete pro Protokoll mitprotokollieren (stats(enable/disable)), anzeigen (stats(show)) und zurücksetzen (stats(zero)). Es ist denkbar, diese Daten in einem Abbrechnungsmanagement einzusetzen.

Schließlich weist die Methode set_bridge_priority() dem Switch eine neue Identität zu. Dabei laufen mehrere Schritte ab, die in [ID97] (8.8.4) genauer erläutert sind. Zusammengefaßt läßt sich sagen, daß die Methode set_bridge_priority() den Switch komplett neu initialisiert.