SNMP: A Necessary Evil

Wie geht es den Switches und Routern in Ihrem Netzwerk? Sind die NAS-Appliances noch verfügbar? Wie ist die Geschwindigkeit einer speziellen Schnittstelle? Ist die Temperatur im Server-Raum auch nicht zu hoch? Mit SNMP (Simple Network Management Protocol) können Sie alle Arten von Informationen über Ihre Netzwerkkomponenten erhalten.

Da viele Hardwarehersteller das Protokoll unterstützen, lassen sich Daten von Netzwerk-Switches, Routers, USVs und Stromversorgungsgeräten, NAS-Appliances, Druckern, etc. abrufen und in Ihrer Monitoring-Software nutzen. Das Überwachen dieser Daten kann dabei helfen, Entscheidungen basierend auf Fakten zu treffen, statt zu raten. Das kann Ihnen dabei helfen, Fehler zu vermeiden noch bevor diese auftreten.

In diesem Blogpost wollen wir eine Einführung in SNMP und ihre Geschichte geben. Wir wollen erklären, wie OIDs (Object Identifiers) und MIBs (Managed Information Bases) arbeiten und wofür man sie benötigt. Wir sprechen außerdem über die Vor- und Nachteile von SNMP und teilen ein paar Insights von unseren Entwickeln, die tagtäglich SNMP-Checks schreiben. Natürlich zeigen wir Ihnen auch, wie Sie Ihre Geräte mit Checkmk monitoren können.

Einige Fakten über SNMP

Fangen wir mit einer kurzen Übersicht über SNMP an und wie sich das Protokoll über die letzten Dekaden entwickelt hat. Es gibt drei Hauptversionen. SNMPv1, das älteste, ist aus den späten 80er Jahren. Es wurde ursprünglich als Standard für die Verwaltung von Netzwerkgeräten über IP (Internet Protocol) entwickelt. Über 30 Jahre später ist es immer noch im Einsatz, obwohl es unsicher und ineffizient ist. Version 1 benötigt lediglich eine Community – dabei handelt es sich um eine Art Passwort – das im Klartext vorliegt. Wenn es mit der im SNMP-Agenten gespeicherten Community übereinstimmt, gewährt es den Zugang. SNMP-v1 unterstützt nur 32-Bit-Counter, was für heutige Gigabit-Netzwerke nicht ausreichend ist und Probleme verursacht, da die Counter zu schnell überlaufen, meistens sogar mehr als einmal zwischen den Abfragen.

Warum das eine Rolle spielt? Wir rechnen das mal nach: Die höchste Nummer, die ein 32-Bit-Counter speichern kann ist 2^32 = 4.294.967.296 – knapp vier Milliarden. Wenn Sie die Anzahl an Oktetts überwachen wollen, die ein voll ausgelastetes 1-Gbit-Interface erhält: Dabei handelt es sich um eine Milliarde Bits pro Sekunde. Ein Oktett hat 8 Bits. So empfangen Sie pro Sekunde rund 125 Millionen Oktetts. Nach 34 Sekunden haben Sie über vier Milliarden Oktetts erhalten und der Counter bricht um und startet wieder bei 0. Yay!

SNMPv2c unterstützt 64-Bit-Counter für Interfaces mit hohen Kapazitäten. Der v1-Nachfolger sendet jedoch weiterhin Daten im Klartext über das Netzwerk, aber führt eine neue, optimierte Möglichkeit ein, um Management-Daten in Bulk-Transfers zu senden und zu empfangen. SNMPv2c und SNMPv1 sind zudem nicht kompatibel.

SNMPv3 fügt der v2c Sicherheitsfunktionen hinzu und unterstützt sowohl Authentifizierung via MD5 oder SHA-1 als auch eine Verschlüsselung mittels DES, AES 128 und in manchen Fällen auch AES 256. Natürlich unterstützt SNMPv3 auch eine Kombination aus beiden. Sie können sich bei SNMPv3 zwischen drei verschiedenen Sicherheitsebenen entscheiden: NoAuthNoPriv (no authentification, no privacy), AuthNoPriv (authentication, no privacy) und AuthPriv (authentication and privacy). Seit MD5 und SHA-1 als unsicher gelten, sollten Sie sicher gehen und zwei verschiedene Passwörter festlegen, wenn Sie auf dem Gerät das Passwort für Authentifizierung und Verschlüsselung festlegen.

Beachten Sie: Die Verschlüsselung unter SNMPv3 benötigt deutlich mehr Prozessorleistung, sodass es die Geräte signifikant verlangsamt. Das ist auch der Grund, warum Version 3 ein nerviger Flaschenhals sein kann, etwa auf großen, modularen Switchen (lesen Sie hierzu auch die Sektion: „Ist SNMP großartig oder ist es ätzend?“). Viele Geräte unterstützen außerdem immer noch Version 1 als Ergänzung zu Version 2 – aber bitte versuchen Sie SNMPv1 aufgrund des Umbruchproblems zu vermeiden.

