SNMP Monitoring: Was ist SNMP und wie behalten Sie Ihre Netzwerk-Performance in Echtzeit im Blick?

SNMP (Simple Network Management Protocol) ist das Standardprotokoll, mit dem IT-Teams Netzwerkgeräte überwachen und verwalten. 

Ein zentrales System (der Manager) fragt Geräte (Agents) nach Daten wie CPU-Auslastung, Speichernutzung oder Interface-Traffic ab. Die Geräte antworten mit strukturierten Werten aus einer lokalen Management Information Base (MIB). 

Es läuft über UDP-Port 161 für Abfragen und 162 für Alerts. Es funktioniert auf nahezu jedem Router, Switch, Server, jeder USV und jedem Storage-Array und liegt in drei Versionen vor (v1, v2c und v3). Nur SNMPv3 bietet integrierte Authentifizierung und Verschlüsselung.

In diesem Leitfaden gehen wir Schritt für Schritt durch, wie SNMP end-to-end arbeitet, was die Komponenten leisten und welche Version Sie wählen sollten. Außerdem zeigen wir, wie Sie SNMP konfigurieren und absichern, wie Sie Fehler eingrenzen und wo das SNMP Protokoll an Grenzen stößt.

Was ist SNMP?

SNMP ist ein Standardprotokoll, mit dem ein Monitoring-System (der SNMP-Manager) über ein gemeinsames Nachrichtenformat Zustands- und Performance-Daten von Netzwerkgeräten sammelt. Geräte mit unterschiedlichen Betriebssystemen (ein Cisco-Switch, ein Linux-Server, eine APC-USV) beantworten SNMP-Abfragen alle über dasselbe Protokoll, auch wenn die konkret bereitgestellten Daten je nach Gerät variieren. Ein einziges Tool überwacht so die gesamte Umgebung.

Der Name kann allerdings täuschen. SNMP ist in der Praxis nicht immer einfach zu verwenden, kommt bei weit mehr als klassischen Netzwerkgeräten zum Einsatz und wird in den meisten Umgebungen vor allem für Monitoring und weniger für aktives Management genutzt. 

SNMP dient hauptsächlich dazu, Daten über Geräte zu erfassen, beispielsweise CPU-Auslastung, Speichernutzung, Interface-Traffic, Temperatur, Lüfterstatus, verbleibende Batterielaufzeit einer USV oder den Zustand von Laufwerken in einem Storage-System. Nahezu alle Netzwerkgeräte unterstützen SNMP. Das gilt auch für viele Serverbetriebssysteme, Storage-Systeme und einige Anwendungen.

Warum SNMP wichtig ist

SNMP bietet eine kostengünstige und breit unterstützte Möglichkeit, den Zustand Ihrer Infrastruktur kontinuierlich zu überwachen und Probleme zu erkennen, bevor Nutzer davon betroffen sind. 

Ohne SNMP muss jemand Dashboards und andere Monitoring-Tools im Blick behalten oder auf Beschwerden warten. Mit SNMP kann ein einziges System Tausende Geräte regelmäßig abfragen und automatisch bei Problemen alarmieren. Genau hier setzt professionelles Netzwerk-Monitoring an.

SNMP-Komponenten: Manager, Agent, MIB und OID

SNMP besteht aus vier Kernkomponenten:

1. Der Manager fragt Daten ab und empfängt Alerts.
2. Der Agent antwortet und kann außerdem Alerts senden.
3. Die MIB definiert, welche Daten auf einem Gerät vorhanden sind.
4. Der OID ist die eindeutige Adresse eines einzelnen Datenpunkts innerhalb der MIB.

Wie diese Komponenten zusammenspielen

Ein Manager fragt einen Agent standardmäßig über UDP-Port 161 ab. Der Agent schlägt die angeforderte OID in seiner lokalen MIB nach und liefert den Wert zurück. Derselbe Agent kann außerdem unaufgefordert Alerts (Traps) über UDP-Port 162 an den Manager schicken, wenn ein Schwellenwert überschritten wird oder sich ein Zustand ändert.

Der Manager (Network Management Station)

Der Manager ist jedes System, das SNMP-Abfragen sendet und Alerts (Traps oder Informs) empfängt. Das kann ein einzelner Linux-Rechner sein, der snmpwalk über die Kommandozeile ausführt, ein einfaches Tool wie What's Up Gold, oder eine vollwertige Plattform wie LogicMonitor. Bei dieser Plattform führen unsere Collectors die Abfragen aus, und unser SaaS-Backend speichert die Daten, analysiert sie und erzeugt daraus Alerts. 

Alles, was SNMP-Abfragen initiiert, gilt als Manager. Ein einzelnes Gerät kann sowohl einen Manager als auch einen Agent betreiben.

Der Agent

Der Agent ist die Software auf dem überwachten Gerät. Sie erfüllt zwei Aufgaben. Sie beantwortet Abfragen des Managers, und sie sendet Alerts (Traps oder Informs), wenn konfigurierte Ereignisse eintreten. 

