Diskussion:Simple Network Management Protocol

OID-Adressen

Gibt es eine Liste der OID-Adressen? also z.B. 1.3.6.1.2.1.1.3, etc?

Können Links zu programmen gegeben werden, die die SNMP-Daten aus Routern etc. auslesen können?

Danke, --Abdull 00:32, 14. Mär 2005 (CET)

Jeder Hersteller sollte MIBs für seine Geräte (Router, Bridges, Hosts, Netzwerkdrucker etc.) bereitstellen. Diese kann man dann in sein Netzwerkmanagementsystem einlesen. In RFCs sind auch MIB-II, RMON etc. standardisiert, z. B. für Netzwerkdrucker RFC 1759, die RMON-MIB etwa bei www.mg-soft.si/mgMibExplorer-samples/RMON-MIB.html. Bei freshmeat.net findest du gerade einen Einführungsartikel zu Netzwerkmanagementsystemen NMS und natürlich auch die GPL-Tools wie Net-SNMP. --Hubi 07:01, 14. Mär 2005 (CET)

1) Net-SNMP installieren. Mit snmptranslate -m ALL ... lassen sich OIDs eingeben und in MIB-Referenzen übersetzen.

2) Mit der Liste "enterprise-numbers" findet man heraus, wer der Hersteller von private MIBs ist. -- Jensstark 12:43, 3. Jul. 2009 (CEST)

„Der Trap“ oder „Die Trap“

_Der_ Trap? Meinem unmaßgeblichen Sprachempfinden nach sind Traps weiblich. --Zarquod 17:48, 8. Mär 2006 (CET)

Also ich bin der Meinung: Der Trap, die Traps.... --Rene Bretz (ReneOFD) 14:13, 10. Mär 2006 (CET)

Meistens geht man doch nach dem entsprechenden deutschen Wort, also hier die Falle, somit die Trap. --ChristianErtl 10:51, 8. Jun 2006 (CEST)

Wir reden auch immer von der/dem Trap (Falle/Ereignis/Ausnahmesituation ...) also männlich.

Bei uns in der Firma wird auch nur von den/dem SNMP Trap(s) gesprochen.

Der Trap/ die Traps ist allgemein gebräuchlich. Im Falle von "von der Falle" reden ist Falle grammatikalisch gesehen trotzdem weiblich. Da Traps ja eigtl Ereignisse sind, die gemeldet werden, wäre auch das Trap "korrekt". Da sich aber der Trap nunmal eingebürgert hat, bevorzuge ich die männliche Form (auch bei das Email wird mir immer übel).

Kasten

Ich habe mal versucht, eine Taxobox für Netzwerkprotokolle anzufangen. Für die Protokollstapel habe ich Vorlagen gebaut

• Vorlage:Netzwerk-TCP-IP-Anwendungsprotokoll FTP,...
• Vorlage:Netzwerk-UDP-IP-Anwendungsprotokoll SNMP, DHCP etc.
• Vorlage:Netzwerk-TCP-UDP-IP-Anwendungsprotokoll z.B. DNS, NTP

Leider muss dort float:right eingetragen sein, der Parameter um den Protokollstapel in der Taxobox zentriert anzuzeigen, funktioniert aber noch nicht richtig. Falls möglich, würde ich irgendwann auch eine Vorlage für die Box präferieren. --Hubi 16:25, 11. Mär 2006 (CET)

