Ausschwärmen

In großen Netzen fällt es schnell schwer, den Überblick zu behalten. Manch Administrator wünscht sich hier ein Werkzeug, dass automatisch das Netz durchforstet, alle Geräte mit ihren Verbindungen katalogisiert, alle Hosts kennt, die Infrastruktur grafisch darstellt und außerdem noch auf Schwierigkeiten hinweist sowie frei verfügbar ist. NeDi (Kurzform von „Network Discovery“) ist eine solche eierlegende Wollmilchsau.

Die eigenen Netze durchsuchen

Grundlage jeglichen Netzwerkmanagements ist die genaue Kenntnis des eigenen Netzes. Kerndaten hierfür sind, welche Router und Switches verbaut sind und welche Rechner sich dort tummeln. Werkzeuge können dem Administrator diese Informationen beschaffen, indem sie die Netze scannen und nach verwertbaren Informationen suchen. In großen Netzen (beispielsweise 10.0.0.0/8) und besonders mit IPv6 ist diese Strategie zum Scheitern verurteilt, weil ein Scanvorgang zu viel Zeit erfordert. NeDi geht deshalb bei der Erfassung aller Komponenten im Netz wesentlich intelligenter vor: Es fragt einige wenige sogenannte Seed Devices nach weiteren Geräten, die diese kennen. Als Protokoll hierfür kommt das Simple Netzwerk Management Protocol (SNMP) zum Einsatz, der Internet Standard (IETF RFC) zur Verwaltung von Geräten in Netzen. Per SNMP-Abfragen erfährt NeDi beispielsweise vom Default-Router alle Nachbarn, die dieser kennt.

NeDi verfügt über verschiedene Möglichkeiten, ein Gerät nach dem nächsten Nachbarn zu fragen. So kann es in Routing-Tabellen nach bekannten Next Hops suchen oder die ARP-Tabellen auslesen. Netzwerkgeräte von Cisco erkennen sich gegenseitig über das proprietäre Cisco Discovery Protocol (CDP). Alternativ dazu existiert das von mehreren Herstellern unterstützte Local Link Discovery Protocol (LLDP). Alle so ermittelten Devices übernimmt NeDi in die Liste noch zu durchsuchender Geräte auf und arbeitet diese rekursiv ab. Der Durchlauf endet, sobald diese Liste keine neuen Einträge mehr enthält.

Wenn NeDi schon einmal dabei ist, jedes Gerät im Netz abzufragen, sammelt es gleich zusätzliche Informationen ein. Das fängt mit Systemnamen und -klasse an, geht weiter über das Betriebssystem inklusive Versionsnummer, CPU-Last, Speicherauslastung, Temperatur, Durchsatz und Fehler auf den einzelnen Schnittstellen und natürlich alle angeschlossenen Hosts in den konfigurierten VLANs. NeDi identifiziert Hosts über ihre MAC-Adresse und Netzwerkgeräte über ihren Systemnamen (siehe Abb. 1).

Nach einem Durchlauf hat NeDi alle notwendigen Informationen für eine Abbildung des kompletten Netzes und kann Auskunft darüber geben, an welchem Switch und Port ein bestimmter Rechner angeschlossen oder wie ein Switch an den Core angebunden ist. Das Tool kennt alle Verbindungen zwischen den Geräten. Es beurteilt alle gesammelten Daten bei jedem Durchlauf und gibt Informationen, Warnungen oder Alarme aus, falls es etwas Ungewöhnliches gefunden hat. Das kann beispielsweise ein zu heißer Switch oder ein überlasteter Router sein oder zu viele Fehler auf einem Anschluss (siehe Abb. 2). Dabei liefert das Programm nicht nur die Informationen, welche Geräte tatsächlich im Netz vorhanden sind, sondern lässt sich auch als einfaches Netzwerkmanagementsystem einsetzen.

Konfiguration und Datenspeicher

Da sich NeDi alle Informationen per SNMP besorgt, ist die zentrale Option in der Konfigurationsdatei nedi.conf der Community String – respektive Username und Passwort beim Einsatz von SNMPv3. Zusätzlich finden sich dort die Zugangsdaten zu einer Datenbank. Alle Informationen, die das Programm während seiner Streife durch das Netz gefunden hat, legt es dort ab.

Diese Angaben sind für einen erfolgreichen Einsatz verpflichtend, alle anderen Optionen in der Konfigurationsdatei dienen nur noch dazu, das Programm zu optimieren. Geräte, die nicht auf SNMP antworten, kann der Administrator hier ebenso eintragen wie die Grenzen des eigenen Netzes. So muss NeDi diese nicht erst durch aufwendige Timeouts selbst herausfinden.

