3
NET SNMP Doppelte Knotennamen in unterschiedlichen Zweigen
Wir entwickeln gerade in einem Projekt unsere eigene MIB um eine Kommunikation zwischen Oberfläche und Dienst sicherzustellen. D.h. wir trennen DIENST und Oberfläche so voneinander, dass die Übertragung ausschließlich via NET SNMP erfolgt.
Bei der Entwicklung der MIB Baumstruktur haben wir entsprechende Knoten erstellt, wie man das ebenso macht. Dabei haben wir auch Knoten verwendet die namentlich doppelt vorkommen, aber in ganz unterschiedlichen Zweigen sind. Das geht anscheinend leider nicht. Glücklicherweise sind „doppelte“ Blätter Bezeichnungen möglich, sonst wäre das Projekt ernsthaft in Gefahr gewesen.
Kennt jemand eine Lösung für mein Problem der „doppelten“ Knotennamen (aber in unterschiedlichen zweigen), so dass ich diese dennoch benutzen kann und dann auch noch Standard Konform bin. Gibt es dazu ggf. sogar eine „Vorschrift“ oder Einschränkung? Ich habe bislang nicht s dazu gefunden.
Würde mich sehr über ein Feedback freuen.
WirCom
Kennt jemand eine Lösung für mein Problem der „doppelten“ Knotennamen (aber in unterschiedlichen zweigen), so dass ich diese dennoch benutzen kann und dann auch noch Standard Konform bin. Gibt es dazu ggf. sogar eine „Vorschrift“ oder Einschränkung? Ich habe bislang nicht s dazu gefunden.
Würde mich sehr über ein Feedback freuen.
WirCom
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 195444
Url: https://administrator.de/contentid/195444
Printed on: April 25, 2024 at 14:04 o'clock
3 Comments
Latest comment
Auf diese Frage gibt es nur eine einzige sinnvolle Antwort:
Lies dir den IEEE Standard durch:
http://tools.ietf.org/html/rfc1441
und
http://tools.ietf.org/html/rfc1452
bzw. wenn du Ver.3 benutzt:
http://tools.ietf.org/html/rfc3411 bis rfc3418
Die RFC sind weltweit bindend und beschreiben bis ins Detail WIE diese Dinge zu implementieren sind und was erlaubt ist oder nicht. Für alle Entwickler weltweit sind diese Dokumente bindend denn sie beschreiben den Standard bzw. das Framework an die sich alle halten müssen die zu dem Standard konform sein müssen.
Alles andere ist Bastelei im freien Fall und hat nichts mit seriöser Entwicklung zu tun wenn man sich auf den SNMP Standard bezieht !
Lies dir den IEEE Standard durch:
http://tools.ietf.org/html/rfc1441
und
http://tools.ietf.org/html/rfc1452
bzw. wenn du Ver.3 benutzt:
http://tools.ietf.org/html/rfc3411 bis rfc3418
Die RFC sind weltweit bindend und beschreiben bis ins Detail WIE diese Dinge zu implementieren sind und was erlaubt ist oder nicht. Für alle Entwickler weltweit sind diese Dokumente bindend denn sie beschreiben den Standard bzw. das Framework an die sich alle halten müssen die zu dem Standard konform sein müssen.
Alles andere ist Bastelei im freien Fall und hat nichts mit seriöser Entwicklung zu tun wenn man sich auf den SNMP Standard bezieht !
Hallo Aqui,
besten Dank für Dein Feedback. Du hast natürlich recht, dass man die RFC´s für so ein Projekt befolgen sollte um "seriös" zu programmieren. es betrifft mich abe rnur zu einen geringen Teil und kämpfe, damit was ich "zugeworfen" bekomme. Teilweise gebe ich mich mit den zugeworfenen Broken und Einschränkungen der entwickler zufrieden und teilweise nicht, wie in diesem Aufruf.
Ich habe mal versucht mich durch die RFC´s durchzuarbeiten. und wie folgt gefunden:
3.1.1.1. snmpEngineID
Within an administrative domain, an snmpEngineID is the unique and
unambiguous identifier of an SNMP engine. Since there is a one-to-
one association between SNMP engines and SNMP entities, it also
uniquely and unambiguously identifies the SNMP entity within that
administrative domain. Note that it is possible for SNMP entities in
different administrative domains to have the same value for
snmpEngineID. Federation of administrative domains may necessitate
assignment of new values.
3.3.1. An SNMP Context
Each context has (at least) one unique identification within the
management domain. The same item of management information can exist
in multiple contexts. An item of management information may have
multiple unique identifications. This occurs when an item of
management information exists in multiple contexts, and this also
occurs when a context has multiple unique identifications.
Mir ist zwar klar, dass ich innerhalb der selben Ebene unique sein muss, aber nicht in den anderen Ebenen.
Ist das so, oder habe ich nur nicht richtig gelesen und sehe den Wald vor lauter Bäumen nicht.
Grüße
Wircom
besten Dank für Dein Feedback. Du hast natürlich recht, dass man die RFC´s für so ein Projekt befolgen sollte um "seriös" zu programmieren. es betrifft mich abe rnur zu einen geringen Teil und kämpfe, damit was ich "zugeworfen" bekomme. Teilweise gebe ich mich mit den zugeworfenen Broken und Einschränkungen der entwickler zufrieden und teilweise nicht, wie in diesem Aufruf.
Ich habe mal versucht mich durch die RFC´s durchzuarbeiten. und wie folgt gefunden:
3.1.1.1. snmpEngineID
Within an administrative domain, an snmpEngineID is the unique and
unambiguous identifier of an SNMP engine. Since there is a one-to-
one association between SNMP engines and SNMP entities, it also
uniquely and unambiguously identifies the SNMP entity within that
administrative domain. Note that it is possible for SNMP entities in
different administrative domains to have the same value for
snmpEngineID. Federation of administrative domains may necessitate
assignment of new values.
3.3.1. An SNMP Context
Each context has (at least) one unique identification within the
management domain. The same item of management information can exist
in multiple contexts. An item of management information may have
multiple unique identifications. This occurs when an item of
management information exists in multiple contexts, and this also
occurs when a context has multiple unique identifications.
Mir ist zwar klar, dass ich innerhalb der selben Ebene unique sein muss, aber nicht in den anderen Ebenen.
Ist das so, oder habe ich nur nicht richtig gelesen und sehe den Wald vor lauter Bäumen nicht.
Grüße
Wircom
Hallo,
also wir anhand der RFC keine Einschränkung gefunden und es noch mal durchgetestet in der Praxis.
Dabei haben wir mit "net-snmp" dennoch die Erfahrung gemacht, dass keine doppelten Knoten verwendet werden dürfen innerhalb der gleichen MIB, auch dann nicht, wenn diese Knoten an völlig verschienen Stellen liegen und somit nicht in der gleichen Ebene sind.
Dementsprechend noch mals die Frage an die Community: Hat einer von euch diese Erfahrung bereits gemacht, könnte das ein Problem von net-snmp sein, oder ist es "meine" Problem?
Würde mich über ein Feedback freuen.
Grüße
WirCom
also wir anhand der RFC keine Einschränkung gefunden und es noch mal durchgetestet in der Praxis.
Dabei haben wir mit "net-snmp" dennoch die Erfahrung gemacht, dass keine doppelten Knoten verwendet werden dürfen innerhalb der gleichen MIB, auch dann nicht, wenn diese Knoten an völlig verschienen Stellen liegen und somit nicht in der gleichen Ebene sind.
Dementsprechend noch mals die Frage an die Community: Hat einer von euch diese Erfahrung bereits gemacht, könnte das ein Problem von net-snmp sein, oder ist es "meine" Problem?
Würde mich über ein Feedback freuen.
Grüße
WirCom