Wieso ist im Kasten "TCP/IP ..." erwähnt, wenn es sich um UDP handelt? -- demx8as6 (23:16, 19. Mai 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Diskussionsbeiträge im Review

Ich hatte mich mit diesem Protokoll eine Zeitlang beschäftigen müssen und dabei diesen Artikel stark erweitert. Nachdem alles was ich über das Protokoll für erwähnenswert halte drin ist und es in den letzten Monaten auch keine nennenswerten Änderungen mehr gegeben hat, will ich das ganze zu einem Abschluss bringen und hier prüfen lassen. Ich habe jetzt noch mal alle Links geprüft und den kompletten Text nach Word kopiert und ihn von der Word-Rechtschreibhilfe prüfen lassen. --Stefan2 10:18, 4. Mai 2006 (CEST)

Hallo, Stefan2, wo sind denn die ganzen Technik-Leute hin ? Ich bin jetzt wohl der erste, der Dir eine Rückmeldung gibt. Zunächst mal, es ist ein guter Artikel und er gefällt mir. Jetzt kommt das "aber": es ist ein Expertenartikel mit viel Liebe zum Detail, Omas und Erstsemester kommen etwas zu kurz. Deswegen folgende Anregung: Die Einleitung sollte einen Überblick über ein ganzes System mit Management-Station, Kommunikationsnetzwerk und gemanagten Geräten geben. Am besten als Grafik, weil ein Bild mehr sagt als 1000 Worte. Mit so einer Einleitung ist dann im Text schnell der Übergang zu der Grafik gemacht, die Du "das Prinzip der SNMP-Kommunikation" genannt hast. Dann wird nämlich besser klar, zwischen welchen Partnergeräten das Protokoll läuft. Was ich außerdem noch als Lücke empfinde: es gibt keine Grafik, in der eine MIB auftaucht. Im Text kommt nicht richtig raus, daß auch im gemanagten Gerät eine MIB ist, auf die der Agent zugreift, und deren Daten er via SNMP an die Management-Station schickt. Das wären erstmal zwei Vorschläge, wie sich der Artikel noch besser machen liesse. Mir ist schon klar, daß meine Vorschläge nicht das Protokoll selbst betreffen, sondern seine Anwendung. Aber die Anwendung ist ein wichtiger Aspekt. Fink 20:50, 9. Mai 2006 (CEST)

Erst mal danke fürs durchsehen des Artikels und die Anregungen. Dieses Thema nicht zu einem Expertenartikel werden zu lassen ist schon ganz schön schwierig. Ich hoffe das es trotzdem für die meisten Menschen möglich ist, mit Hilfe der Einleitung zu verstehen wozu SNMP überhaupt benötigt wird. Ein paar Bilder die hilfreich sein könnten habe ich mittlerweile hinzugefügt. Das erste Bild war ein kleines Problem, da in der Einleitung am rechten Rand dieser Kasten ist. Ich habe das Bild deshalb unter den Text gesetzt. Ein Bild mit einem MIB-Baum folgt noch demnächst (bin noch am zeichnen). Außerdem habe ich die Kapitel „Funktionsweise“ und „Management Information Base“ noch mal kräftig umformuliert, in der Hoffnung, das für einen Laien es leichter verständlich wird. Für weitere Anregungen bin ich aber weiterhin dankbar. --Stefan2 23:28, 28. Mai 2006 (CEST)

Ein sehr detaillierter Beitrag, der bei mir (totaler Laie) eine Mischung aus Respekt vor dem Fachwissen und Hilflosigkeit auslöst. Kannst Du den Artikel mal darauf hin durchschauen, ob Fachworte wie "Managementtool" nicht ersetzbar sind? Um die Einleitung besser zu verstehen, muss man als Laie schon einige von den verlinkten Artikeln gelesen und verstanden haben (Beispiele: Netzwerkprotokoll, Router, Switches,...). Für mein Gefühl (mehr kann ich leider nicht bieten) wäre es anschaulicher, das anschaulichere Bild über die zentrale Funktion des SNMP durch die Managementkonsole nach oben zu nehmen. Die jetzt am Anfang stehende Tabelle ist für Laien nicht verständlich und trägt auch zum Verständnis des Lemmas nichts bei. Die Agenten werden ohne Erklärung eingeführt. Sind das auch wieder Einrichtungen, die über ein Protokoll mit Unteragenten und die wiederum mit den Netzwerkelementen kommunizieren? Ich würde in das Bild über das Prinzip der SNMP-Kommunikation noch die einem Laien schon eher bekannten Netzwerkelemente mit aufnehmen. Dann werden die Managed Objects eingeführt. Sind die identisch mit den Netzwerkelementen? Würde ich so verstehen...Dass der Manager und die MIBs in der Managementkonsole als Dateien vorliegen, nehme ich gefühlsmäßig an, könnte man aber (wenn es stimmt) auch in die Beschreibung aufnehmen. Ab da verlassen mich die weiteren Abkürzungen (OIDs, ASN.1, RFCs,...) und Versionen. Es wird (wieder nur mein Gefühl) mehr zu einem Handbuch für Leute, die sich schon eingearbeitet haben, als zu einem Enzyklopädie-Artikel für Omas.... Ich weiß, dass es sauschwer ist, so ein Thema omagerecht vorzustellen und dies soll auch nur ein Rückfluss von ganz schräg außen sein. Vielleicht ist es ja so oder so ähnlich schon eine Fundgrube für angehende Informatiker oder ein Auffrischungsartikel für welkende Fachleute. Ich wünsche dem Artikel jedenfalls noch eine Menge Rückmeldungen im Review oder spätestens bei der lesenswert-Kandidatur....--Leumar01 11:00, 29. Mai 2006 (CEST)

Danke fürs durchlesen des Artikels. Das meiste hat mir schon sehr geholfen. Ein wenig Zeit werde ich jetzt schon zum basteln brauchen. Abkürzungen und Fachbegriffe raus zu werfen geht natürlich nur bis zu einem gewissen Grad, da manches einfach zu dem Thema gehört. Aber einiges lässt sich da noch machen. Ob ich die Tabelle neben der Einleitung wirklich raus werfe muss ich mir noch mal überlegen. Die meisten Netzwerkprotokolle haben so eine Kurzübersicht. Das ist vergleichbar mit den Artikeln der Biologen, die eine Tabelle haben, in der Familie, Gattung und solche Sachen des Tieres oder der Pflanze angegeben wird. --Stefan2 12:01, 30. Mai 2006 (CEST)

Hallo, ich würde den Absatz über die MIB weniger ausführlich machen und die Inhalte eher in den Hauptartikel der MIB verschieben. Wenn jemand über MIBs etwas wissen will, sollte er die Informationen dort finden, nicht hier. MHO, -- Fleasoft 15:05, 12. Jun 2006 (CEST)

Betrifft übrigens auch die Weblinks (s. auch Diskussion zum MIB-Artikel). -- Fleasoft 15:42, 12. Jun 2006 (CEST)

Wird nicht mehr verwendet?

Der Folgende Satz entspricht nicht der Realität: Aufgrund der ernsten Sicherheitsprobleme der Versionen 1 und 2 sowie der geringen Unterstützung der Version 3 wird SNMP inzwischen in vielen Unternehmensnetzen nicht mehr verwendet. Zwischen dem 2. und 12. Juni 2006 haben sich alleine 95 Firmen bei er IANA registrieren lassen um eine private OID zu bekommen. Das zeigt eindeutig, daß auch heute noch das Protokoll in gebrauch ist und bei neuen Produkten verwendet wird. Deshalb habe ich diesen Satz erst mal aus dem Artikel entfernt. --Stefan2 16:25, 13. Jun 2006 (CEST)

Standard / Standart

Kann jemand der einen Account bei den 'Commons' hat bitte den 'standart' typo im Bild korrigieren? Könnte ich selber, aber für ein einzelnes Bild möchte ich keinen Account eröffnen. --Lak 13:17, 14. Jun 2006 (CEST)

Danke :) --Lak 08:59, 15. Jun 2006 (CEST)

