Hallo,
ich habe ein Problem mit den IBM System X Sensoren auf einen Windows Server 2008 R2.
Ich habe soweit alles ausprobiert, um den Fehler zu lokalisieren, jedoch ohne Erfolg.
Das Problem besteht im Wechsel, sodass die Sensoren nicht dauerhaft ausfallen, sondern diese im Wechsel von wenigen Minuten ausfallen und anschließend wieder funktionieren. Die Meldung lautet im Fehlerzustand: No Such Name (SNMP-Fehler # 2)
Ich habe zum Test weitere SNMP Sensoren hinzugefügt, diese verursachen keine derartigen Fehler. Daher kann ich mir nicht vorstellen, dass es an SNMP liegt.
Auf einen 2. Server (andere Hardware, gleiches OS) funktionieren die Sensoren ohne beschriebene Probleme.
Ich habe bereits den System Director und SNMP erneut installiert.
Mittlerweile bin ich verzweifelt und weiß nicht mehr weiter. Über jede Hilfe wäre ich froh.
Article Comments
Hallo
Ich hab genau das selbe Problem, ausser dass bei mir Fehler #2003 gemeldet wird. Jede zweite SNMP-Abfrage schlägt fehl. Wechselt sich schön ab zwischen no resonse und ok. So weit ich sehe, betrifft das nur Server mit Windows 2008 R2 und auch nur solche, die im selben Subnetz stehen wie die Probe. Ich hab Wireshark installiert auf einer Probe und mir den Traffic mal angesehen. SNMP-Anfragen gehen raus, aber es kommen tatsächlich keine Antworten zurück.
Ich hab am Dienstag das Update installiert. Hatte das schon vorher vereinzelt beobachtet, aber nicht mit dieser Regelmässigkeit. Die halbe DMZ steht jetzt den ganzen Tag auf rot. :(
Jun, 2015 - Permalink
Hi,
das Problem liegt bei mir jedoch nicht an SNMP. Ich habe andere SNMP Sensoren, die keine Probleme haben. Bei mir sind es nur jene, die für IBM System X sind.
Ich habe mittlerweile auch einiges an Support von PRTG erhalten. Es heißt nun, dass das Problem bei IBM liegt und nicht an PRTG. So richtig glauben kann ich das nicht. An einem anderen Server habe ich die Probleme nicht. Der Server liegt ebenfalls im gleichen Netz wie der Problem Server. Nur halt unterschiedliche Hardware gleiches OS (2008 r2). Ich glaube, dass die MIB's nicht wirklich passen für meinen Problem Server und das würde bedeuten, dass es doch an PRTG liegt.
Ich versuche gerade mir eigene Sensoren zu bauen.
Jun, 2015 - Permalink
Hi,
ein Fehler #2003 weist darauf hin, dass keine Verbindung vom PRTG Host bzw. der PRTG Remote Probe zum Zielsystem hergestellt werden kann. Wie rpzhdk bereits durch Wireshark festgestellt hat, verlassen die SNMP-GET Befehle den Monitoring-Server, kommen aber aus irgendwelchen Gründen nicht beim Zielsystem an, oder werden von dem Zielsystem nicht beantwortet.
Sie können zum einen den SNMP Tester zum Fehlerzeitpunkt benutzen um zu schauen, welche Antwort Sie erhalten, natürlich können Sie auch jegliches andere SNMP Tool Ihrer Wahl benutzen.
Die IBM-eigenen OIDs befinden sich hinter der OID
1.3.6.1.4.1.2.6.159
oder
1.3.6.1.4.1.2.3.51
Solange die IBM Server nicht auf SNMP-Anfragen antworten, hat PRTG keine Möglichkeit die Werte zu erhalten.
Viele Grüße
Jun, 2015 - Permalink
Hallo sadfr
Ich hab mittlerweile den Fehler in inserem Setup gefunden. Es hat überhaupt nichts mit PRTG oder dem Zielsystem zu tun. Schuld ist die Proxy ARP Funktion der Firewall. Die Meldet, dass die Ziel-IP ihr gehört, woraufhin die Pakete an die falsche MAC-Adresse geliefert werden. Das ist offenbar Standardverhalten bei vielen Cisco Geräten. Wir haben das abgeschaltet und nun läuft alles wie geschmiert.
Überprüf mal die Firewall bzw. Router für dies Netz und schalt das gegebenenfalls ab. Würd mich wunder nehmen, ob's hilft.
Gruss Roberto
Jul, 2015 - Permalink
Hi,
danke für das Feedback. Ich bin immer noch am Kämpfen mit dem Problem. Bei mir scheint es aber ein anderes Problem zu sein, da ich mehrere Server auf Hardware habe und die Überwachung auf 3 Servern wunderbar funktioniert.
Mit Wireshark habe ich mir angeschaut wie das Zielsystem antwortet. Das Zielsystem antwortet mit "No such Name".
Daher gehe ich davon aus, dass das Problem bei mir an anderer Stelle zu suchen ist. Mir wurde bereits gesagt ich solle ein IBM Systems Director Support Paket kaufen und mit IBM darüber sprechen.
Mittlerweile nervt es tierisch, da ich das Problem nicht in den Griff bekomme.
Meinst du auch in meinem Fall könnte es etwas mit dem ARP Proxy zu tun haben? Das gerade dieses eine Zielsystem damit Probleme macht?
Als Information noch ganz nützlich: Der Core Server ist virtualisiert mit Hyper-V und läuft auf dem Zielsystem welches Probleme verursacht.
Jul, 2015 - Permalink
Habe jetzt auch nochmal alles überprüft. Die ARP Proxy Funktion war bei mir nicht aktiviert. Das Häkchen war raus. Die Switche im Serverschrank haben die Funktion nicht.
Wie geschrieben kommen die Oakete ja beim Zielsystem an, jedoch antwortet das Zielsystem mit No such Name. Also gehe ich hier mittlerweile von einem Problem am Zielsystem aus.
Jul, 2015 - Permalink
Ja das hört sich schwer nach nem Fehler im Zielsystem an. Aber einen Versuch war's wert.
Was für Werte versuchst Du denn abzurufen? Wir haben unsere IBM Blades letztes Jahr entsorgt. Den Director hatte ich schon 5 Jahre früher abgeschafft. Überwacht haben wir alles was ging direkt über die Daten, die Windows von Haus aus liefert. Den Rest haben wir aus dem Management Modul gelesen. iLO, CIMC, AMM oder wie auch immer das Ding heute heisst. Wenn Du das anzapfen kannst, würd ich's mal so versuchen. Da müssten die wichtigsten Hardwaredaten vorhanden sein.
Ich mag mich erinnern, dass bei IBM alles extrem von der Firmware abhängt. Falls nicht schon geschehen, installier mal die "latest" Updates mit dem UXSP. Viel mehr fällt mir jetzt grad nicht ein. Die Meldung "No such Name" krieg ich eigentlich nur, wenn ich was an der Hardware des Zielsystems ändere.
Jul, 2015 - Permalink
Heute kommen die Infos aus dem IMM. Die neuste Firmware wollte ich auch schon installieren. Das werde ich als nächstes machen.
Nach einem Neustart habe ich das Problem auf 3 von 4 Servern. SNMP läuft weiterhin, nur nicht die IBM Sensoren. So langsam werde ich echt sauer!!
Werde mal das IMM aktualisieren.
Überwachen möchte ich die Festplatten, logische Disks, System Health, RAM. Zur Zeit alle samt fehlerhaft ohne Chance auf Besserung.
Jul, 2015 - Permalink
Schicken Sie uns bitte ein Support Ticket inkl. Support Bundle zur Analyse.
Jun, 2015 - Permalink