Bei Routern, Switches und Firewalls ist der Agent in der Regel bereits in die Firmware integriert. Auf universell einsetzbaren Servern (Linux, Windows, Solaris, AIX, FreeBSD) muss ein entsprechender Agent installiert werden. Unter Linux wird häufig Net-SNMP eingesetzt, dessen SNMP-Agent als snmpd-Daemon läuft.

Die MIB (Management Information Base)

Die MIB ist eine strukturierte Datenbank, die in reinen Textdateien definiert ist. Sie beschreibt in einer Baumstruktur jeden Datenpunkt, den ein Gerät melden kann. 

Standard-MIBs decken das ab, was jedes Gerät bereitstellen sollte, etwa Interface-Zähler, Systemname und Uptime. Hersteller-MIBs decken gerätespezifische Daten ab, zum Beispiel die verbleibende Laufzeit einer APC-USV oder die Temperatur einer bestimmten Cisco-Line-Card. 

Ein Gerät stellt Daten bereit, indem es die vom Hersteller definierten MIBs implementiert.

Der OID (Object Identifier)

Ein OID ist die numerische Adresse eines verwalteten Objekts im MIB-Baum. Jede Zahl im OID benennt einen Knoten, und der vollständige Punktpfad identifiziert genau einen Wert, den der Agent zurückgeben kann.

Nehmen wir beispielsweise die OID .1.3.6.1.2.1.1.1.0. 

Das bedeutet immer sysDescr, eine Textbeschreibung des Systems. Die OIDs, mit denen Sie am häufigsten arbeiten, beginnen meist entweder mit .1.3.6.1.2.1 für Standard-MIB-2-Objekte oder mit .1.3.6.1.4.1 für private Hersteller-OIDs.

Cisco ist der Enterprise-Zweig .1.3.6.1.4.1.9 zugewiesen, sodass jedes Cisco-spezifische Objekt unterhalb dieses Zweigs eingeordnet ist. Die IANA pflegt unter iana.org/assignments/enterprise-numbers das vollständige Register der Hersteller-Präfixe.

Skalare vs. tabellarische OIDs

OIDs lassen sich in zwei grundlegende Typen unterteilen:

1. Skalare OIDs liefern einen einzelnen Wert, weil es von dieser Sache nur eine gibt. sysDescr ist skalar, weil ein Gerät eine Beschreibung hat. 
2. Tabellarische OIDs liefern Werte aus einer Tabelle, in der jede OID eine Spalte darstellt und der Index die Zeile identifiziert. 

Interfaces sind tabellarisch. Ein Router hat viele Interfaces, jedes mit eigener Beschreibung, eigenem Octet-Counter und eigener Fehlerzahl. Tabellarische OIDs enden mit einem Index, der die Zeile identifiziert, etwa .1.3.6.1.2.1.2.2.1.10.3 für den In-Octets-Counter auf Interface-Index 3.

Ein einfaches Beispiel mit snmpwalk:

$ snmpwalk -v2c -c Secret 127.0.0.1 .1.3.6.1.2.1.1.1.0

SNMPv2-MIB::sysDescr.0 = STRING: Linux demo1.logicmonitor.net 2.6.32-358.6.2.el6 x86_64

Führen Sie dieselbe Abfrage gegen einen Cisco Switch aus, erhalten Sie stattdessen den IOS-Versionsstring statt des Linux-Kernel-Strings. Gleiche OID, anderer Agent, passende Antwort.

So funktioniert SNMP: Der gesamte Ablauf

SNMP funktioniert im Wesentlichen in vier Schritten: 

1. Der Manager sendet eine Anfrage
2. Der Agent liest seine MIB
3. Der Agent sendet den angeforderten Wert zurück
4. Der Agent sendet einen unaufgeforderten Trap, wenn sich etwas ändert (optional)

Die Kommunikation erfolgt hauptsächlich über UDP.

Schritt für Schritt

1. Anfrage: Der Manager sendet ein GET, GETNEXT oder GETBULK an den Agent über UDP-Port 161, benennt die gewünschte OID und übermittelt einen Community String (v1/v2c) oder Benutzeranmeldedaten (v3).

2. Abfrage: Der Agent prüft die Anmeldedaten, schlägt dann die OID in den von ihm implementierten MIB-Objekten nach und ruft den zugehörigen Wert vom Gerät ab.

3. Antwort: Der Agent schickt ein RESPONSE-Paket mit dem Wert zurück, von UDP-Port 161 an den Manager. Gauges (etwa die Temperatur) kommen unverändert zurück. Counter (etwa eingehende Octets) kommen als rohe Gesamtsummen zurück, und der Manager errechnet aus zwei Samples eine Rate.

4. Trap (optional): Haben Sie den Agent entsprechend konfiguriert, löst eine Schwellenwertüberschreitung oder Zustandsänderung einen TRAP oder INFORM aus. Der Agent sendet ihn über UDP 162 an den Manager, ohne auf ein Polling zu warten.