Lesenswert-Kandidatur: Simple Network Management Protocol (Archivierung Abstimmung 12. Juni bis 19. Juni)

Beschreibung des Netzwerkprotokoll SNMP. Ich habe mir größte Mühe gegeben, das Thema für Laien großteils verständlich zu machen und habe dabei im Review einiges an Unterstützung bekommen. --Stefan2 12:46, 12. Jun 2006 (CEST)

•  Pro - Inhaltlich gut aufbereitet, kein ersichtlichen Fehler zu finden. -- wdwd 16:47, 12. Jun 2006 (CEST)

• Noch ohne Wertung. Beim ersten Lesen ist mir folgender Teil der Einleitung aufgefallen: Durch seine Einfachheit hat sich SNMP zum Standard entwickelt, der von den meisten Managementprogrammen unterstützt wird. Aufgrund der ernsten Sicherheitsprobleme der Versionen 1 und 2 sowie der geringen Unterstützung der Version 3 wird SNMP inzwischen in vielen Unternehmensnetzen nicht mehr verwendet. Ein Standard, der nicht mehr eingesetzt wird. Da fehlen mir weitere Informationen, warum das so ist (der kurze Verweis auf Sicherheitsprobleme reicht mir da einfach nicht) und was stattdessen eingesetzt wird. --Lyzzy 20:59, 12. Jun 2006 (CEST)

