3
Fehler bei der SNMP-Trap-Verarbeitung von der Netzwerkschnittstelle zum Prozess
Hallo liebe Administratoren,
ich habe folgendes Problem:
An einen Sun-Server (5.10, sparc) werden SNMP-Traps auf den Port 162 geschickt. Auf dem Port 162 lauscht ein Prozess (Monitoring-Agent), welcher die Traps weiter verarbeitet.
Dies hat eine ganze Weile funktioniert und plötzlich bekommt der Agent, der auf dem Port lauscht keine Traps mehr.
Zunächst habe ich mit "snoop port 162" überprüft, ob die Traps überhaupt noch am Server ankommen. Die Traps konnte ich dort sehen.
Anschließend habe ich anhand der PID des Agenten überprüft, ob der Prozess noch am Port gebunden ist: pfiles 645 | grep -i port
Ausgabe: sockname: AF_INET 0.0.0.0 port: 162
Und auch das erscheint mir als richtig. Aber trotzdem bekommt der Agent die Traps nicht von der Netzwerkschnittstelle weitergeleitet.
Was kann das sein?
Ich bin für alle Ideen dankbar!
Schöne Grüße
frigge
ich habe folgendes Problem:
An einen Sun-Server (5.10, sparc) werden SNMP-Traps auf den Port 162 geschickt. Auf dem Port 162 lauscht ein Prozess (Monitoring-Agent), welcher die Traps weiter verarbeitet.
Dies hat eine ganze Weile funktioniert und plötzlich bekommt der Agent, der auf dem Port lauscht keine Traps mehr.
Zunächst habe ich mit "snoop port 162" überprüft, ob die Traps überhaupt noch am Server ankommen. Die Traps konnte ich dort sehen.
Anschließend habe ich anhand der PID des Agenten überprüft, ob der Prozess noch am Port gebunden ist: pfiles 645 | grep -i port
Ausgabe: sockname: AF_INET 0.0.0.0 port: 162
Und auch das erscheint mir als richtig. Aber trotzdem bekommt der Agent die Traps nicht von der Netzwerkschnittstelle weitergeleitet.
Was kann das sein?
Ich bin für alle Ideen dankbar!
Schöne Grüße
frigge
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 201265
Url: https://administrator.de/forum/fehler-bei-der-snmp-trap-verarbeitung-von-der-netzwerkschnittstelle-zum-prozess-201265.html
Ausgedruckt am: 23.04.2025 um 09:04 Uhr
3 Kommentare
Neuester Kommentar
Hi Frigge,
bei SNMP gibt es drei Varianten, die übereinstimmen müssen.
Aber selbst bei SNMP 1 und 2 wird immer ein (unverschlüsseltes) Passwort/Community-String mitgeschickt.
Auch wenn es nicht logisch ist, aber der SNMP Empfänger muss das Passwort kennen und akzeptieren. Sonst wird es nicht verarbeitet.
Auch eine unbekannte OID führt dazu, dass ein Trap nichts mehr auslöst. Das kann schon mal über ein SW-update in der private MIB des Absenders passieren.
Im Empfänger ist die ja quasi hart codiert, also fest eingetragen.
Gruß
Netman
bei SNMP gibt es drei Varianten, die übereinstimmen müssen.
Aber selbst bei SNMP 1 und 2 wird immer ein (unverschlüsseltes) Passwort/Community-String mitgeschickt.
Auch wenn es nicht logisch ist, aber der SNMP Empfänger muss das Passwort kennen und akzeptieren. Sonst wird es nicht verarbeitet.
Auch eine unbekannte OID führt dazu, dass ein Trap nichts mehr auslöst. Das kann schon mal über ein SW-update in der private MIB des Absenders passieren.
Im Empfänger ist die ja quasi hart codiert, also fest eingetragen.
Gruß
Netman
Hallo Netman,
Danke für die ANtwort
Wer ist denn hier der "SNMP-Empfänger", der das Passwort kennen muss? Der Server oder der Prozess? Und welche Stationen durchläuft so ein Trap im Server eigentlich? Ich kenne nur den Startpunkt (Netzwerkschnittstelle) und den Endpunkt (Der Prozess/Agent). Gibt es da noch Zwischenstationen? Muss da irgendwo Passwort/Community-String eingetragen werden?
An der OID wirds nicht liegen, da ich fürs debuggen auf alle OIDs (also *) filter.
Gruß
frigge
Danke für die ANtwort
Wer ist denn hier der "SNMP-Empfänger", der das Passwort kennen muss? Der Server oder der Prozess? Und welche Stationen durchläuft so ein Trap im Server eigentlich? Ich kenne nur den Startpunkt (Netzwerkschnittstelle) und den Endpunkt (Der Prozess/Agent). Gibt es da noch Zwischenstationen? Muss da irgendwo Passwort/Community-String eingetragen werden?
An der OID wirds nicht liegen, da ich fürs debuggen auf alle OIDs (also *) filter.
Gruß
frigge
der Empfängerprozess ist doch open-snmp?
Ansonsten wäre es der Prozeß, der die Info von der NIC weiterreicht.
Ansonsten sehen Traps aus wie normale UDP Pakete aber an Port 162.
...Absender IP Ziel IP ... Community OID Wert.
Via TCPdump oder Wireshark kann man es gut sehen.
Für Testzwecke kann man solche Pakete auch manuell absetzen.
Gruß
Netman
Ansonsten wäre es der Prozeß, der die Info von der NIC weiterreicht.
Ansonsten sehen Traps aus wie normale UDP Pakete aber an Port 162.
...Absender IP Ziel IP ... Community OID Wert.
Via TCPdump oder Wireshark kann man es gut sehen.
Für Testzwecke kann man solche Pakete auch manuell absetzen.
Gruß
Netman