Eine Monitoring-Plattform wiederholt die ersten drei Schritte typischerweise in regelmäßigen Intervallen, speichert die Werte, berechnet daraus beispielsweise Raten und Verhältnisse und löst Alerts aus, wenn definierte Schwellenwerte überschritten werden. 

Die meisten Plattformen nutzen Traps als sekundäres Signal, nicht als primäres. Die Gründe dafür behandeln wir weiter unten.

SNMP-Befehle und PDU-Typen

SNMP definiert sieben Nachrichtentypen, die PDUs genannt werden. Fünf kommen vom Manager, um Daten abzurufen oder zu ändern, und zwei kommen vom Agent, um Ereignisse zu melden. 

Jeder SNMP-Austausch verwendet einen davon.

SNMP-Ports und -Protokolle

SNMP verwendet zwei UDP-Ports: 161 für Polling und 162 für Traps. 

SNMP läuft typischerweise über UDP (Ports 161 und 162), kann aber auch über TCP arbeiten (was selten vorkommt) oder in manchen Implementierungen über TLS/DTLS. Der jeweils passende SNMP Port hängt also vom eingesetzten Transport ab.

Firewall- und ACL-Konfiguration

Wenn das SNMP-Polling nicht mehr funktioniert, prüfen wir zuerst die Firewall. SNMP läuft über UDP, und unbemerkte Paketverluste können genauso aussehen wie ein ausgefallenes Gerät oder ein defekter Agent. Eine fehlerhafte Firewall-Regel lässt sich meist schnell als Ursache ausschließen, bevor weitere Komponenten untersucht werden. 

Die Quell-IP des Managers muss UDP-Port 161 auf dem Gerät erreichen können, da der SNMP-Agent dort standardmäßig Abfragen entgegennimmt. Für Traps gilt die umgekehrte Richtung: Das Gerät muss UDP-Port 162 auf dem Manager erreichen können, da in diesem Fall der Agent die Kommunikation initiiert.

Eine kurze Checkliste für Firewall-Probleme:

• Erlauben Sie eingehenden Traffic auf UDP-Port 161 am Gerät für die IP-Adresse beziehungsweise das Subnetz des Managers.
• Erlauben Sie UDP 162 eingehend auf dem Manager von jedem Gerät, das Traps sendet. Diese Liste ist meist deutlich größer als die Polling-ACL.
• Denken Sie daran, dass UDP verbindungslos ist. Ein Antwortpaket muss einer Firewall-Regel eigenständig entsprechen, besonders bei zustandslosen Firewalls, da das State-Tracking für UDP schwächer ausfällt als für TCP.
• Für SNMP over TLS/DTLS werden standardmäßig die Ports 10161 für Abfragen und 10162 für Benachrichtigungen verwendet. Das verwendete Transportprotokoll hängt davon ab, ob TLS oder DTLS eingesetzt wird.

SNMP-Versionen: v1, v2c und v3

In Produktivumgebungen sind drei SNMP-Versionen verbreitet. Wir empfehlen SNMPv3, sofern das Gerät diese Version unterstützt. SNMPv2c kann als Alternative in entsprechend geschützten internen Netzwerken eingesetzt werden. SNMPv1 sollte nur bei Legacy-Geräten zum Einsatz kommen, die keine neuere Version unterstützen.

Hier ein Überblick über die drei SNMP-Versionen: 

SNMPv1: Die ursprüngliche Version 

Sie ist einfach zu konfigurieren, da sie als einzige Anmeldeinformation einen Community String im Klartext nutzt. Die entscheidende Grenze sind die 32-Bit-Counter. Ein 1-Gbps-Interface kann einen 32-Bit-Octet-Counter in 34 Sekunden überlaufen lassen. Bei Ein-Minuten-Abfragen lässt sich deshalb nicht mehr sagen, ob 10 Octets durchliefen oder 4.294.967.306. 

Wenn Sie noch SNMPv1 einsetzen, sollten Sie nach Möglichkeit die Migration auf eine neuere Version einplanen.

SNMPv2c

v2c ist v1 mit 64-Bit-Countern und einigen neuen Nachrichtentypen wie GETBULK. Die Absicherung ist weiterhin ein Community String im Klartext. SNMPv2c sollte daher nur in entsprechend geschützten und vertrauenswürdigen Netzwerksegmenten eingesetzt werden. 

Die meiste Hardware unterstützt v2c, oft standardmäßig aktiviert. Bei einigen älteren Geräten muss es explizit eingeschaltet werden. Aktivieren Sie es nur, wenn v3 nicht verfügbar ist.

SNMPv3

SNMP v3 ergänzt den Funktionsumfang von v2c um echte Sicherheit. Es unterstützt Authentifizierung (meist SHA), Verschlüsselung (meist AES) oder beides. 

Die Einrichtung ist aufwendiger. Statt eines einzelnen Community Strings konfigurieren Sie Benutzer, Authentifizierungsprotokolle, Verschlüsselungsschlüssel und Views. Der Aufwand lohnt sich in jedem Netz, in dem jemand ohne Vertrauensstellung den Traffic mitschneiden oder Pakete fälschen könnte.

Welche SNMP-Version Sie verwenden sollten

