Die häufigste Ursache einer SNMP-Fehlkonfiguration ist eine Versions- oder Community-Diskrepanz zwischen Agent und Monitoring-Server. Prüfen Sie zuerst mit snmpwalk gegen die Ziel-IP, ob der Agent überhaupt antwortet, gleichen Sie dann Version, Community bzw. USM-Benutzer, ACLs und UDP-Port 161 ab. Danach passen Sie beide Seiten identisch an.
Symptome
- Monitoring-Tool meldet Timeout oder „No Response
- :obwohl das Gerät per Ping erreichbar ist
Häufige Ursachen
Versionsdiskrepanz zwischen Agent und Poller
Ein v3-Poller fragt einen v2c-Agent (oder umgekehrt). SNMP handelt Versionen nicht aus, ein Mismatch führt zu stummem Verwerfen der Anfrage ohne aussagekräftige Fehlermeldung.
Falscher Community-String oder USM-Benutzer
Groß-/Kleinschreibung, Leerzeichen oder rotierte Passwörter führen bei v1/v2c zu Silent-Drop. Bei v3 passen Auth- oder Priv-Passphrase nicht mehr zur konfigurierten Sicherheitsstufe.
ACL oder view-Beschränkung am Agent
Die Zeile access oder snmp-server community mit ACL erlaubt nur bestimmte Quell-IPs oder OID-Subtrees. Anfragen aus einem neuen Monitoring-Subnetz werden dadurch abgewiesen.
Firewall blockiert UDP 161/162
Zonen-Firewalls, Windows Defender Firewall oder iptables lassen den SNMP-Poll (UDP 161) oder Traps (UDP 162) nicht durch. Der Agent läuft, ist aber nicht erreichbar.
SNMP-Dienst nicht aktiv oder falsch gebunden
Der Dienst snmpd bzw. SNMP Service läuft nicht, ist an 127.0.0.1 gebunden oder lauscht auf einem abweichenden Port. Dadurch bleibt jede Abfrage vom Netz aus erfolglos.
Schritt-für-Schritt-Lösung
- Erreichbarkeit und Antwort des Agents mit snmpwalk prüfen
Testen Sie zuerst vom Monitoring-Host aus: snmpwalk -v2c -c <community> <ziel-ip> 1.3.6.1.2.1.1 fragt die System-MIB ab. Kommt sysDescr zurück, arbeitet der Agent grundsätzlich. Meldet der Befehl Timeout, liegt das Problem im Transport, in der Version oder im Community-String. - SNMP-Dienststatus auf dem Zielgerät verifizieren
Auf Linux zeigt systemctl status snmpd, ob der Dienst läuft und an welche Adresse er gebunden ist. Prüfen Sie ergänzend mit ss -ulnp | grep 161. Unter Windows liefert Get-Service SNMP den Status; bei Cisco IOS zeigt show snmp die Zähler eingehender Pakete. - Version, Community und v3-Benutzer beidseitig abgleichen
Öffnen Sie /etc/snmp/snmpd.conf bzw. die Gerätekonfiguration und notieren Sie exakt: SNMP-Version, Community-String oder v3-Benutzer inklusive authProtocol (SHA), privProtocol (AES) und Passphrasen. Vergleichen Sie diese Werte 1:1 mit den Zugangsdaten im Monitoring-Tool. Rotieren Sie bei Zweifel beide Seiten neu. - Zugriffskontrollen, Views und Source-IP-Filter kontrollieren
Bei Cisco prüfen Sie snmp-server community <string> RO <acl>; bei Net-SNMP die Zeilen com2sec, group, view und access. Stellen Sie sicher, dass die IP-Adresse des Pollers in der ACL steht und der view den benötigten OID-Subtree (mindestens .1.3.6.1.2.1) enthält. - Firewall- und Routing-Pfad für UDP 161 und 162 freigeben
Öffnen Sie UDP 161 eingehend am Agent (Polls) und UDP 162 am Trap-Empfänger. Unter Linux: iptables -A INPUT -p udp --dport 161 -s <poller>/32 -j ACCEPT. Unter Windows aktivieren Sie die Regel „SNMP-Dienst (UDP eingehend) - OIDs mit snmptranslate und snmpget gezielt validieren
Fehlen einzelne Werte, testen Sie die konkrete OID: snmpget -v2c -c <community> <ip> 1.3.6.1.2.1.2.2.1.10.1. Mit snmptranslate -On IF-MIB::ifInOctets.1 wandeln Sie Namen in numerische OIDs. So erkennen Sie, ob eine MIB im Monitoring-Tool fehlt oder der Agent den Subtree schlicht nicht implementiert. - SNMPv3 mit korrekter Sicherheitsstufe härten
Wechseln Sie produktiv auf v3 mit authPriv, SHA-Auth und AES-Priv. Legen Sie den Benutzer mit net-snmp-create-v3-user an, ordnen Sie ihn einer Gruppe und einem view zu. Prüfen Sie danach: snmpwalk -v3 -l authPriv -u <user> -a SHA -A <pw> -x AES -X <pw> <ip>. - Änderungen dokumentieren und Monitoring gegenprüfen
Halten Sie Version, Benutzer, ACL-Quellen und geöffnete Ports pro Gerät fest. Lösen Sie im Monitoring-Tool ein „Rediscover
Typische SNMP-Symptome, Ursachen und erste Gegenmaßnahme
| Symptom | Wahrscheinliche Ursache | Erste Maßnahme | |
|---|---|---|---|
| snmpwalk läuft in Timeout | Firewall blockiert UDP 161 oder Dienst gestoppt | Port am Agent und Zwischen-Firewalls prüfen, snmpd starten | |
| „Authentication failure | im Log | Community oder v3-Passphrase falsch | Zugangsdaten beidseitig neu setzen und Groß-/Kleinschreibung prüfen |
| Nur einige OIDs liefern Daten | view-Definition schränkt Subtree ein | view im Agent auf benötigte MIBs erweitern | |
| Werte springen unrealistisch | Counter-Wrap bei 32-Bit-Countern | Auf 64-Bit-Counter (ifXTable, HC-Varianten) umstellen | |
| Traps erreichen NMS nicht | UDP 162 blockiert oder falscher Empfänger | Trap-Ziel und Firewall-Regel für 162 prüfen | |
| Agent antwortet nur lokal | snmpd an 127.0.0.1 gebunden | agentAddress in snmpd.conf auf 0.0.0.0:161 setzen |
So beugen Sie vor
- SNMPv3 mit authPriv als Standard, v1/v2c nur in isolierten Management-VLANs
- Community-Strings und v3-Passphrasen regelmäßig rotieren und im Passwort-Tresor ablegen
- ACLs so eng wie möglich: nur Monitoring-Server-IPs, read-only-Views nutzen
- Konfigurationstemplates per Ansible oder RANCID ausrollen, um Drift zu vermeiden
Häufige Fragen
Warum antwortet SNMP lokal, aber nicht vom Monitoring-Server?
In den meisten Fällen ist der Agent an localhost gebunden oder eine ACL lässt nur bestimmte Quell-IPs zu. Prüfen Sie in /etc/snmp/snmpd.conf die Zeile agentAddress und stellen Sie sie auf udp:161 oder eine konkrete Management-IP. Kontrollieren Sie zusätzlich Host-Firewall und ACLs auf dem Gerät.
Soll ich SNMPv2c oder SNMPv3 einsetzen?
Für produktive Umgebungen ist SNMPv3 mit authPriv die richtige Wahl, weil Authentifizierung und Verschlüsselung integriert sind. SNMPv2c überträgt den Community-String im Klartext und eignet sich nur in strikt isolierten Management-Netzen. Bei bestehender v2c-Landschaft empfiehlt sich ein schrittweiser Umstieg pro Gerätegruppe.
Wie finde ich heraus, welche OID mein Monitoring-Tool abfragt?
Aktivieren Sie im Tool das Debug- oder Trace-Log für den betroffenen Sensor, dort erscheinen die konkreten OIDs. Alternativ zeichnen Sie den Verkehr mit tcpdump -i any -s0 -w snmp.pcap udp port 161 auf und öffnen die Datei in Wireshark. Der SNMP-Dissector zeigt Version, Community und angefragte OIDs im Klartext.
Lassen Sie Ihre SNMP- und Monitoring-Konfiguration von unserem Netzwerk-Team prüfen und sauber dokumentieren.