Wie eine einfache Konfiguration aussehen kann, zeigt das Listing rechts. Darüber hinaus existiert eine Reihe weiterer Optionen, die das Verhalten des Scan-Tools steuern. Alle Parameter sind aber in der mitgelieferten Beispielkonfiguration gut dokumentiert.

# SNMP community string
comm         public

# Eigenes Netzwerk (regex!)
netfilter    ^10

# Datenbankanbindung (MySQL, möglich sind
#            auch PostgreSQL oder Oracle)
backend      MSQ

dname        nedi
dbuser       nedi
dbpass       secret
dbhost       localhost

Intern speichert NeDi sein gesammeltes Wissen in einer einfach strukturierten Datenbank. Der Entwickler hat bewusst keine Optimierungen vorgenommen, um die INSERT-Operationen sowie Befehle während des Durchsuchens nicht mit JOINs zu belasten. Ein schöner Nebeneffekt ist die Tatsache, dass die Datenbank dauernd zur Verfügung steht und sich somit als Basis für ein Asset Management System anbietet. In der Tabelle devices stehen alle Informationen über Geräte im Netz bereit, die NeDi tatsächlich gefunden hat. Mit wenigen Abfragen kann der Administrator beispielsweise herausfinden, ob ein separates Netzwerkmanagementsystem auch alle gefundenen Geräte überwacht. Ebenso einfach ist der Abgleich der gefundenen Hosts mit dem Asset Management, worüber sich schnell Rechner im Netz lokalisieren lassen, von denen der Administrator eventuell nichts weiß.

NeDi selbst bietet auch Berichte zur Aggregation der Informationen in der Datenbank. Auf Knopfdruck erfährt der Administrator, welche Gerätetypen zum Einsatz kommen und welche Betriebssysteme darauf laufen. Genau so schnell ist eine Übersicht erstellt, die die Schnittstellen mit den meisten Fehlern zeigt.

In der Datenbank stehen allerdings nur die aktuellen Daten des letzten Suchdurchlaufs. Neben dem obligatorischen Eventlog merkt sich NeDi alle wesentlichen historischen Daten in Round-Robin-Datenbanken (RRDB). Hier finden sich alle Werte zu CPU-Last, Temperatur oder Speicherauslastung sowie die Werte zu allen Schnittstellen. Das Vorhalten dieser Historie erfordert pro Gerät und Schnittstelle etwa 120 kByte Platz. Bei 100 Geräten und 5000 Schnittstellen kommt so schnell ein halbes Gigabyte an Daten zusammen. Ein Administrator ist deshalb gut beraten, auf der für NeDi vorgesehenen Partition genügend freien Platz vorzusehen.

Ein Bild sagt mehr als tausend Worte

Erwartungsgemäß bietet die Oberfläche des Tools eine grafisch aufbereitete Ausgabe dieser Daten an. Zu jeder automatisch gefundenen Schnittstelle kann der Administrator eine MRTG-ähnliche (Multi Router Traffic Grapher) Grafik für Durchsatz, Fehler, verworfene Pakete und Broadcasts abrufen.

Zusätzlich merkt sich NeDi einige Daten zum gesamten Netz. Auf Knopfdruck lassen sich so Grafiken über die Anzahl der angeschlossenen Endgeräte ebenso abrufen wie eine Übersicht der vorhandenen Schnittstellen und deren tatsächliche Nutzung. Weitere Optionen sind Angaben zur Auslastung einzelner Netze oder der für Power-over-Ethernet (PoE) benötigte Energieverbrauch.

Ein bisschen Geografie und Topologie

NeDi versucht, alle entdeckten Geräte automatisch nach Standort zu klassifizieren. Es liest den Wert sysLocation aus der SNMP-Tabelle system aus und interpretiert ihn nach dem Muster

Region;Stadt;Gebäude;Stockwerk;[Raum;]
  [Platzierung im Raum;][Zusatzinformation] 

Damit NeDi seine volle Stärke ausspielen kann, sollte der Administrator diese Informationen auf allen Geräten pflegen. Denn so lassen sich die Berichte entsprechend filtern und beispielsweise auf Knopfdruck sämtliche Geräte an einem bestimmten Standort ausgeben.

Filter kann der Administrator aber an jeder Stelle der GUI einsetzen. Berichte lassen sich durch reguläre Ausdrücke auf die passenden Informationen begrenzen. So ist die Suche nach einem Modul mit einer bestimmten Seriennummer ebenso einfach wie die nach allen Geräten mit einer Betriebssystemversion.