Wir empfehlen SNMPv3 mit aktivierter Authentifizierung und Verschlüsselung als Standard. Setzen Sie v2c nur innerhalb eines vollständig vertrauenswürdigen Netzsegments ein, in dem ACLs beschränken, welche Hosts abfragen dürfen. Setzen Sie v1 nur ein, wenn ein Gerät keine neuere SNMP-Version unterstützt, und tauschen Sie dieses Gerät aus, sobald es geht.

Polling vs. Traps: Wann eignet sich welcher Ansatz?

Polling bedeutet, dass der Manager nach Zeitplan Fragen stellt. Traps bedeuten, dass der Agent von sich aus Informationen liefert, wenn etwas passiert. 

Wir empfehlen, Polling als primäre Datenquelle zu behandeln und einen SNMP Trap als sekundäres Signal, nicht umgekehrt.

Warum Traps allein riskant sind

Ein Trap ist ein einzelnes UDP-Paket, das das Gerät genau in dem Moment sendet, in dem etwas schiefläuft. Gerade während einer Störung steigt jedoch das Risiko, dass dieses Paket verloren geht. 

Angenommen, ein Netzteil ist gerade umgeschaltet, und ein Uplink instabil ist. Geht dieses Paket verloren, erhalten Sie keine Benachrichtigung, und Sie erfahren nie, dass eine Benachrichtigung hätte kommen sollen. 

Polling fängt das ab. Ein fehlgeschlagener Poll ist selbst erkennbar. Ihr Manager alarmiert Sie also, dass ein Gerät nicht mehr antwortet.

Warum Traps trotzdem nützlich sind

Für Ereignisse, die zwischen den Polls passieren und schnell relevant sind, liefern Traps eine nahezu echtzeitnahe Benachrichtigung. Beispiele sind ein Port, der administrativ heruntergefahren wird, ein BGP-Nachbar, der zurückgesetzt wird, oder ein redundantes Netzteil, das umschaltet. 

Nutzen Sie sie als Frühwarnung zusätzlich zum Polling, nicht anstelle davon. Aktivieren Sie INFORM-Nachrichten dort, wo Ihre Geräte sie unterstützen, denn INFORM verlangt eine Bestätigung und einen erneuten Versand.

Was Polling bietet, das Traps nicht liefern

Polling liefert Kontext über den zeitlichen Verlauf. 

Ein Trap kann Ihnen melden, dass die CPU 80 % überschritten hat, sofern auf dem Gerät schwellenwertbasierte Alerts konfiguriert sind. Polling sagt Ihnen aber, ob die CPU seit einer Woche steigt oder in den letzten fünf Minuten hochgeschossen ist. 

Dieser Unterschied entscheidet, ob sofortiges Handeln erforderlich ist oder das Problem bis zum nächsten Morgen warten kann. Dieses Muster sehen wir ständig in Kundenumgebungen. Dieselbe Schwellenwertüberschreitung bedeutet je nach Trendlinie dahinter zwei völlig verschiedene Dinge.

SNMP-Sicherheitsrisiken und Best Practices

SNMP ist eine häufige Angriffsfläche, weil es Ende der 1980er-Jahre entworfen wurde, als man die meisten Netze als vertrauenswürdig voraussetzte. 

Drei Risiken sind besonders relevant: 

1. v1 und v2c übertragen Anmeldedaten im Klartext. Wer ein einziges Paket zwischen Manager und Gerät mitschneidet, kann den Community String lesen und wiederverwenden. 
2. Standard-Community-Strings ("public" und "private") sind auf Millionen Geräten noch aktiv, weil Hersteller sie aktiviert ausliefern und Admins vergessen, sie zu ändern. Angreifer benötigen in diesem Fall unter Umständen nicht einmal eigene Zugangsdaten, da die Standardwerte bereits bekannt sind. 
3. Angreifer missbrauchen offene SNMP-Responder, um DDoS-Traffic zu verstärken. Eine kleine GETBULK-Abfrage kann eine bis zu 100-mal größere Antwort auslösen. Dadurch können Geräte als Verstärker für DDoS-Angriffe auf andere Ziele missbraucht werden. 

SNMP sollte deshalb in jeder Umgebung gezielt abgesichert werden.

Checkliste zur Absicherung

Wenden Sie diese Best Practices auf jedes Gerät an, das SNMP spricht:

• Ändern oder entfernen Sie standardmäßige Community Strings wie public und private.
• Verwenden Sie SNMPv3 mit authPriv, also Authentifizierung und Verschlüsselung, sofern das Gerät dies unterstützt.
• Beschränken Sie SNMP über ACLs auf die IP-Adressen autorisierter Manager.
• Trennen Sie Management-Traffic über ein dediziertes VLAN oder eine Management-VRF vom normalen Nutzer-Traffic.
• Deaktivieren Sie SNMP vollständig auf Geräten, die nicht überwacht werden müssen.
• Deaktivieren Sie SET, sofern Sie die Funktion nicht ausdrücklich benötigen.
• Blockieren Sie UDP 161 und 162 am Netzwerk-Perimeter. SNMP sollte nicht direkt über das öffentliche Internet erreichbar sein.
• Rotieren Sie SNMPv3-Zugangsdaten nach denselben Richtlinien wie andere privilegierte Zugangsdaten.
• Prüfen und beschränken Sie die verfügbaren MIB Views, sodass der Agent nur die Informationen bereitstellt, die das Monitoring-System tatsächlich benötigt.