Nun der Hinweis, daß das Protokoll von vielen nicht mehr verwendet wird stammt nicht von mir, sondern wurde vor etwa einer Woche von jemand anderem eingefügt. In wie weit diese Aussage richtig ist kann ich nicht sagen. Meine Erfahrung ist eher, daß SNMP immer noch von allen unterstütz wird. Bis jetzt kann ein Unternehmen, daß Netzwerkgeräte herstellt es sich kaum leisten kann SNMP zu ignorieren. Daher weiß ich nicht so recht was ich mit dem Satz anfangen soll. Meint ihr man kann ihn mit der Bitte es mit Quellen nachzuweisen erst mal entfernen? --Stefan2 09:55, 13. Jun 2006 (CEST)

•  Kontra - Bei dem Artikel eine "Laienverständlichkeit" zu atestieren, ist ja wohl ein Witz. Der Artikel ist zu 50-70 % eine Ansammlung von Datenpaketformaten und RFC`s. Ich kapier den Kram schon, weil ich`s lange gemacht habe; trotzdem hat das einen Vertändnisfaktor von 0-3 Prozent füf Nichtfachleute. Sätze wie diesen -> "Neben den in den RFCs definierten MIBs kann jeder Hersteller von Soft- oder Hardware eigene MIBs, so genannte private MIBs, definieren, die die speziellen Eigenschaften seines Produktes wiedergeben. Diese werden unter der OID iso(1).org(3).dod(6).internet(1).private(4).enterprises(1) bei der IANA registriert." -> kapieren doch nur eingewihte Priester. Gruß auf Port 137 und 52 unter Verwendung von RFC 1274 and 73274 -> ACK -> GETBULK und GOODBYE. Boris Fernbacher 00:15, 13. Jun 2006 (CEST)

Wo liegt den genau das Problem. Die Datenpaketformate sind doch der Hauptbestandteil von SNMP, genauso wie die zahlreichen RFCs in denen die ganze Sache definiert wurde. Eine Beschwerde, das sie einen großen Teil des Artikels einnehmen kann ich nicht gelten lassen. Genauso ist es mit einigen Fachbegriffen. Würden sie fehlen, würde ich mich nicht trauen hier anzutreten. Alles was in dem kritisierten Beispielsatz vorkommt, wurde aber vorher erklärt und definiert. Jemand der den Artikel aufmerksam bis dahin gelesen hat kann das auch ohne Vorwissen verstehen. So aus dem Zusammenhang gerissen ist er natürlich unverständlich. Es wurden auch schon andere Fachartikel sogar als Exzellent ausgezeichnet, obwohl sie im Hinteren Teil sehr tief in die Materie eingestiegen sind. --Stefan2 09:55, 13. Jun 2006 (CEST)

• Laien- Kontra. Struktur und Inhalt scheinen soweit OK zu sein; ich konnte aber nach dem zweiten Kapitel bei besten Willen inhaltlich nicht mehr folgen. OMA-Test ist natürlich so eine Sache - aber ein Artikel, der am Ende ein Glossar für Abkürzungen(!) braucht, kann meiner Meinung nach nicht lesenswert sein. Es fehlt an praktischen Beispielen: Hat das z.B. mein Windows? Wo wird/wurde es KONKRET angewendet? Evt. ein Vergleich mit dem weit besser bekannten pop3 oder smtp? --Kantor.JH 12:50, 13. Jun 2006 (CEST)

Ich dachte immer selbst Fachartikel würden hier eine Chance bekommen, jedenfalls habe ich mal gelesen, das fachlich korrekte aber schwer verständliche Artikel auch als lesenswert gelten. Mit Laienverständlichkeit meinte ich, daß Begriffe wie Netzwerkmanagement oder Netzwerkprotokoll nicht als Grundwissen vorrausgesetzt werden wie in so vielen anderen Artikeln dieses Gebietes. Das gleiche gilt auch für die meisten anderen Fachbegriffe, die im Artikel auftauchen. Die Forderung wichtige Fachbegriffe zu entfernen ist nicht nachvollziehbar und wird auf keinen Fall umgesetzt. Das Glossar am Ende könnte ich natürlich entfernen, wenn der Artikel dadurch besser werden würde. Zu Deinen Fragen: Wie in der Einleitung steht unterstützen so gut wie alle SNMP und damit natürlich auch Windows. Solche Spezialfälle gehören aber nicht in den Artikel rein. Angewendet wird es beim Netzwerkmanagement. Pop3 und smtp haben nicht mit Netzwerkmanagement zu tun und haben damit auch nichts in dem Artikel zu suchen. Mal ganz ehrlich ein wenig sauer bin ich jetzt schon. Der Artikel ist ausführlich und Vollständig. Aufgabe und Funktionsweise werden erklärt. Im Review hattet ihr über einen Monat Zeit konstruktive Kritik zu üben. Bis jetzt kam hier aber nichts, was wirklich zu ändern wäre, was bei all den Kontras schon sehr merkwürdig ist. --Stefan2 14:45, 13. Jun 2006 (CEST)