OID und MIB – Was zum Hack?

Wie bereits erwähnt sammelt SNMP Daten und übermittelt diese vom verwalteten Gerät zur Monitoring-Software. Je nach Gerät kann es sich um eine Information über den Toner oder über ausgedruckte Seiten eines Druckers, die Bandbreite einer Netzwerk-Schnittstelle, den Lüfterstatus eines Servers etc. handeln. Jede einzelne Information ist ein Objekt, das einen eigenen, einzigartigen Identifier besitzt, beispielsweise eine individuelle Adresse. Diese Adresse wird OID (Object Identifier) genannt.

Bei einer OID handelt es sich um eine lange Zahlensequenz, die durch Punkte getrennt ist. Beispielsweise:

1.3.6.1.2.1.2.2.1.5

Dies ist eine hierarchische Ordnung, die einer Baumstruktur folgt. Sie wird von links nach rechts gelesen und startet mit der Wurzel (1 = ISO), gefolgt von der ersten untergeordneten Notiz (3 = identified organization) und so weiter. Das folgende Bild zeigt eine Reihe an relevanten Pfaden in diesem Baum.

Die meisten Teile des Baums sind standardisiert. Sie sollten beispielsweise immer die Informationen mit Bezug zu den Netzwerk-Interfaces unter OIDs unter dem Zweig 1.3.6.1.2.1.2 finden. Darüber hinaus kann jeder Hersteller eigene OIDs in einem Unterverzeichnis haben. Der blaue Bereich auf dem Schaubild zeigt einen Teil von Ciscos OID-Baum (unter 1.3.6.1.4.1.9). Es gibt sowohl generische OIDs (linker Baum) als auch spezifische Produkt-OIDs, etwa ein Cisco UCS (rechter Zweig).

Um eine OID lesen zu können, benötigt man einen Übersetzer. Die MIB (Management Information Base) liefert Namen, Definitionen und Beschreibungen für die Objekte. Die Konvertierung einer OID in etwas menschlich lesbares ist ein bisschen wie die Dekodierung von IP-Adressen mit der Hilfe von DNS. Seit eine Menge Hardwarehersteller ihr eigenes OID-Zahlen-Muster verwenden, ist ihr eigenes MIB notwendig, um die Zahlen verstehen und übersetzen zu können.

Bitte beachten Sie: Kunden fragen oft nach MIB-Checks. Aber denken Sie daran, dass MIB nur eine Übersetzung ist. In anderen Worten, es ist nicht die Lösung, sondern der Weg zur Lösung.

Ist SNMP großartig oder ist es ätzend?

SNMP ist weiterhin der De-facto-Standard im Netzwerk-Monitoring. Viele Geräte unterstützen das Protokoll – und manchmal auch nur das – sodass man nahezu alles – von Traffic/Bandbreite und CPU Load bis hin zum Lüfterstatus eines RAID-Systems, Klimaanlagen und Türalarmen – mit SNMP überwachen kann. Weil SNMP einen standardisierten Weg bietet, die Daten einzusammeln, ist es außerdem mit verschiedenen Monitoring-Lösungen kompatibel.

Dennoch hat das SNMP-Monitoring einige signifikante Nachteile. Die Abfrage eines Geräts über SNMP ist langsam und ziemlich ineffizient. Im Vergleich zu SNMPv1 hat Version 2 die Dinge zwar etwas verbessert, SNMPv3 macht die Dinge jedoch mit der zusätzlichen Sicherheit wieder schlechter – wenn ich mit den MD5/SHA-1-Algorithmus ansehe, möchte ich das Wort „Sicherheit“ lieber in Anführungszeichen setzen.

Tipp: Wenn die Verschlüsselung Ihre Umgebung deutlich verlangsamt, sollten Sie überlegen, wieder zu v2c zurückzugehen und das Traffic-Management aus Sicherheitsgründen in ein separates VLAN auszulagern.

Nur weil viele Geräte SNMP unterstützen, heißt das nicht, dass alle Hersteller einen guten Job bei der Implementierung geleistet haben. Eine schlechte Performance ist für Administratoren eine Qual, die ein Gerät überwachen, bei dem SNMP-Abfragen mit einem Timeout enden. Eine schlechte SNMP-Implementierung ist jedoch für jene noch ärgerlicher, die Checks für eine Monitoring-Lösung entwickeln. Unsere Entwickler haben bereits alle Arten von schlecht umgesetzten SNMP-Stacks gesehen. Denken Sie nur an verschiedene Zeitformate: Einige Länder nutzen YYYY/MM/DD, andere DD/MM/YYYY oder DD/MM/YY und sogar MM/DD/YY. Vor einigen Wochen haben wir einen Check für ein SNMP-Gerät geschrieben, bei dem der Hersteller dachte, dass die Nutzung von drei Zahlenstellen für das Tagesformat eine gute Idee wäre. Wir können inzwischen locker ein ganzes Buch über „SNMP stories from hell“ schreiben.