Was „SNMP-Support" wirklich bedeutet

„SNMP-Support" bedeutet, dass ein Gerät SNMP-Abfragen beantworten kann, aber nicht, welche Abfragen oder wie viele nützliche Daten zurückkommen. Der Umfang reicht von einem Versionsstring bis zu Tausenden herstellerspezifischen Metriken. Die Angabe ‚SNMP-Support‘ allein sagt daher wenig darüber aus, wie umfassend sich ein Gerät tatsächlich überwachen lässt.

Standard-MIBs decken Interface-Auslastung, Pakete pro Sekunde, CPU, Speicher und TCP-Statistiken ab. 

Das reicht oft für ein einfaches Monitoring eines Routers oder Switches. Für eine USV reicht es nicht (dort brauchen Sie Batterielaufzeit, Zeit im Batteriebetrieb und Zustand des Batteriepacks) und ebenso wenig für ein Storage-Array (dort brauchen Sie Laufwerksgesundheit, freie Kapazität und Latenz pro LUN). Diese Metriken existieren nur in herstellerspezifischen MIBs.

Auch eine verfügbare Hersteller-MIB löst dieses Problem nicht automatisch. 

Die MIB von APC umfasst über 4.500 Objekte, und viele davon sind für den täglichen Betrieb kaum relevant. Eines meldet etwa „die physische Adresse des Gleichrichters auf dem Bus". Nicht jedes APC-Gerät implementiert jedes Objekt, da Geräte nur Teilmengen der vollständigen MIB unterstützen. 

Die tatsächlich relevanten Metriken können über verschiedene Bereiche des MIB-Baums verteilt sein. Sie zu finden, erfordert entweder sorgfältiges Lesen der Herstellerdokumentation oder ein Monitoring-Tool, das bereits weiß, welche OIDs für welches Modell wichtig sind.

Was „SNMP-Support" in einem Monitoring-System bedeutet

Ein Monitoring-System, das SNMP spricht, ist nicht automatisch gut darin, SNMP-Geräte zu überwachen. Der eigentliche Test ist, wie viel OID-Arbeit das System Ihnen abnimmt. 

Dabei sind drei Funktionen besonders entscheidend:

1. Automatische Erkennung: Ein gutes System identifiziert das Gerät, wählt die richtigen OIDs für dieses Modell und prüft erneut, wenn sich die Konfiguration ändert. Schalten Sie PoE ein, wird die PoE-MIB abfragbar, ohne dass jemand eine Konfiguration bearbeiten muss.
2. Korrekte Datenauswertung: SNMP liefert Gauges, Counter, Strings und Bitmaps. Counter müssen in Raten umgerechnet werden, indem Samples differenziert und durch das Intervall geteilt werden, und 64-Bit-Counter laufen weit seltener über als 32-Bit-Counter. Das System sollte all das unsichtbar erledigen.
3. Sinnvolle Standard-Schwellenwerte für Alerts: Vordefinierte Alerts für das, was die Produktion tatsächlich beeinträchtigt (Interface-Fehler, CPU-Sättigung, volllaufende Festplatten, USV im Batteriebetrieb), sollten bereits existieren. Zudem sollten eigene Schwellenwerte eine kleine Anpassung sein, nicht eine Woche Arbeit bedeuten.

Über diese drei hinaus zählen zu den nützlichen Extras Graphing, flexibles Alert-Routing, automatische Geräteerkennung, Topologie-Karten für Layer 2 und Layer 3 sowie Unterstützung für weitere Protokolle (WMI, JMX, Hersteller-APIs) dort, wo SNMP an Grenzen stößt. 

Ein System, das SNMP mit diesen anderen Quellen zusammenführt, ist weit nützlicher als eines, das nur SNMP spricht. Auf diesem Prinzip haben wir unsere eigene Plattform aufgebaut.

SNMP unter Linux installieren

Um SNMP unter Linux zu installieren, führen Sie die folgenden vier Schritte aus: 

1. Das Paket installieren
2. Den Agent konfigurieren
3. Den Dienst starten
4. Prüfen, ob er antwortet 

Unter Red Hat oder CentOS dauert der ganze Vorgang etwa eine Minute auf einem einzelnen Host. Andere Distributionen nutzen dasselbe net-snmp-Paket mit anderen Paketmanager-Befehlen.

Schritt 1: Das net-snmp-Paket installieren

Installieren Sie den Agent und die Kommandozeilen-Werkzeuge mit Ihrem Paketmanager. Das Utilities-Paket liefert Ihnen snmpwalk, snmpget und weitere Tools, die Sie zum Testen brauchen.

yum install net-snmp net-snmp-utils

