Netzwerk-Monitoring mit SNMP

Ganz so einfach ist es nicht

28. August 2020, 7:00 Uhr | Martin Hirschvogel/jos
Checkmk erkennt automatisch, um welches Netzwerkgerät es sich handelt. In der Listendarstellung sind alle erkannten Services eines Switches im Monitoring zu sehen.
© Bild: Tribe29

Das Simple Network Management Protocol (SNMP) ist seit seiner Einführung Ende der 1980er-Jahre fester Bestandteil des Monitorings von Netzwerkumgebungen. Doch so einfach, wie es das „S“ suggeriert, ist es nicht. Ohne das nötige Praxiswissen drohen einige Fallstricke bei der Überwachung.

Seit seiner Einführung im Jahr 1988 hat sich SNMP als De-facto-Standard im Netzwerk-Monitoring etabliert. Viele Hersteller unterstützen das Protokoll und haben einen entsprechenden SNMP-Agenten auf ihren Netzwerkgeräten implementiert. Dieser erlaubt es Monitoring-Lösungen, verschiedene Daten, etwa zur Bandbreite, CPU-Load, Schnittstellen etc. abzufragen, ohne dass man einen zusätzlichen Agenten auf den Komponenten installieren muss. (siehe dazu auch den Artikel auf Seite 32). Mit der steigenden Anzahl an Geräten im Netzwerk  hilft eine einfache und etablierte Methode wie SNMP dabei, diese Komponenten schnell ins Monitoring aufzunehmen.

Das Protokoll bietet zwei Methoden, um Daten von den Geräten abzufragen: Polling und Traps. Beim SNMP-Polling fragt die Monitoring-Instanz in einem bestimmten Zeitintervall von beispielsweise einer Minute die Daten ab. Dieses aktive Abfragen der Werte kommt beim statusbasierenden Monitoring zum Einsatz und gilt als empfohlene Spielart. Nachteil des SNMP-Pollings ist es jedoch, dass der Administrator nicht mitbekommt, wenn zwischen zwei Abfragen ein Ereignis auftritt, etwa ein kurzzeitiger Wechsel des Interface-Status.

Mit SNMP-Traps gibt es zudem noch eine Event-basierende Variante: Tritt ein bestimmtes Ereignis auf dem überwachten Gerät auf, schickt es eine Fehlermeldung an die Monitoring-Instanz. Ein Nachteil von SNMP-Traps ist unter anderem, dass die via UDP versendeten Datenpakete verloren gehen können. Da es bei UDP keine Empfangsquittung gibt, erfährt der Administrator im Fall einer verloren gegangenen Alarmmeldung gar nicht, dass diese überhaupt versendet wurde – und es ein Problem in seinem Netzwerk gibt.

Ein weiterer Nachteil von SNMP-Traps kann die Flut der ausgelösten Meldungen sein. Ist ein Core-Switch zum Beispiel nicht mehr verfügbar, führt das in großen Netzwerkumgebungen dazu, dass tausende Switches Traps verschicken und der Trap-Empfänger – sofern er keinen vorgeschalteten Filtermechanismus hat – unter der Last der Fehlermeldungen zusammenbrechen kann. Das Monitoring ist dann im Ernstfall nicht verfügbar. Zudem muss der Administrator alle Komponenten im Netzwerk neu konfigurieren, wenn sich die IP-Adresse des Trap-Empfängers ändert.

Drei Protokoll-Varianten

In den über 30 Jahren seines Bestehens haben sich drei Varianten des Standards herauskristallisiert. SNMPv1 kommt nur noch auf sehr alten Geräten zum Einsatz – oder auf solchen, die SNMPv2c nur mangelhaft oder gar nicht unterstützen. SNMPv2c umfasst im Vergleich zu v1 Bulk-Abfragen, erlaubt also das Abrufen mehrerer Werte gleichzeitig sowie 64-Bit-Counter, die für das Monitoring von Switch-Ports mit über 1 GBit/s unabdingbar sind. Das „c“ im Versionsnamen steht zudem für Community, was bei SNMP die Rolle eines Passworts einnimmt.