• Laien- Pro Kern und Struktur und Funktion des SNMP sind mir gut klar geworden und (@Fernbacher) die Abkürzungen sind erklärt und ein Glossar für Abkürzungen (@Kantor) gibt es in jedem ingenieurwissenschaftlichen Fachartikel, ohne Einfluss auf die inhaltliche Qualität. Natürlich muss ein Laie sich in so einen Artikel mehr reinbeißen als ein Fachmann. Fachliche Tiefe ist kein Argument gegen lesenswert. Ich bin sicher, dass der Artikel für interessierte Laien (wie mich), angehende Fachstudenten und vielleicht sogar Fachleute, die sich mal wieder auf den Stand der Dinge bringen lassen wollen, als lesenswert gelten kann. --Leumar01 16:55, 13. Jun 2006 (CEST)

Es ist kein Geheimnis, daß sich bei Reviews eher die Fachleute tummeln ;-) Als Laie muss (und möchte) ich sicherlich hier (=bei den lesenswerten) auch nicht _jedes_ Detail verstehen - aber ich möchte WENIGSTENS wissen, worum es GROB geht und wo ich das UNGEFÄHR einordnen kann. Es geht ja auch gar nicht darum, daß du die Fachwörter rausschmeissen sollst - es wäre der "lesbarkeit" aber schon erheblich nützlich, wenn du das Glossar IN den Text an die entsprechenden Stellen einbauen würdest. Auch beim absoluten Laien sollte doch noch _etwas_ mehr hängenbleiben als die Information: "SNMP ist ein Netzwerkprotokoll zur Überwachung von anderen Netzwerkgeräten, was verschiedene Versionen und ganz viele technische Details hat..." --Kantor.JH 16:52, 13. Jun 2006 (CEST)

•  Kontra Der Artikel erscheint mir doch sehr schwer verständlich. Es mangelt an konkreten Anwendungen und Beispielen für Software, die SNMP verwendet. Außerdem werden unverhältnismäßig viele Abkürzungen benutzt, die am Ende noch in einem Abkürzungsverzeichnis erklärt werden müssen. Die Aufzählungen der Versionen mit den RFCs liest sich auch nicht gut. Dann sind da noch diese Kästen, die den Aufbau der Pakete beschreiben sollen, die so aber praktisch nicht verständlich sind. In anderen Artikel, etwa zu TCP oder UDP sind die entsprechenden Darstellungen deutlich besser. Saemon 21:24, 13. Jun 2006 (CEST)

Ein Blick in den exzellenten TCP-Artikel zeigt mir, dass zu dem hier vorliegenden kaum ein Unterschied in Aufzählungen und Abkürzungsvielfalt zu sehen ist, sondern er eher mit noch mehr unerklärten Fachbegriffen durchwachsen ist. (Aus der Diskussionseite dieses Artikels geht übrigens für mich nicht hervor, wann und mit welcher Abstimmung er exzellent geworden ist! Hat da jemand einfach so das Bapperl reinsetzen können?) Ganz schön unterschiedliche Maßstäbe liegen für mich hier offensichtlich vor. Ich verstehe die Wiki-Welt aber vielleicht noch nicht gut genug ... --Leumar01 12:37, 14. Jun 2006 (CEST)

dann schlage doch TCP zur Wiederwahl vor, mit der Begründung, dass er für Laien nicht verständlich ist ... Sven-steffen arndt 14:57, 14. Jun 2006 (CEST)

ich mach das mal, da mir auch nicht klar ist, warum er exzellent ist ... Sven-steffen arndt 15:02, 14. Jun 2006 (CEST)

Ich bleibe bei Contra. Im Vergleich zu Artikeln zu anderen Protokollen wie TCP oder HTTP ist der Artikel recht schwer verständlich und Verständlichkeit ist ja auch nicht mein einziger Kritikpunkt. Saemon 12:55, 18. Jun 2006 (CEST)