Unter Debian oder Ubuntu lautet die Entsprechung apt install snmpd snmp. Auf neueren Red-Hat-Systemen verwenden Sie dnf statt yum.

Schritt 2: Den Agent konfigurieren

Der Agent liest seine Konfiguration aus /etc/snmp/snmpd.conf. Für einen Host hinter einer Firewall, der nicht direkt aus dem Internet erreichbar ist, ist die einfachste funktionierende Konfiguration eine einzige Zeile:

rocommunity MyCommunity

Damit kann jedes Gerät, das den Community String MyCommunity kennt, von jeder IP aus Nur-Lese-Abfragen ausführen, sofern keine Zugriffssteuerungen ergänzt werden. Schreiboperationen (SET) bleiben deaktiviert, was für die meisten Produktivumgebungen sinnvoll ist.

Ersetzen Sie MyCommunity durch einen nicht leicht zu erratenden Wert und verwenden Sie keine Standardwerte wie public oder private. Nach "public" und "private" wird ständig gescannt, verwenden Sie sie daher nie.

Für striktere Setups unterstützt snmpd.conf auch, einzuschränken, welche IPs den Agent abfragen dürfen, SNMPv3-Authentifizierung und -Verschlüsselung zu aktivieren und einzugrenzen, für welche OIDs der Agent antwortet. 

Schritt 3: Den Dienst starten und beim Systemstart aktivieren

Starten Sie den Agent jetzt und weisen Sie das System an, ihn bei jedem Systemstart zu starten:

chkconfig snmpd on

service snmpd restart

Auf Systemen mit systemd (die meisten modernen Linux-Distributionen) lautet die Entsprechung:

systemctl enable snmpd

systemctl restart snmpd

Schritt 4: Prüfen, ob der Agent antwortet

Testen Sie den Agent vom selben Host aus, bevor Sie mögliche Netzwerkprobleme untersuchen. Eine erfolgreiche lokale Abfrage bedeutet, dass der Agent läuft und die Konfiguration für den lokalen Zugriff gültig ist:

snmpwalk -v2c -c MyCommunity 127.0.0.1 .1.3.6.1.2.1.1.1.0

Sie sollten eine Zeile zurückbekommen, die mit SNMPv2-MIB::sysDescr.0 = STRING: beginnt, gefolgt von Ihrer Systembeschreibung. Erhalten Sie eine entsprechende Antwort, funktioniert der Agent. Erhalten Sie es nicht, springen Sie zur Troubleshooting-Checkliste im nächsten Abschnitt.

Wenn Abfragen fehlschlagen:

Arbeiten Sie diese Punkte der Reihe nach ab:

• Lokale Firewall: iptables, firewalld oder nftables muss UDP 161 eingehend erlauben. Prüfen Sie das mit iptables -L -n oder dem entsprechenden Befehl.
• Netzwerk-Firewalls: Alles zwischen Manager und Server muss ebenfalls UDP 161 erlauben.
• Kommen die Pakete überhaupt an: Führen Sie tcpdump -i any port 161 auf dem Server aus und fragen Sie vom Manager ab. Erscheint nichts, ist es ein Netzwerkproblem.
• hosts.allow / hosts.deny: Manche net-snmp-Builds nutzen tcpwrappers. Fügen Sie snmpd: ALL zu /etc/hosts.allow hinzu, um zu testen.
• Community-String: Stellen Sie sicher, dass der Manager exakt den String aus der Agent-Konfiguration verwendet.

SNMP-Troubleshooting: eine strukturierte Checkliste

Wenn SNMP versagt, liegt das Problem fast immer an einer von vier Stellen: dem Port, den Anmeldedaten, dem Agent oder der ACL. 

Prüfen Sie sie in dieser Reihenfolge. Überspringen Sie nichts.

1. Ist der Port erreichbar?

• Führen Sie vom Manager aus nmap -sU -p 161 aus. Ein Ergebnis "open" oder "open|filtered" bedeutet, dass der Port erreichbar ist, aber nicht endgültig bestätigt.
• Ist er geschlossen, prüfen Sie Firewalls zwischen Manager und Gerät sowie jede ACL auf dem Gerät selbst.

2. Sind die Anmeldedaten korrekt?

• Prüfen Sie bei v1/v2c den Community String Zeichen für Zeichen. Nachgestellte Leerzeichen und Groß-/Kleinschreibung sind wichtig. 
• Prüfen Sie bei v3 Benutzername, Auth-Protokoll (MD5 oder SHA), Auth-Schlüssel, Privacy-Protokoll (DES oder AES) und Privacy-Schlüssel. Ein einziges falsches Feld lässt den gesamten Austausch scheitern.

3. Läuft der Agent und antwortet er?

• Führen Sie unter Linux systemctl status snmpd oder service snmpd status aus.
• Führen Sie unter Cisco IOS show snmp aus, um Paketzähler zu sehen. Steigende "input queue drops" deuten auf eine Überlastung des Agents hin.
• Führen Sie tcpdump -i any -n port 161 auf dem Gerät aus. Kommen Anfragen an und geht keine Antwort raus, liegt das Problem wahrscheinlich an der Agent-Konfiguration, den Anmeldedaten oder den Zugriffssteuerungen.