Natürlich kann die MIB helfen, aber um eines klarzustellen: Die MIB ist nicht der heilige Gral und eine Menge der gespeicherten Informationen kann sogar nicht korrekt sein. Wo sie möglicherweise Bytes erwarten, finden sie beispielsweise Bits und so weiter. Das ist übrigens auch der Grund, warum wir kein großer Fan von Check-Generatoren sind, die man mit einer MIB füttert, um einen Check zu erzeugen. Es kann funktionieren aber meistens werden sie eher Zeit damit verbringen, fehlerhafte Checks manuell zu fixen.

Ein weiterer Rat unserer Conultants ist es, ein Cross-Monitoring mit SNMP zu vermeiden. Versuchen Sie niemals, Ihre Switches, Routers etc. mit mehr als einem SNMP-Tool anzusteuern. Auch wenn das Gerät eine leistungsstarke CPU haben sollte, ist es möglicherweise keine gute Idee, zwei Monitoring-Server oder irgendein anderes Tool zu konfigurieren, um das Gerät gleichzeitig zu überwachen.

Zusammenfassend lässt sich sagen: Nutzen sie SNMP nur, wenn es keine andere Möglichkeit gibt. SNMP strapaziert das Zielsystem und die Monitoring-Software zu sehr, wenn es nicht richtig implementiert wird – was leider häufig der Fall ist. Wenn Sie einen guten, leichtgewichtigen Agenten für das Monitoring verwenden können, nutzen Sie ihn. Wenn eine gute API verfügbar ist, verwenden Sie lieber die. Wir empfehlen beispielsweise die NetApp-API für das Monitoring zu verwenden, da sie deutlich besser implementiert ist als der SNMP-Agent. Erst wenn Sie keinen Agenten auf dem Gerät installieren können und es keine gute API gibt, sollten Sie auf SNMP zurückgreifen.

SNMP-Monitoring mit Checkmk

Checkmk unterstützt ein Monitoring via SNMP für eine Vielzahl von Geräten, darunter Switches, Router, USVs und Stromversorgungsgeräten, NAS-Appliances, Drucker, etc. Wir bieten nur keine generischen Checks für diese Geräte an. Stattdessen haben wir über die letzten Jahre viele spezifische Checks geschrieben, die unseren Kunden helfen. Sie haben uns wertvolle Hinweise und Ratschläge gegeben, um sicherzustellen, dass wir mit unseren Checks die richtigen Dinge überwachen und sinnvolle Standard-Schwellenwerte festlegen.

In der Annahme, dass Ihr DNS korrekt funktioniert, müssen Sie nur den Host-Namen eines neuen Geräts sowie die Community (v1, v2c) beziehungsweise das Password des Geräts für die Authentifizierung und Verschlüsselung (v3) eingeben. Checkmk wird daraufhin die richtigen Checks für das Gerät bestimmen und die Services automatisch erkennen – ohne dass Sie irgendwas zusätzlich konfigurieren müssen.

Welche Geräte Checkmk unterstützt, können Sie in unserem Katalog mit allen Check-Plugins nachschlagen. Klicken Sie auf einen Listeneintrag, um detaillierte Informationen über den unterstützten Agenten (Checkmk-Agent, Hersteller-API, SNMP) zu erhalten. Checkmk kann unter Nutzung der Event Consol auch SNMP-Traps behandeln. Mehr Informationen hierzu finden Sie in unserem Handbuch.

SNMP spielt auch weiterhin eine wichtige Rolle

Jetzt kennen Sie den Unterschied zwischen den verschiedenen Protokollversionen und wissen, was OIDs und MIBs sind. Wir haben außerdem erklärt, wie Sie mit Checkmk alle möglichen Geräte mit SNMP monitoren können. Für uns hat es sich gut angefühlt, sich ein bisschen über SNMP oder vielmehr über die schlechten Implementierungen des Protokolls durch die Hersteller auszulassen. Dennoch bleibt festzuhalten: SNMP spielt auch weiterhin eine wichtige Rolle bei der Überwachung physikalischer Geräte und wird das wahrscheinlich auch noch eine ganze Weile lang sein. Ohne SNMP wären die Dinge viel schlimmer – es ist einfach ein notwendiges Übel mit dem wir leben müssen.

Dies ist der erste Artikel einer Reihe von Blogposts über das Netzwerk-Monitoring mit SNMP. Bleiben Sie dran für mehr #monitoringlove.