Via SNMP lässt sich die Funktion vieler Netzwerkgeräte bis in feinste Verästelungen überwachen. Voran geht aber oft eine Menge Friemelei.
Bei einem Kunden habe ich einen Grandstream GXW4248 an einer FreePBX-Telefonanlage im Einsatz. Das Gerät läuft leider nur mäßig stabil. Um schnell reagieren zu können, hatte ich das Gerät im PRTG Network Monitor zunächst via Ping überwacht, später habe ich zusätzlich geprüft, ob es auf HTTPS-Anfragen antwortet. Für bestimmte Fehler war aber auch das nicht aussagekräftig – etwa fehlgeschlagene Registrierungen an der Telefonanlage. Hier beschreibe ich exemplarisch, wie man den Registrierungsstatus eines Ports via SNMP überwachen kann.
SNMP ist ein extrem schlichtes Protokoll, das aber gleichzeitig eine hohe Affinität zu nerdiger Detektivarbeit erfordert. Die erste Frage lautet: Spricht der Grandstream SNMP? Das ist schnell mit “Ja” beantwortet und aktiviert:
SNMP besteht grob daraus, dass ich das Gerät frage: Wie ist der Wert von Parameter “.1.3.6.1.4.1.42397.1.1.2.2.1.0.0”? Und das Gerät antwortet dann etwa “1”. Woher weiß ich aber, dass ich nach “.1.3.6.1.4.1.42397.1.1.2.2.1.0.0” fragen muss? Dafür stellt der Hersteller im Idealfall eine MIB-Datei zur Verfügung, in der sich nachlesen lässt, welcher Parameter (in SNMP-Sprech: welche OID) wofür steht.
Woher bekommt man nun eine MIB-Datei? Auch damit kann man gelegentlich Stunden zubringen, weil Hersteller unerklärlicherweise zwar SNMP implementieren, dann aber nicht preisgeben, wofür die OIDs stehen. Das sieht dann schlimmstenfalls so aus:
Man erfährt also “Parameter X hat den Status 1”, weiß aber nicht, wofür das steht. Grandstream hat das zum Glück vorblidlich gelöst und bietet den Download der MIB-Datei im Gerät selbst an:
Um diese Datei auszuwerten, hilft unter Windows der iReasoning MIB Browser. Nach der Installation gehe ich dort auf File>Load MIBs und öffne die heruntergeladene Datei.
Um mich mit dem Grandstream-Adapter zu verbinden, gebe ich dessen IP unter “Address:” ein, schalte rechts daneben unter “Advanced…” auf SNMP-Version 2 um und trage die übliche “Read Community: public” ein.
Im MIB Tree finde ich nun einige Parameter und kann als erste Fingerübung mal die “System Up Time” abfragen:
Da kommt ein plausibler Wert zurück – die Kommunikation steht also.
Im private-Abschnitt finde ich erste interessante OIDs, etwa die Version der laufenden Firmware. Da der Grandstream in der Lage ist, die Firmware regelmäßig auf Aktualität zu prüfen und automatisch zu aktualisieren, könnte man sich einen Sensor wünschen, der beim Abweichen von einer bestimmten Firmwareversion Alarm schlägt. Denn eine Mailbenachrichtigung vor oder nach dem Update gibt es nicht. Ein Doppelklick auf versionCore schlägt aber leider fehl und liefert nur ein “No Such Instance” zurück. Hat man mir zuviel versprochen?
Die Lösung besteht darin, dass die OID von versionCore .1.3.6.1.4.1.42397.1.1.3.2 lautet, ich aber nach der darunterliegenden .1.3.6.1.4.1.42397.1.1.3.2.0.0 fragen muss. Das finde ich heraus, indem ich im Kontextmenü von versionCore “Get Next” wähle – so sucht der MIB Browser nach der nächsten gültigen OID:
Im MIB Tree finde ich auch einen Abschnitt temperatureSensors, der lohnend für eine Überwachung sein könnte. Anscheinend sind bis zu sechs Temperatursensoren vorgesehen:
Diese kann ich bequem gesammelt via “Get Subtree” abfragen:
Auch diese Werte wollen wieder interpretiert werden. Im Feld “Description” finde ich zwar den Hinweis “Temperature sensor for SVIP chip 0”, weiß aber nicht, ob es sich um Grad Celsius handelt (was bei Sensor 1 und 3 unplausibel scheint) oder um Fahrenheit (was wiederum bei Sensor 2 unplausibel ist – 51°F (10°C) herrschen sicher nicht im Gerät). Hier hilft nur beobachten, um sinnvolle Warnschwellen zu setzen – etwa direkt nach dem Einschalten des Geräts.
Aber zurück zur eigentlichen Frage. Eine OID, die meine Frage nach dem Registrierungsstatus beantwortet, finde ich im Baum auf Anhieb nicht, daher öffne ich die MIB-Datei zunächst in einem Editor und lese mich ein wenig rein. Die Datei hat fast 5000 Zeilen, aber ich finde schnell ein Objekt hookStatus1 – das beantwortet offensichtlich die Frage “Ist an Port 1 der Hörer aufgelegt oder abgenommen?”. Die Spur ist gut, und etwas weiter unten finde ich “regStatus1”. Bingo!
Damit kann ich in den MIB Browser zurückkehren und via “Edit>Find in MIB Tree” nach diesem Objekt suchen:
Ein Doppelklick auf regStatus1 liefert wieder ein “No Such Instance”, von dem man sich nicht entmutigen lassen darf. “Get Next” führt erneut zum Erfolg, und eine Abfrage von regStatus2 zeigt, dass die drittletzte Ziffer für den Port steht:
Die Antwort ist ein “Registered” – zu deutsch also “erfolgreich bei der Telefonanlage angemeldet”. Damit sind wir am Ziel. Fast. Denn nun möchte PRTG noch instruiert werden.
Dort füge ich einen neuen Sensor auf dem Grandstream hinzu:
Der naheliegende “SNMP (Benutzerdef.)” führt nicht zum Ziel, weil er nur Integer-Werte auswertet, also etwa ein “1”. Der Grandstream antwortet jedoch mit dem String “Registered”. Paessler schreibt dazu diplomatisch: “PRTG is able to work-around such doubtful SNMP implementations”. Man möge den SNMP Custom String Sensor nutzen.
Auch da braucht es noch mal kurzes Mitdenken. Die Suche nach “Registered” würde immer zu einem positiven Ergebnis führen, auch bei einem “Not Registered”. Also drehe ich den Spieß um und definiere eine doppelte Verneinung, gewissermaßen “Sag niemals Nie!”:
Damit bin ich endlich am Ziel:
Der Vollständigkeit halber prüfe ich auch noch den Fehlerfall:
Wie gesagt, man muss schon Spaß haben an solcher Tüftelei. Aber wenn’s gelingt, ist die Befriedigung um so größer.