KevJon
Anfänger
Beiträge: 4
Anzahl Nagios-Server: 1
Nagios-Version(en): 1
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 641
Anzahl Services: 35
Betriebssystem(e): 5
Plugin-Version(en): 1
NDO-Version: 1
1
21.04.2011, 14:32
Beiträge: 1 355
Anzahl Nagios-Server: 2-5
Nagios-Version(en): 1-3
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 80-200
Anzahl Services: 1400-2000
Betriebssystem(e): Linux
Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)
Sonstige Addon's: n2rrd, PNP, livestatus
2
21.04.2011, 17:26
KevJon
Anfänger
Beiträge: 4
Anzahl Nagios-Server: 1
Nagios-Version(en): 1
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 641
Anzahl Services: 35
Betriebssystem(e): 5
Plugin-Version(en): 1
NDO-Version: 1
3
21.04.2011, 20:42
Beiträge: 1 355
Anzahl Nagios-Server: 2-5
Nagios-Version(en): 1-3
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 80-200
Anzahl Services: 1400-2000
Betriebssystem(e): Linux
Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)
Sonstige Addon's: n2rrd, PNP, livestatus
4
21.04.2011, 22:45
Wo schrieb ich denn 'was von "einfach"?
Zitat von »KevJon«
Im Prinzip, ja. Aaaber ein einfacher Index is dat nich.
Also Modul "TEDI", Zeitstempel 05-Oct-2007 10:44:51.0 UTC+02:00. (Die 11 ist ein VT, das scheint die Desc geschlabbert zu haben. 7*256+215 = 2007.)
Zitat von »KevJon«
Beispiel zu Varbind 2:
1.3.6.1.4.1.xxx.yyy.2.666.1.2.2.1.10(OID) .4(Length of Module) .84.69.68.73(Module Name) .11.7.215.10.5.10.44.51.0.43.2.0(Date and Time yy.yy.mm.dd.hh.mm.ss.dss.+/-.hhUtc.mmUtc) .1(Alarm Sequence Number)
Wieso, hab' ich doch grad' oben vorgerechnet. Sowohl Strings beschränkter Länge als auch Zeitstempel wie in Deinem Zitat definiert sind endliche Zustandsräume, also auf endliche Bytefolgen abbildbar ...
Zitat von »KevJon«
Das Teil hat ungezählte Module und Date and Time in den OID Baum reinzukriegen ist m.E. unmöglich.
KevJon
Anfänger
Beiträge: 4
Anzahl Nagios-Server: 1
Nagios-Version(en): 1
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 641
Anzahl Services: 35
Betriebssystem(e): 5
Plugin-Version(en): 1
NDO-Version: 1
5
22.04.2011, 10:58
Zitat
Also Modul "TEDI", Zeitstempel 05-Oct-2007 10:44:51.0 UTC+02:00. (Die 11 ist ein VT, das scheint die Desc geschlabbert zu haben. 7*256+215 = 2007.)
Zitat
Sowohl Strings beschränkter Länge als auch Zeitstempel wie in Deinem Zitat definiert sind endliche Zustandsräume, also auf endliche Bytefolgen abbildbar ...
Beiträge: 1 355
Anzahl Nagios-Server: 2-5
Nagios-Version(en): 1-3
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 80-200
Anzahl Services: 1400-2000
Betriebssystem(e): Linux
Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)
Sonstige Addon's: n2rrd, PNP, livestatus
6
22.04.2011, 18:38
Dir ist schon klar, daß Du bis jetzt mit keinem Wort verraten hast, was für ein "System" Du überhaupt auf der Trap-Empfänger-Seite hast? 'Mal abgesehen davon, daß Du im Unterforum Betriebssysteme/Linux postest ...
Zitat von »KevJon«
Daraus verstehe ich, dass die gelieferten OIDs tatsächlich korrekt sind. Wie bekomme ich das meinem System beigebogen?
KevJon
Anfänger
Beiträge: 4
Anzahl Nagios-Server: 1
Nagios-Version(en): 1
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 641
Anzahl Services: 35
Betriebssystem(e): 5
Plugin-Version(en): 1
NDO-Version: 1
7
26.04.2011, 09:46
War der Meinung, dass es für den Fall nicht wirklich relevant ist. Es handelt sich um ein OpenMaster Version 7.0.
Zitat
Dir ist schon klar, daß Du bis jetzt mit keinem Wort verraten hast, was für ein "System" Du überhaupt auf der Trap-Empfänger-Seite hast?
Ich hab nach der angesprochenen MIB gesucht, aber nix (jedenfalls nicht die MIB selbst) gefunden. Dass die Net-SNMP Tools da flexibler sind ist gut, aber ich hab auf meiner Kiste leider keine drauf. Somit hilft mir das im Moment nicht weiter mein Problem zu lösen.
Zitat
Die ADVA-Gschicht steht in den MIBs drin, wie gesagt als INDEX, und ich erinnere mich, daß die Net-SNMP Tools das durchaus hinbekommen haben
Genau, drum kann das OpenMaster System die Trap OIDs nicht auswerten.
Zitat
(Varbinds in einem) Trap(s) sind zugegebenermaßen eine andere Sache, und OID-Konstrukte, die nicht formell korrekt in der MIB definiert sind, auch.
So haben beide Seiten ihre Meinung korrekt zu arbeiten. Und der OMC-Admin muss nach einer Lösung suchen. Entweder einem von beiden beweisen, dass ein Fehler vorliegt oder eine Lösung in einer OMC bekannten Programmiersprache zu entwickeln. Am liebsten wäre mir 'ne MIB Definition. Nur ohne konkretes Beispiel komme ich nicht weiter. Ne Idee?
Zitat
Das OMC kennt dieses spezielleAPI nicht.
Vom OMC werden die Trap-Attribute im gelieferten "erweiterten" Format zwar akzeptiert, allerdings nicht aufgelöst. Das führt dazu, dass die eintreffenden Events im Eventlog vollständig angezeigt werden, allerdings werden keine Namen für die Attribute angezeigt, sondern nur die "erweiterten" OIDs. Das OMC kann nur die OIDs auflösen, die auch in einer MIB spezifiziert sind - so wie es im Standard definiert ist.
Bei der weiteren Qualifizierung im OMC werden die nicht auflösbaren Attribute entfernt, so dass diese im Alarmlog nicht mehr angezeigt werden.
Zitat der Mail vom ........... (die mit dem PDF Anhang), dass die-ALARM-MIB.mib auf RFC3877 basiert. Aus dem zitierten RFC ist die von verwendete OID-Bildungsregel nicht ableitbar. Im Gegenteil, dort steht im Abschnitt 3.6 "the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined". Darus folgt, dass sich NICHT standardkonform verhält. Wir lassen uns gerne eines Besseren belehren, aber dazu sollte mindestens angeben, aus welchem RFC die Bildungsregel abgeleitet ist. Ansonsten ist es weiterhin ein Fehler von .
Beiträge: 1 355
Anzahl Nagios-Server: 2-5
Nagios-Version(en): 1-3
Verteiltes Monitoring: Nein
Redundantes Monitoring: Nein
Anzahl-Hosts: 80-200
Anzahl Services: 1400-2000
Betriebssystem(e): Linux
Plugin-Version(en): Whatever I can download, patch, or cobble together myself :-)
Sonstige Addon's: n2rrd, PNP, livestatus
Also die Antwort ist 'ne Ver...äppelung. Erstens lautet das vollständige Zitat des RFCs:
Zitat von »KevJon«
Der OMC Hersteller sagt dazu folgendes:
Zitat
Zitat der Mail vom ........... (die mit dem PDF Anhang), dass die-ALARM-MIB.mib auf RFC3877 basiert. Aus dem zitierten RFC ist die von verwendete OID-Bildungsregel nicht ableitbar. Im Gegenteil, dort steht im Abschnitt 3.6 "the varbinds in the Trap-PDU sent over the wire map one to one into those varbinds listed in the SMI of the trap in the MIB in which it was defined".
Jo, das kenn' ich ... die Entwickler bei ADVA haben auch 'mal geglaubt, sie seien im Recht, wenn sie ein Interface als operationally down deklarieren, wenn die vom anderen Ende angebotenen AutoNeg-Optionen ihrer Ansicht nach nicht standardkonform waren. Ergebnis: Interfaces, die "down" sind und über die trotzdem full wirespeed Traffic läuft.
Zitat von »KevJon«
So haben beide Seiten ihre Meinung korrekt zu arbeiten. Und der OMC-Admin muss nach einer Lösung suchen. Entweder einem von beiden beweisen, dass ein Fehler vorliegt oder eine Lösung in einer OMC bekannten Programmiersprache zu entwickeln. Am liebsten wäre mir 'ne MIB Definition. Nur ohne konkretes Beispiel komme ich nicht weiter. Ne Idee?
Zitat
Darus folgt, dasssich NICHT standardkonform verhält. Wir lassen uns gerne eines Besseren belehren, aber dazu sollte mindestens angeben, aus welchem RFC die Bildungsregel abgeleitet ist. Ansonsten ist es weiterhin ein Fehler von .