Eine Geräteliste ist kein Netzplan

Das Inventar kennt vierhundert Geräte. Modell, Seriennummer, Standort, Verantwortlicher, alles gepflegt. Ein Netzplan ist das trotzdem nicht, und der Unterschied fällt genau dann auf, wenn man ihn braucht: um drei Uhr nachts, wenn ein Switch ausfällt und jemand wissen will, was daran hängt.

Eine Liste kennt Knoten. Ein Plan braucht Kanten.

Woher die Kanten kommen

Die Verbindungsinformation liegt nicht im Inventar, sondern in den Geräten selbst. Switches und Router erzählen ihren direkten Nachbarn regelmäßig, wer sie sind, über welchen Port sie senden und was sie können. Jedes Gerät führt daraus eine lokale Nachbarschaftstabelle.

Der herstellerneutrale Standard dafür ist LLDP, festgelegt in IEEE 802.1AB. Cisco hat mit CDP ein eigenes, proprietäres Gegenstück, das dasselbe leistet, aber nur unter Cisco-Geräten. Beide arbeiten auf Schicht 2, tauschen ihre Angaben als TLV-Felder aus und legen das Ergebnis lokal ab, wo es per SNMP abgefragt werden kann.

Genau dort scheitern die meisten automatischen Netzplan-Versuche. Ein Werkzeug kann per SNMP fleißig Systemnamen, Uptimes und Schnittstellenzähler einsammeln und trotzdem keine einzige Kante kennen, weil die Nachbarschaftstabelle eine andere Abfrage ist als der Rest.

Die Stolperfalle im eigenen Haus

Bei uns heißt das konkret: Der SNMP-Import der Topologie speist sich aus LLDP- und CDP-Daten, und die entstehen ausschließlich durch Agent-Aufgaben vom Typ SNMP Scan. Der ähnlich klingende Typ SNMP Discovery sammelt OID-Werte ein, liefert aber keine Nachbarschaftsdaten. Wer den falschen wählt, bekommt einen leeren Import und keine Fehlermeldung, denn technisch hat alles funktioniert.

Die zweite Voraussetzung liegt außerhalb des Werkzeugs: LLDP beziehungsweise CDP muss auf den Switches überhaupt aktiv sein. In vielen Netzen ist es bewusst abgeschaltet, weil ein Protokoll, das Gerätenamen und Portbezeichnungen ins Netz ruft, im Zugangsbereich nichts zu suchen hat. Das ist eine vertretbare Entscheidung. Sie bedeutet nur, dass der Plan dort von Hand entsteht.

Was der Import nicht liefert

Nachbarschaftsdaten beschreiben, was tatsächlich verkabelt ist. Sie sagen nichts darüber, was gemeint war. Segmentierung, VLAN-Zonen, die Trennung zwischen Produktions- und Verwaltungsnetz, all das ist Absicht und steht in keiner Tabelle. Deshalb trennt das Modul physische, logische und hybride Topologien: Die physische Sicht lässt sich importieren, die logische muss jemand denken.

Als zweiten Startpunkt gibt es den Rack-Import, der alle Geräte eines Racks als Elemente übernimmt. Auch er liefert Knoten, keine Kanten, aber er erspart das Abtippen.

Warum der Plan sonst wieder veraltet

Jeder kennt den Netzplan, der in einer Zeichendatei liegt und seit zwei Umbauten nicht mehr stimmt. Der Grund ist immer derselbe: Die Kästchen sind Beschriftungen. Sie wissen nichts von dem Gerät, das sie darstellen, und niemand merkt, wenn es ausgetauscht wurde.

Im Designer lässt sich jedes Element deshalb mit einem echten Objekt verknüpfen, über einen Picker mit den Reitern DCIM-Geräte, IT-Systeme, Netzwerke und Racks. Ein verknüpftes Element ist ein Verweis, keine Zeichnung. Es zeigt weiterhin auf denselben Datensatz, wenn der sich ändert.

Der praktische Rat aus der Dokumentation ist entsprechend unspektakulär: Elemente konsequent verknüpfen statt nur zu beschriften, physische und logische Sicht über den Topologie-Typ trennen statt zu vermischen, fertige Pläne auf veröffentlicht setzen und veraltete archivieren statt zu löschen. Ein archivierter Plan beantwortet später die Frage, wie es vorher aussah.

Mehr auf der Modulseite zur Netzwerk-Topologie.