• Mal eine Anmerkung zur "Laienverständlichkeit": Kriterien für lesenswerte Artikel zum Thema Fachartikel:

Ausdrücklich zugelassen sind auch: Artikel, die von der Mehrheit der Nutzer als unverständlich angesehen, aber fachlich korrekt und fundiert ein spezielles Thema behandeln.

Und das hat schon seinen Sinn, dass dies explizit so erwähnt wird. Also bitte die Kontrastimmen nochmal überdenken --Popie 15:16, 14. Jun 2006 (CEST)

• In diesem Sinne von mir ein  Pro. --Belsazar 20:07, 15. Jun 2006 (CEST)
• pro; etwas knapp, aber nur, weil auch ich mir noch ein paar "plakative Anwendungsbeispiele" gewünscht hätte, deren es meines Wissens eine Menge gibt. Ansonsten muss ich als völliger Laie sagen, dass der/die Autoren sich schon ordentlich Mühe gegeben haben, dass auch ich ihnen folgen kann. Dazu tragen die ordentliche Schreibe, das Bemühen, vom Einfachen zum Komplizierten und nicht umgekehrt zu gelangen, sowie die Illustrationen und Tabellen bei. JHeuser 18:53, 18. Jun 2006 (CEST)

• contra; es fehlt, wozu das Protokoll eigentlich genutzt wird. Nach einem Halbsatz steht die Aufzählung Überwachung von Netzwerkkomponenten, Fernsteuerung und Fernkonfiguration von Netzwerkkomponenten, Fehlererkennung und Fehlerbenachrichtigung. Das ist etwas mager und sollte dringend erweitert werden, weil es alles und gar nichts bedeuten kann. Hier fehlen konkrete Beispiele, um (nicht nur) dem fachfremden Leser deutlich zu machen, wie und dass das Protokoll tatsächlich eingesetzt wird. Für Netz- und Systemadministration ist es schon immens wichtig, wenn sie eine Mitteilung erhalten, dass das BIOS-Fehlerlog von Server XY voll ist, oder der Router A an Port n ein Problem hat. Der Schwerpunkt liegt zu sehr auf der Beschreibung der technischen Hintergründe und vernachlässigt die praktische Umsetzung. --Lyzzy 19:08, 18. Jun 2006 (CEST)

Jetzt wo die Abstimmung fast zuende ist und das Ergebnis wohl fest steht, wollte ich mich trotzdem bei allen bedanken, die mitgemacht haben und versucht haben sich in dieses, mit Sicherheit schwierige Thema, einzulesen. Das nach all der Arbeit noch nicht mal ein Lesenwert drin ist, ist natürlich deprimierend. Da ich bezweifle, das ich noch viel zu dem Artikel hinzufügen kann, werde ich hier auch nur noch wenig mitarbeiten. Das Review und diese Abstimmung, die noch mal einiges positives hier bewirkt haben waren von meiner Seite als Abschluß gedacht. Das muß aber nicht für andere gelten, die noch Dinge wissen, die ich vergessen habe. So konnte ich über die dritte Version fast nicht schreiben, da ich mich nicht mit ihr befassen musste. --Stefan2 11:35, 19. Jun 2006 (CEST)

Toter Link

Der Weblink Techniker - Projekt Umfangreiche deutschsprachige Einführung in SNMP ist wohl tot. Kennt jemand einen Ersatz? 89.52.129.18 08:22, 28. Jun 2006 (CEST)

Überarbeiten - MIB