Nach jedem Durchlauf weiß NeDi wie die Geräte im Netz miteinander verbunden sind und wo sie tatsächlich stehen. Unter dem Menüpunkt „Topology -> Map“ kann der Administrator sich einen Überblick über das gesamte Netz ausgeben lassen. Das Tool geht erst einmal davon aus, dass die Standorte der Geräte richtig konfiguriert sind, und zeigt deshalb eine geografische Ansicht. Mit der Auswahl „Main -> flat“ kann der Administrator deshalb festlegen, dass die Darstellungsroutine diese Informationen nicht beachten soll und erhält sofort einen Gesamtüberblick über sein Netz. Dieser Überblick kann allerdings schnell unübersichtlich geraten, falls NeDi viele Geräte kennt. Hier kann der Punkt „Name & Filter“ zu mehr Durchblick verhelfen. Mit den dortigen Eingaben lässt sich die Darstellung auf einen Teil begrenzen. Mit vernünftiger Benennung der Geräte kann man sich zum Beispiel nur den Core ansehen oder die Auswahl auf ein Gebäude beschränken.

Interessant ist auch der Filter „Neighbour“. Hier liefert das Tool die direkten Nachbarn zu allen Geräten, auf die der reguläre Filterausdruck passt. Abbildung 3 zeigt als Ergebnis nach dem Anwenden des Filters switch1[12] die Devices und ihre Nachbarn.

Die Technik im Hintergrund

NeDis Herz – die Suchmaschine – ist in Perl geschrieben. Den Zeitbedarf für einen Durchlauf kann der Administrator mit dem Kommando time stoppen. Optimieren lässt sich ein Durchlauf, indem man die Grenzen des eigenen Netzes definiert und alle Geräte, die nicht auf SNMP antworten, explizit von der Suche ausnimmt. Ansonsten scannt die Suchmaschine ein einzelnes Gerät im Durchschnitt innerhalb von 10 Sekunden. Ein großer Switch mit Hunderten Schnittstellen und VLANs kann aber auch schon einmal fünf Minuten in Anspruch nehmen.

Sind die Durchläufe optimiert, richtet man einen Cron-Job ein, der in den entsprechenden Zeitabschnitten das Netz erneut untersucht. Natürlich muss man immer einen Kompromiss zwischen Aktualität und Granularität und damit der Menge an Daten finden.

Das GUI von NeDi ist dagegen in PHP geschrieben. Dessen Autor Remo Rickli nutzt hierfür eine klassische LAMP-Architektur. Administratoren mit ein wenig Scripting-Erfahrung dürften sich sowohl im Perl-Suchskript als auch im PHP-GUI schnell zurechtfinden. Für Erweiterungen und Patches ist der Autor immer dankbar.

Etwas aufwendiger wird es, wenn das Management-Werkzeug die Geräte im eigenen Netz nicht richtig oder – schlimmer noch – gar nicht erkennt. Für die Modellierung eines Gerätes nutzt es sogenannte Definitions-Dateien. Diese legen fest, mit welcher sysObjectID NeDi Geräte einer bestimmten Klasse identifiziert, nach welchen OIDs es diese Geräteklasse fragen darf und was sie letztlich bedeuten.

Modellieren eigener Geräte

So nutzt zum Beispiel Cisco eine andere OID für die CPU-Auslastung (cisco.9.109.1.1.1.1.5.9) als Geräte des Herstellers HP (hp.2.14.11.5.1.9.6.1.0). Viele OIDs sind in den Standard-MIBs der MIB-2 festgelegt. Diverse Parameter sind aber auch herstellerspezifisch und über die MIBs des enterprises-Baums definiert.

Glücklicherweise lassen sich Definitionsdateien für NeDi mit jedem handelsüblichen Editor erzeugen und bearbeiten. Das GUI verfügt sogar über einen eigenen Definitions-Editor, in dem es die OIDs der potenziellen Parameter erfragt. Bringt NeDi also die passende Definition für die Geräte im eigenen Netz nicht mit, kann der Administrator ausgehend von den Definitionen ähnlicher Devices sich selber eine passende zusammenstellen. In der Definition legt der Administrator auch fest, wie die Darstellung der Geräte dieser Klasse später in der Grafik erfolgen soll. Router, Switches oder Firewalls erhalten logischerweise unterschiedliche Symbole.

Mit diesem Werkzeug im eigenen Netz lassen sich Netzwerk- und Asset-Management gut automatisieren. Der Administrator kann sich wieder wichtigen Fragen zuwenden.

Dr. Michael Schwartzkopff

ist für die sys4 AG als Berater und Trainer für die Themen Monitoring, Hochverfügbarkeit und IT-Sicherheit tätig.

Alle Links: www.ix.de/ix1211127 (avr)