4. Erlaubt die ACL diesen Manager?

• Cisco: Prüfen Sie die ACL, auf die snmp-server community oder snmp-server group verweist.
• Linux net-snmp: Die "rocommunity" -Direktive akzeptiert eine Quellbeschränkung, zum Beispiel rocommunity MyCommunity 10.0.0.0/24.

SNMP Monitoring im großen Maßstab betreiben

So skalieren Sie SNMP:

• Poll-Intervalle an die Metrik anpassen: 60 Sekunden ist der übliche Standard. Setzen Sie Interface-Counter auf 30 Sekunden herunter, wo die Gerätekapazität es zulässt, denn kurze Spitzen sind wichtig. Für langsam veränderliche Werte wie die Storage-Kapazität können längere Intervalle von beispielsweise 300 Sekunden sinnvoll sein. Kürzere Intervalle belasten Gerät und Collector stärker, wählen Sie daher keine kürzeren Polling-Intervalle als erforderlich.
• Collector nahe an den überwachten Geräten platzieren: Polling über eine WAN-Verbindung kostet bei jedem Austausch Latenz und macht die Trap-Zustellung fragiler.
• Abfragen mit GETBULK bündeln: Nutzen Sie GETBULK (ab v2c) mit einem sinnvollen Repetition-Wert, meist 10 bis 20, um die Anzahl der Anfragen um eine Größenordnung zu senken.
• Anmeldedaten über Konfigurationsmanagement rotieren: Tools wie Ansible, Chef, Puppet oder Salt lassen Sie Community-Strings oder SNMPv3-Schlüssel über die gesamte Flotte ausrollen, ohne sich einzeln an den Geräten anzumelden.
• Polling zeitlich verteilen: Verteilen Sie Abfragen gleichmäßig, statt alle Abfragen gleichzeitig zu Beginn eines Polling-Intervalls zu starten. Eine geballte Welle gleichzeitiger SNMP-Abfragen verursacht Paketverluste und CPU-Spitzen auf kleineren oder ressourcenbeschränkten Geräten.

SNMP-Anwendungsfälle

SNMP taucht in den meisten IT-Umgebungen in fünf Aufgaben auf: Performance-Monitoring, Fehler-Alerting, Kapazitätsplanung, Troubleshooting und Compliance-Nachweise. 

Jede nutzt dieselben zugrundeliegenden Daten, aber die Art, wie die Daten verwendet werden, unterscheidet sich.

• Performance-Monitoring: Sammeln Sie CPU-, Speicher-, Interface-Traffic- und Latenz-Metriken in regelmäßigen Abständen und stellen Sie sie grafisch und als Trend dar.
• Fehler-Alerting: Lösen Sie Alerts aus, wenn ein Schwellenwert überschritten wird, ein Prozess abstürzt, ein Netzteil ausfällt oder ein Interface flappt.
• Kapazitätsplanung: Nutzen Sie Wochen und Monate an SNMP-Daten, um vorherzusagen, wann Uplinks, CPU oder Storage ausgehen.
• Troubleshooting: Durchlaufen Sie ein Gerät während eines Incidents, um Live-Counter zu inspizieren (Interface-Fehler, Größe der Routing-Tabelle, Speicherpools), ohne eine CLI-Sitzung zu öffnen.
• Compliance: Historische SNMP-Daten beantworten Auditor-Fragen zu Uptime, Wartungsfenstern und Ressourcennutzung, für die es sonst keine Aufzeichnung gäbe.

Grenzen von SNMP

Die Schwächen von SNMP fallen in drei Kategorien: Sicherheitslücken, Skalierungskosten und Abdeckungslücken. Zu wissen, zu welcher Kategorie ein Problem gehört, sagt Ihnen, ob Sie es beheben, umgehen oder SNMP mit etwas anderem kombinieren sollten.

Sicherheitslücken

Zwei Einschränkungen liegen auf Protokollebene und wirken sich auf die Integrität der erfassten Daten aus:

• Schwache Standardsicherheit: v1 und v2c haben keine Verschlüsselung und authentifizieren mit einem geteilten String im Klartext. v3 behebt das, braucht aber eine sorgfältigere Einrichtung.
• UDP-Verlust: SNMP läuft über UDP. Polls und Traps können unter Überlast stillschweigend verschwinden, was Ihnen eine falsche Sicherheit über die Abdeckung gibt.

Skalierungskosten

Bei der Skalierung von SNMP auf Tausende von Geräten zeigen sich vor allem zwei Einschränkungen:

• Polling-Overhead: Zehntausende kleiner UDP-Abfragen pro Minute summieren sich. Auf beschränkten Geräten (einfachen Switches, IoT-Hardware) kann SNMP selbst eine spürbare CPU-Last verursachen.
• Eigenheiten der Tabellen-Indizierung: Interface-Indizes können sich auf manchen Geräten nach einem Neustart ändern. Ein Monitoring-System, das Indizes cached, kann nach einer Änderung die falschen Tabelleneinträge abfragen, bis die Interfaces erneut erkannt und zugeordnet wurden.