Die Erklärung der MIB steht im Wiederspruch zu http://www.cs.uu.nl/wais/html/na-dir/snmp-faq/part2.html (2.30.01 SUBJECT: What is a MIB?) Die Erklärung dort ist sehr gut. Beim Artikel hingegen erhält man den Eindruck, dass eine MIB eine Instanz der Datenstruktur sei (also Daten selber), anstatt eine bloße Beschreibung der vorhandenen Datenstruktur eines "SNMP-Gerätes". Außerdem wäre es besser den Abschnitt eher eh komplett in Management_Information_Base einzubauen, ohne hier nur darauf zu verweisen. -- Nachtigall 21:33, 17. Sep 2006 (CEST)--Gluettge (Diskussion) 21:30, 11. Jul. 2012 (CEST) Die Erklärung der MIB ist auch in dem Sinne nicht gut, da Sie vorgaukelt, dass die Werte in einer MIB immer in einer Tabelle abgelegt werden. Das stimmt so nicht. Man unterscheidet zwischen sogenannten Skalaren, z.B. bei der Beschreibung der ifSpeed aller Interface, oder aber auch bei komplexeren Einträgen wie der ifTable, wo man die Dateien in einer Tabelle ablegt. Man muss auch darin unterscheiden, wie z.B. der OID-Baum in einem Device (Router, Switch, etc) hinterlegt ist und die zur OID dazugehörige MIB-Variable im MIB-Baum des SNMP-Agenten hinterlegt wird. Die MIB macht die als OID dargestellte Werte im SNMP-Agenten für uns Menschen lesbar. Das ist ja gerade der Sinn von den MIBs. SNMP ist das Protokoll mit dem die Informationen übermittelt werden. Die Beschreibung der MIB hat in diesem Artikel meines erachtens nichts zu suchen, sondern, hier stimme ich meinem Vorredner vollkommen zu, in einem Artikel behandelt werden.--Gluettge (Diskussion) 21:30, 11. Jul. 2012 (CEST) gluettge 21:25, 11 Jul 2012 (CEST)

Den eigenen Artikel gibt es inzwischen, Management Information Base. Ich verlinke den und werfe den hier vorhandenen Text raus. Er enthält nicht mehr als der Hauptartikel. WIr lagen vor Madagaskar (Diskussion) 01:40, 27. Jan. 2016 (CET)

Beispiel

Als Beispiel könnte man z.B. das Monitoring von Brandschutzanlagen aufführen. Ich beginne gerade mich in SNMP einzuarbeiten. Heutige Brand und Rauchmelder nutzen auch SNMP. Man kann dann z.B. mit dem OpenSource Tool Zabbix z.B. die aktuelle Temperatur auslesen und z.B. per Pager Alarm auslösen, wenn die Temperatur ein Limit erreicht hat. Solche Beispiele (Switch, Netzwerküberwachung, etc) könnten vielleicht hilfreich sein, dem Laien etwas mehr Verständnis abzugewinnen.

Ansonsten finde ich den Artikel sehr gut. Er hat mir schon geholfen, das ganze Thema etwas zu abstrahieren und zu verstehen. Gruß --skho 09:31, 8. Jan. 2007 (CET)

Zwei Fragen zu den Grafiken

Die Grafik "Das Prinzip der SNMP-Kommunikation" suggeriert, daß SNMP 6 Agenten vorgibt, von denen 5 (Agent 1-5 in der Grafik) unter der Kontrolle eines Master Agent stehen und der sechste (Agent 6) eine Sonderrolle einnimmt. Gibt SNMP das tatsächlich so vor oder ist das nur ein Beispiel?

Die Grafik "Die MIB in der Kommunikation zwischen Manager und Agenten" enthält links eine Tabelle, in der die OID einmal als Spaltenüberschrift auftaucht und einmal als Zeileneintrag. Widerspricht sich das nicht? Demnach hätte die OID selbst eine OID (hier 1.3.6.1.2.1.1.2), macht das Sinn?

-- 12:44, 09. März 2007 (MEZ)

zur zweiten Frage: Ja das ist korrekt. Im zweiten Eintrag steht die OID der Enterprise-Kennung. Hier mal ein Beispiel, mit dem ich gerade arbeite: SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.1588.2.1.1.1 Wie du erkennst, hat diese OID selbst eine OID als Wert, nämlich die Enterprise-OID, also die Stelle, ab der enterprise-Informationen des Herstellers liegen. --skho _Nachricht 13:21, 9. Mär. 2007 (CET)

Meine Grafik "Das Prinzip der SNMP-Kommunikation" stellt lediglich ein Beispiel dar, die Anzahl der Agents kann beliebig variieren... --Rene Bretz (ReneOFD) 16:02, 9. Mär. 2007 (CET)

zum SNMP#Abkürzungsverzeichnis

Hi,

ei was soll denn dieses Abkürzungsverzeichnis? Die Links auf die Akürzungen gehören selbstverständlich in den Text, die Begriffe an Ort und Stelle aufs Notwendigste erläutert (wenn dies nötig ist). Diese Tabelle ist - entschuldigung, das ist sonst gar nicht meine Art, aber hier ist es nun mal so - unnötig und sogar noch verwirrend (im ersten Moment kann man ja glatt auf die Idee kommen, es handle sich da um Zeugs, was sich aus SNMP entwickelt hat oder irgendwie damit zu tun hat - aber der direkte Kontext besteht nirgendwo).