Da der Datenverkehr bei v1 und v2c – inklusive Community – im Klartext verläuft, hat man mit SNMPv3 neben einer Verschlüsselung auch eine „echte“ Authentifizierung eingeführt. Version 3 umfasst mit NoAuthNoPriv (No Authentification, No Privacy), AuthNoPriv (Authentification, No Privacy) und AuthPriv (Authentification, Privacy) drei Sicherheitsebenen. Die Verschlüsselung unter v3 erfordert jedoch deutlich mehr Rechenleistung auf den Geräten, während die Authentifizierung zusätzlichen Konfigurationsaufwand für den Administrator nach sich zieht. Abhängig vom Szenario kann es demnach sinnvoller sein, SNMPvc2 für sein Monitoring zu verwenden und den Monitoring-Traffic in ein separates VLAN auszulagern.

Schlechte Implementierung auf den Geräten

Das Monitoring mit SNMP steht und fällt jedoch mit der Implementierung des Protokolls durch die Hersteller auf ihren Geräten. Diese ist häufig mangelhaft umgesetzt, sodass sie manchmal sogar dem Protokoll widersprechen und darüber hinaus gerne typische Programmierfehler enthalten. So kann es vorkommen, dass die über SNMP abgefragten Daten widersprüchlich oder gar falsch sind, Bulk-Abfragen an einem gewissen Punkt abstürzen oder so lange dauern, dass sie in ein Timeout laufen.

Immer wieder findet man zudem Fälle, bei denen Hersteller falsche Angaben zur Einheit machen, und dies nicht dokumentieren. Sie nutzen Grad Fahrenheit statt Grad Celsius oder erwähnen nicht, dass der übermittelte Wert 1/10 °C entspricht. Ein ausgegebener Wert von 0 °C kann für einen Umgebungssensor eine valide Temperaturangabe sein. Es kann aber auch bedeuten, dass der Temperatursensor defekt oder nicht erreichbar ist. Fehlt dieser Hinweis in der Dokumentation, führt dies zu Missinterpretationen und Fehlalarmen. Die Daten müssen also immer auch im richtigen Kontext gesehen werden.

Neben den bereits aufgezeigten Schwierigkeiten bei der Sicherheit und Implementierung kommt SNMP schnell an seine Leistungsgrenzen. Will ein Administrator annähernd ein Echtzeit-Monitoring aufsetzen, muss er die Intervalle der SNMP-Pollings deutlich enger takten. In der Regel betragen diese etwa eine Minute. Verkürzt er das Zeitfenster zwischen den Abfragen, erhöht er die Last auf den Komponenten im Netzwerk deutlich.

In einigen Fällen kann es außerdem sinnvoll sein, einen bestimmten Wert im Notfall nicht abzufragen – zumindest, wenn aufgrund einer schlechten Implementierung oder aus irgendeinem anderen Grund die Abfrage auf einem Gerät durch das Monitoring unmöglich ist. Dies widerspricht jedoch dem Monitoring-Ansatz, dass man alle Objekte in seiner Netzwerkumgebung überwachen sollte.

Um ein umfassendes Monitoring mit SNMP aufzusetzen, ist es daher sinnvoll, eine Monitoring-Software zu wählen, die automatisch erkennt, um welches Gerät es sich handelt. Anschließend sollte die Lösung in der Lage sein, selbstständig sinnvolle Datenabfragen für das erkannte Gerät zu initiieren und fehlerhafte Werte automatisch auszusortieren. Die Entwicklung einer solchen Software erfordert natürlich ein entsprechendes Know-how – sowohl über SNMP als auch über das zu überwachende Gerät. Der Administrator spart sich dadurch jedoch eine manuelle Konfiguration seiner Netzwerkkomponenten für das Monitoring und erhält zudem keine falschen oder ungenauen Daten. So minimiert sich der Administrationsaufwand auch für große Netzwerkumgebungen und der IT-Verantwortliche kann sicher sein, dass seine Entscheidungen auf richtigen Monitoring-Daten basieren.

Anbieter zum Thema

zu Matchmaker+

  1. Ganz so einfach ist es nicht
  2. Kein Thronfolger in Sicht

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Monitoring

Weitere Artikel zu Nimsoft

Weitere Artikel zu Toshiba Mobile Communications Division

Matchmaker+