Abdeckungslücken

Drei weitere Einschränkungen betreffen Bereiche, die SNMP nicht abdecken kann, sei es aufgrund herstellerspezifischer Unterschiede oder weil moderne IT-Umgebungen inzwischen andere Anforderungen stellen:

• Uneinheitliche Hersteller-Implementierungen: Zwei Geräte verschiedener Hersteller derselben Kategorie stellen selten dieselben Metriken bereit. Der Umfang der bereitgestellten Metriken kann je nach Hersteller erheblich variieren.
• OID-Inkonsistenz: Hersteller-MIBs nutzen für dieselben Daten unterschiedliche Strukturen. Monitoring-Templates lassen sich daher häufig nicht ohne Anpassungen auf Geräte anderer Hersteller übertragen.
• Begrenzte Sicht auf moderne Infrastruktur: Container, Serverless-Funktionen und Cloud-Dienste stellen SNMP kaum bereit. Moderne Stacks kombinieren SNMP mit Streaming-Telemetrie (gNMI, OpenTelemetry), Hersteller-APIs und der Aufnahme von Logs über professionelles Log-Management.

SNMP-Herausforderungen bei Herstellern und MIBs

Hier die Herausforderungen, die uns am häufigsten begegnen, grob geordnet danach, wie viel Schaden jede anrichtet:

• Nur nomineller Support: Manche Geräte implementieren die Standard-MIBs, geben aber Nullen oder statische Werte zurück. Der Agent antwortet, doch die Daten sind nicht echt. Dieses Problem ist besonders schwer zu erkennen, da der Agent weiterhin ordnungsgemäß zu antworten scheint.
• OIDs, die sich zwischen Firmware-Versionen ändern: Ein Hersteller kann eine OID in einem Minor-Release abkündigen. Monitoring, das gegen die alte OID gebaut wurde, liefert nach einem Upgrade stillschweigend keine Daten mehr. Dadurch können nach einem Firmware-Upgrade unerwartet Datenlücken in bestehenden Dashboards entstehen.
• Nicht veröffentlichte MIB-Dateien: Manche Hersteller verstecken MIB-Dateien hinter Support-Portalen. Ohne die entsprechende MIB-Dokumentation lassen sich zurückgegebene OIDs nur schwer zuverlässig interpretieren. Werte kommen zurück, aber nichts sagt Ihnen, was sie bedeuten.
• Fehlender Kontext: Eine OID zur CPU-Auslastung meldet je nach Hersteller womöglich etwas anderes (Ein-Minuten-Durchschnitt, Fünf-Minuten-Durchschnitt, Momentanwert), ohne zu kennzeichnen, was gemeint ist. Schwellenwerte, die gegen einen Hersteller gesetzt sind, können für einen anderen falsch sein.
• Metriken in unterschiedlichen Bereichen: Bei den meisten Geräten sind Interface-Fehlerraten in der standardisierten IF-MIB enthalten, bei anderen jedoch in herstellerspezifischen MIB-Bereichen. Um sie zuverlässig zu erfassen, ist daher eine gerätespezifische Discovery-Logik erforderlich.
• Index-Instabilität: ifIndex-Werte können bei einem Neustart neu vergeben werden. Manche Hersteller bieten ifAlias oder eine MIB mit persistenten Indizes als Umgehung an, aber nicht alle.

Um diese Herausforderungen zu vermeiden, validieren Sie, was SNMP auf jeder Geräteklasse in Ihrer Umgebung tatsächlich zurückgibt, bevor Sie sich auf die Daten verlassen. 

Prüfen Sie Counter-Werte stichprobenartig gegen andere Quellen (CLI-Ausgabe, NetFlow, Anwendungsmetriken) auf mindestens einem Gerät pro Modell.

Von SNMP-Support zu echter Transparenz

SNMP ist weiterhin die universelle Basis für das Monitoring von Infrastruktur. Nahezu jede Netzwerkhardware und jedes Server-Betriebssystem kann es nutzen. Für das Monitoring von Routern, Switches, Firewalls, USV-Einheiten und klassischen Servern spielt SNMP daher weiterhin eine zentrale Rolle.

Protokoll-Support ist aber nur der Ausgangspunkt. Die eigentliche Arbeit besteht darin, herauszufinden, welche OIDs wichtig sind, sie geräteübergreifend konsistent zu sammeln und diese Daten in Alerts und Trends zu verwandeln, denen Ihr Team vertrauen kann. Genau das macht gutes SNMP Monitoring aus.

LogicMonitor ist darauf ausgelegt, diese Arbeit zu reduzieren. Es hilft Ihnen, SNMP-fähige Infrastruktur mit weniger manueller Konfiguration, besserer Geräteabdeckung und einem klareren Weg von rohen Metriken zur Handlung zu überwachen. In einer hybriden Observability-Plattform fügt sich SNMP Monitoring so in ein größeres Bild ein.

FAQs