Nagios-/Icinga-Portal

Ist das sowas, daß man eine OID x.y.z.66.108.97.104 hat und das steht dann für fooBarBaz."Blah" (ASCII Values aneinandergereiht)? Wenn ja, dürftest Du Pech haben; Das heißt INDEX und steht schon in der SNMPv2-SMI MIB drin.

(Und wenn man auf einer nicht allzu neuen ADVA CPE einen ESA Test laufen läßt, der per String (Name) eindeutig identifiziert wird, und dessen Ergebnisse per SNMP abholen will, dann macht man einen snmpwalk auf esaProbeStatsEntry."Name".)

Zitat von »KevJon«

Im Prinzip, ja. Aaaber ein einfacher Index is dat nich.

Wo schrieb ich denn 'was von "einfach"? Ich kann das Prinzip auch nicht sonderlich gut leiden, muß aber zugeben, daß die Alternative im genannten ADVA-Szenario (ESA Tests mithilfe einer lfd. Nummer in der OID abbilden und die OID zum Test "FooBarBaz" muß man sich per snmpwalk über den Teilbaum mit den Namen suchen) auch nicht wirklich göttlich wäre.

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)

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«

Das Teil hat ungezählte Module und Date and Time in den OID Baum reinzukriegen ist m.E. unmöglich.

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«

Daraus verstehe ich, dass die gelieferten OIDs tatsächlich korrekt sind. Wie bekomme ich das meinem System beigebogen?

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 ...

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 - maW ich habe bei einem snmpwalk/snmpget tatsächlich Ausgaben bekommen so ähnlich wie

covEsa::esaProbeMaxRoundTrip."TestName" = INTEGER: 4711

(Varbinds in einem) Trap(s) sind zugegebenermaßen eine andere Sache, und OID-Konstrukte, die nicht formell korrekt in der MIB definiert sind, auch. In einem Konstrukt aus snmptrapd und snmptt würde ich 'mal schätzen, daß snmptrapd OIDs in Varbinds immer noch numerisch an snmptt gibt und dessen Config-File-Syntax dürfte dann wohl Probleme haben, damit mehr Auswertung zu treiben als per Regexp Match einzelne Modules zu identifizieren ...

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".

Also die Antwort ist 'ne Ver...äppelung. Erstens lautet das vollständige Zitat des RFCs:

In SNMPv1 [RFC1157], 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 [RFC1215].

Zweitens geht's in dem Abschnitt um die Frage, welche Varbinds bei der Definition des Traps anzugeben sind, und keineswegs darum, daß die in einem Varbind vorkommenden OIDs in dieser Definition abschließend und vollzählig aufgeführt werden müssen.

Zitat von »KevJon«

Zitat

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 .

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?

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. Hat IIRC zwei Jahre und jede Menge von Markt zuschanden gewatschte Sales-Leute gebraucht, um das zu korrigieren.

Aber zurück zum Thema. Eine direkte Unterstützung für die dargestellte Bauart von OIDs sehe ich dem RFC beim Querlesen auch nicht, wohl aber ausgiebige Darstellung von Varbinds, die lediglich ein Verweis auf Alarm Tables des Trap-Senders sein müssen. Ohne mich zum SNMP-Papst aufzuspielen, würde ich daraus schließen, daß

• der Trap-Sender in Varbinds durchaus OIDs schicken darf, die es in exakt dieser Form vor dem Alarm noch gar nicht gab und die man per snmpget o.ä. abfragen müßte/soll, um weitere Informationen zum Alarm zu bekommen, und
  
• der Trap-Empfänger durchaus das Recht hat, auf solche zusätzlichen Abfragen zu verzichten und auch die Tatsache zu ignorieren, daß solche OIDs auf irgendeine "sprechende" Art gebaut sind (speziell wenn sich diese gar nicht vollständig in ASN.1 Syntax darstellen läßt).
  

Wobei letzteres immer noch etwas anderes ist als daß ein Monitoring-System hingeht und "unverständliche" OIDs/Varbinds glatt wegschmeißt.

Wenn OMC darauf besteht, daß sie sozusagen "eindeutige und unveränderliche" OIDs für die Varbinds vergekaut kriegen müssen, hast Du mit den realiter eingebauten Timestamps wohl gelitten. Dann wäre ein selbstgebautes Konverter-Plugin - wenn ich Deinen Hinweis auf die "OMC bekannte Programmiersprache" da richtig verstehe? - wohl der gangbarste Weg ...