Wenn niemand dagegenspricht, nähme ich mir das Recht heraus, diese Sache durchzuführen.

Grüße, --Benji 19:10, 23. Mai 2007 (CEST)

Hättstes mal gleich gemacht. Ich hab es jetzt gelöscht. Die Abkürzungen sind alle schon im Text verwikilinkt.--87.162.4.242 12:33, 19. Feb. 2008 (CET)

OID-Adressnotation: Konformität mit ITU-T Empfehlungen / ASN.1

 Wirklich interessant ist für SNMP nur der Unterbaum .iso.org.dod.internet (.1.3.6.1), welcher auch einfach mit „internet“ abgekürzt werden kann. Ein snmpget nach „internet.xy“ würde also denselben Wert liefern, wie ein snmpget nach „.iso.org.dod.internet.xy“ bzw. „.1.3.6.1.xy“.

Hier sind 2 Dinge anzumerken:

• 1. Die Dot-Notation kommt von der IETF und wird durch die ITU-T im ASN.1 Standard (X.660 etc) nicht anerkannt. Das Einfügen von NameForms ("iso") in die Dot-Notation ist etwas bedenklich - ich bin mir nicht sicher, ob das in einem RFC spezifiziert wurde. Die Auflösung einer solchen Adresse ist ohne ORS nicht möglich, da z.B. "dod" kein standardisierter Bezeichner ist und somit keine Übersetzung dod = 6 stattfinden kann.
• 2. Das Ersetzen von ".1.3.6.1" durch "internet" ist kein gültiger "NameForm" für die ASN.1 Notation von OIDs. Weder ISO noch ITU-T haben "1.3.6.1" eine standardisierte Name-Form (= NumberForm optional) "internet" zugewiesen und das Weglassen von ".1.3.6" ist nicht nach ASN.1 Standard möglich. (Vollständige Liste aller NameForm Standardisierungen hier: http://www.oid-info.com/name-forms.htm ). Eine ASN.1 OID der Form { iso org dod internet xy(0) } oder { internet xy(0) } wäre also in ASN.1 Modulen ungültig.

PS: Jemand sollte die Grafiken aktualisieren. CCITT ist schon lange nicht mehr der der Bezeichnet für arc 0. CCITT sollte überall durch ITU-T ersetzt werden.

--21:09, 20. Apr. 2012 (CEST) (ohne Benutzername signierter Beitrag von 87.165.188.111 (Diskussion))

Software?

Mir fehlen hier ein paar Beispiele oder Hinweise zu Software oder Tools: Was muss/kann ich installieren, um SNMP-Daten verwalten zu können? Danke. 92.106.151.60 21:53, 27. Jul. 2013 (CEST)

Bild: Das Prinzip der SNMP-Kommunikation

In der SNMP-Kommunikation gibt es keine SetResponse-"Befehl". Dies ist unlogisch, denn die GetResponse-PDU ist die Antwort auf eine Abfrage. Nachzulesen in der RFC 1157.

Grafiken: Länge/Größe der Nachrichten/VarBindings

Die Größenfelder existieren im Datenstrom nicht! Diese werden lediglich vom jeweilig genutzten Sniffing-Tool hineininterpretiert!

Paketaufbau - Abbildung "Aufbau eines SNMP-Paketes, für Nicht-Trap-Meldungen"

Nirgends im SNMP-Paket-Header ist eine "Länge der Nachricht in Byte" vorhanden, jegliche Größen von SNMP-Paketen werden von Sniffern interpretiert und sind nirgends im Datenstrom vorhanden.

Inkonsistenz bzgl "RESPONSE" vs "GET-RESPONSE"

In der Auflistung der Nachrichtentypen in "1. Funktionsweise" gibt es unter anderem den "GET-RESPONSE" Typ. In der nachfolgenden Beschreibung wird zwischen "GET-RESPONSE" und "RESPONSE" unterschieden. Letzteres fehlt aber in der Auflistung.

"PDU" nicht erklärt / verlinkt

Bei der Lektüre bin ich über die PDU gestolpert. Das Akronym wird nicht aufgelöst, auch nicht verlinkt. --217.6.96.12 08:56, 12. Mai 2023 (CEST)