Simple Network Management Protocol (SNMP) ist ein "Internetstandardprotokoll für Betriebsgeräte in IP Netzen. Geräte, die normalerweise SNMP unterstützen, schließen Router, Schalter, Server, Arbeitsplätze, Drucker, Modemgestelle, und mehr ein." Es wird größtenteils in Netzverwaltungssystemen verwendet, um netzbeigefügte Geräte für Bedingungen zu kontrollieren, die Verwaltungsaufmerksamkeit bevollmächtigen. SNMP ist ein Bestandteil des Internetprotokoll-Gefolges, wie definiert, durch Internet Engineering Task Force (IETF). Es besteht aus einer Reihe von Standards für das Netzmanagement, einschließlich eines Anwendungsschicht-Protokolls, eines Datenbankdiagramms und einer Reihe von Datengegenständen.

SNMP stellt Verwaltungsdaten in der Form von Variablen auf den geführten Systemen aus, die die Anlagenkonfiguration beschreiben. Diese Variablen können dann gefragt (und manchmal gesetzt werden) durch Betriebsanwendungen.

Übersicht und grundlegende Konzepte

Im typischen SNMP-Gebrauch, einem oder mehr Verwaltungscomputern, hat Betriebsleiter genannt, haben Sie die Aufgabe der Überwachung oder des Handhabens einer Gruppe von Gastgebern oder Geräten in einem Computernetz. Jedes geführte System führt zu jeder Zeit durch, ein Softwarebestandteil hat einen Agenten genannt, der Information über SNMP dem Betriebsleiter meldet.

Im Wesentlichen stellen SNMP Agenten Verwaltungsdaten auf den geführten Systemen als Variablen aus. Das Protokoll erlaubt auch aktive Verwaltungsaufgaben, wie das Ändern und die Verwendung einer neuen Konfiguration durch die entfernte Modifizierung dieser Variablen. Die über SNMP zugänglichen Variablen werden in Hierarchien organisiert. Diese Hierarchien und anderer metadata (wie Typ und Beschreibung der Variable), werden durch Verwaltungsinformationsbasen (MIBs) beschrieben.

Ein GeSNMP-führtes Netz besteht aus drei Schlüsselbestandteilen:

• Geführtes Gerät
• Reagenz — Software, die auf geführten Geräten läuft
• Netzverwaltungssystem (NMS) — Software, die auf dem Betriebsleiter läuft

Ein geführtes Gerät ist ein Netzknoten, der eine SNMP-Schnittstelle durchführt, die oder bidirektionalen Einrichtungs(read-Only-)-Zugang zur knotenspezifischen Information erlaubt. Geführte Geräte tauschen knotenspezifische Information mit dem NMSs aus. Manchmal genannt Netzelemente, die geführten Geräte können jeder Typ des Geräts, einschließlich, aber nicht beschränkt auf, Router, Zugriffsserver, Schalter, Brücken, Mittelpunkte, IP Telefone, IP Videokameras, Computergastgeber und Drucker sein.

Ein Agent ist ein Netzmanagement-Softwaremodul, das auf einem geführten Gerät wohnt. Ein Agent hat lokale Kenntnisse der Verwaltungsinformation und übersetzt diese Information zu oder von einer SNMP spezifischen Form.

Ein Netzverwaltungssystem (NMS) führt Anwendungen durch, die kontrollieren und geführte Geräte kontrollieren. NMSs stellen den Hauptteil der Verarbeitung und für das Netzmanagement erforderlichen Speichermittel zur Verfügung. Ein oder mehr NMSs können in jedem geführten Netz bestehen.

Verwaltungsinformationsbasis (MIB)

SNMP selbst definiert nicht, welche Information (der Variablen) ein geführtes System anbieten sollte. Eher verwendet SNMP ein ausziehbares Design, wo die verfügbare Information durch Verwaltungsinformationsbasen (MIBs) definiert wird. MIBs beschreiben die Struktur der Verwaltungsdaten eines Gerät-Subsystems; sie verwenden einen hierarchischen namespace, der Gegenstand-Bezeichner (OID) enthält. Jeder OID identifiziert eine Variable, die gelesen oder über SNMP gesetzt werden kann. MIBs verwenden die durch ASN.1 definierte Notation.

Protokoll-Details

SNMP funktioniert in der Anwendungsschicht des Internetprotokoll-Gefolges (Schicht 7 des OSI Modells). Der SNMP Agent erhält Bitten auf dem UDP Hafen 161. Der Betriebsleiter kann Bitten von jedem verfügbaren Quellhafen bis Hafen 161 im Agenten senden. Die Reagenz-Antwort wird an den Quellhafen auf dem Betriebsleiter zurückgesendet. Der Betriebsleiter erhält Ankündigungen (Fallen und InformRequests) auf dem Hafen 162. Der Agent kann Ankündigungen von jedem verfügbaren Hafen erzeugen. Wenn verwendet, mit der Transportschicht-Sicherheit oder Datenpaket-Transportschicht-Sicherheit werden Bitten auf dem Hafen 10161 erhalten, und Fallen werden gesandt, um 10162 nach Backbord zu halten..

SNMPv1 gibt fünf Kernprotokoll-Dateneinheiten (PDUs) an. Zwei andere PDUs, GetBulkRequest und InformRequest wurden in SNMPv2 hinzugefügt und zu SNMPv3 vorgetragen.

Alle SNMP PDUs werden wie folgt gebaut:

Die sieben SNMP Protokoll-Dateneinheiten (PDUs) sind wie folgt:

GetRequest

Eine Bitte des Betriebsleiters zum Agenten, den Wert einer Variable oder die Liste von Variablen wiederzubekommen. Gewünschte Variablen werden in der Variable bindings angegeben (Werte werden nicht verwendet). Die Wiederauffindung der angegebenen variablen Werte soll als eine Atomoperation vom Agenten getan werden. Eine Antwort mit aktuellen Werten wird zurückgegeben.

SetRequest

Eine Bitte des Betriebsleiters zum Agenten, den Wert einer Variable oder die Liste von Variablen zu ändern. Variable bindings wird im Körper der Bitte angegeben. Änderungen zu allen angegebenen Variablen sollen als eine Atomoperation vom Agenten vorgenommen werden. Eine Antwort mit (aktuellen) neuen Werten für die Variablen wird zurückgegeben.

GetNextRequest

Eine Bitte des Betriebsleiters zum Agenten, verfügbare Variablen und ihre Werte zu entdecken. Gibt eine Antwort mit der variablen Schwergängigkeit für die lexikografisch folgende Variable in der MIB zurück. Die komplette MIB eines Agenten kann durch die wiederholende Anwendung von GetNextRequest spazieren gegangen werden, der an OID 0 anfängt. Reihen eines Tisches können durch das Spezifizieren der Säule OIDs in der Variable bindings der Bitte gelesen werden.

GetBulkRequest

Optimierte Version von GetNextRequest. Eine Bitte des Betriebsleiters zum Agenten um vielfache Wiederholungen von GetNextRequest. Kehrt zurück eine Antwort mit der vielfachen Variable ist bindings von der variablen Schwergängigkeit oder bindings in der Bitte spazieren gegangen. PDU spezifische Nichtwiederholende und Max-Wiederholungsfelder werden verwendet, um Ansprechverhalten zu kontrollieren. GetBulkRequest wurde in SNMPv2 eingeführt.

Antwort

Rückvariable bindings und Anerkennung von Reagenz dem Betriebsleiter für GetRequest, SetRequest, GetNextRequest, GetBulkRequest und InformRequest. Fehlerbericht wird durch den Fehlerstatus und die Fehlerindex-Felder zur Verfügung gestellt. Obwohl es als eine Antwort sowohl auf verwendet wurde kommt als auch untergeht, wurde dieser PDU GetResponse in SNMPv1 genannt.

Falle

Asynchrone Ankündigung von Reagenz dem Betriebsleiter. Schließt Strom sysUpTime Wert, ein OID das Identifizieren des Typs der Falle und fakultativen Variable bindings ein. Das Bestimmungsort-Wenden für Fallen wird auf eine anwendungsspezifische Weise normalerweise durch Falle-Konfigurationsvariablen in der MIB bestimmt. Das Format der Falle-Nachricht wurde in SNMPv2 geändert, und der PDU wurde SNMPv2-Falle umbenannt.

InformRequest

Der anerkannte asynchrone Ankündigungsbetriebsleiter dem Betriebsleiter oder Agenten dem Betriebsleiter. Betriebsleiter-zu-Betriebsleiter-Ankündigungen waren bereits in SNMPv1 möglich (eine Falle verwendend), aber weil SNMP allgemein UDP durchgeht, wo Übergabe nicht gesichert wird und fallen gelassene Pakete nicht berichtet werden, wurde die Übergabe einer Falle nicht versichert. InformRequest befestigt das durch das Zurücksenden einer Anerkennung nach Empfang. Empfänger antwortet mit der Antwort, die die ganze Information in InformRequest nachplappert. Dieser PDU wurde in SNMPv2 eingeführt.

Entwicklung und Gebrauch

Version 1

SNMP Version 1 (SNMPv1) ist die anfängliche Durchführung des SNMP Protokolls. SNMPv1 funktioniert über Protokolle wie User Datagram Protocxol (UDP), Internet Protocol (IP), OSI Connectionless Netzdienst (CLNS), AppleTalk Datagram-Delivery Protocol (DDP) und Novell Internetpaketaustausch (IPX). SNMPv1 wird weit verwendet und ist das De-Facto-Netzmanagement-Protokoll in der Internetgemeinschaft.

Der erste RFCuovs für SNMP, jetzt bekannt als SNMPv1, ist 1988 erschienen:

• RFC 1065 — Struktur und Identifizierung der Verwaltungsinformation für das TCP/IP-based Internet
• RFC 1066 — Verwaltungsinformation stützen für das Netzmanagement des TCP/IP-based Internets
• RFC 1067 — Ein einfaches Netzverwaltungsprotokoll

Diese Protokolle waren obsoleted durch:

• RFC 1155 — Struktur und Identifizierung der Verwaltungsinformation für das TCP/IP-based Internet
• RFC 1156 — Verwaltungsinformation stützen für das Netzmanagement des TCP/IP-based Internets
• RFC 1157 — Ein einfaches Netzverwaltungsprotokoll

Nach einer kurzen Zeit RFC wurde 1156 (MIB 1) durch öfter verwendeten ersetzt:

• RFC 1213 — Version 2 der Verwaltungsinformationsbasis (MIB 2) für das Netzmanagement des TCP/IP-based Internets

Version 1 ist für seine schlechte Sicherheit kritisiert worden. Die Beglaubigung von Kunden wird nur durch eine "Gemeinschaftsschnur", tatsächlich ein Typ des Kennwortes durchgeführt, das im Klartext übersandt wird. Das Design der 80er Jahre von SNMP V1 wurde von einer Gruppe von Mitarbeitern getan, die den offiziell gesponserten OSI/IETF/NSF (Nationales Wissenschaftsfundament) Anstrengung (HEMS/CMIS/CMIP) als beide unimplementable in den Rechenplattformen der Zeit sowie potenziell unausführbar angesehen haben. SNMP wurde gestützt auf einem Glauben genehmigt, dass es ein Zwischenprotokoll war, das erforderlich ist, um zur in großem Umfang Aufstellung des Internets und seiner Kommerzialisierung Schritte zu unternehmen. In diesem Zeitabschnitt war Internetstandard-Beglaubigung/Sicherheit beide ein Traum und hat durch eingestellte Protokoll-Designgruppen entmutigt.

Version 2

SNMPv2 (RFC 1441-RFC 1452), revidiert Version 1 und schließt Verbesserungen in den Gebieten von Leistung, Sicherheit, Vertraulichkeit und Betriebsleiter-zu-Betriebsleiter-Kommunikationen ein. Es hat GetBulkRequest, eine Alternative zu wiederholendem GetNextRequests eingeführt, um große Beträge von Verwaltungsdaten in einer einzelnen Bitte wiederzubekommen. Jedoch wurde das neue parteibasierte Sicherheitssystem in SNMPv2, der von vielen als angesehen ist, allzu kompliziert, nicht weit akzeptiert.

Gemeinschaftsbasierte Einfache Netzverwaltungsprotokoll-Version 2 oder SNMPv2c, wird RFC 1901-RFC 1908 definiert. In seinen anfänglichen Stufen war das auch als SNMPv1.5 informell bekannt. SNMPv2c umfasst SNMPv2 ohne den umstrittenen neuen SNMP v2 Sicherheitsmodell, mit stattdessen das einfache gemeinschaftsbasierte Sicherheitsschema von SNMPv1. Während offiziell nur ein "Draftstandard", das als der SNMPv2 De-Facto-Standard weit betrachtet wird.

Benutzerbasierte Einfache Netzverwaltungsprotokoll-Version 2 oder SNMPv2u, wird RFC 1909-RFC 1910 definiert. Das ist ein Kompromiss, der versucht, größere Sicherheit anzubieten als SNMPv1, aber ohne die hohe Kompliziertheit von SNMPv2 zu übernehmen. Eine Variante davon wurde als SNMP v2 * kommerzialisiert, und der Mechanismus wurde schließlich als eines von zwei Sicherheitsfachwerk in SNMP v3 angenommen.

SNMPv1 & SNMPv2c Zwischenfunktionsfähigkeit

Wie jetzt angegeben, ist SNMPv2 mit SNMPv1 in zwei Schlüsselgebieten unvereinbar: Nachrichtenformate und Protokoll-Operationen. SNMPv2c Nachrichten verwenden verschiedenen Kopfball und Formate der Protokoll-Dateneinheit (PDU) aus SNMPv1 Nachrichten. SNMPv2c verwendet auch zwei Protokoll-Operationen, die in SNMPv1 nicht angegeben werden. Außerdem definiert RFC 2576 zwei mögliche SNMPv1/v2c Koexistenz-Strategien: Proxyagenten und zweisprachige Netzmanagement-Systeme.

Proxyagenten

Ein SNMPv2 Agent kann als ein Proxyagent im Auftrag geführter Geräte von SNMPv1 wie folgt handeln:

• Ein SNMPv2 NMS gibt einen für einen SNMPv1 Agenten beabsichtigten Befehl aus.
• Der NMS sendet die SNMP Nachricht dem SNMPv2 Proxyagenten.
• Der Proxyagent vorwärts, und die Nachrichten an den SNMPv1 unveränderten Agenten.
• Nachrichten von GetBulk werden vom Proxyagenten zu Nachrichten umgewandelt und werden dann zum SNMPv1 Agenten nachgeschickt.

Der Proxyagent stellt SNMPv1-Falle-Nachrichten an SNMPv2-Falle-Nachrichten und dann vorwärts sie zum NMS kartografisch dar.

Zweisprachiges Netzmanagement-System

Zweisprachige SNMPv2 Netzmanagement-Systeme unterstützen sowohl SNMPv1 als auch SNMPv2. Um diese Doppelmanagement-Umgebung zu unterstützen, muss sich eine Verwaltungsanwendung im zweisprachigen NMS mit einem Agenten in Verbindung setzen. Der NMS untersucht dann in einer lokalen Datenbank versorgte Information, um zu bestimmen, ob der Agent SNMPv1 oder SNMPv2 unterstützt. Gestützt auf der Information in der Datenbank kommuniziert der NMS mit dem Agenten, der die passende Version von SNMP verwendet.

Version 3

Obwohl SNMPv3 keine Änderungen mit dem Protokoll beiseite von der Hinzufügung der kryptografischen Sicherheit vornimmt, sieht es viel verschieden wegen der neuen Textvereinbarung, Konzepte und Fachsprache aus.

SNMPv3 hat in erster Linie Sicherheit und entfernte Konfigurationserhöhungen zu SNMP hinzugefügt.

Sicherheit ist die größte Schwäche von SNMP seit dem Anfang gewesen. Die Beglaubigung in SNMP Versionen 1 und 2 beläuft sich auf nichts anderes, als ein Kennwort (Gemeinschaftsschnur) hat klaren Text zwischen einem Betriebsleiter und Agenten eingesendet. Jede SNMPv3 Nachricht enthält Sicherheitsrahmen, die als eine Oktett-Schnur verschlüsselt werden. Die Bedeutung dieser Sicherheitsrahmen hängt vom Sicherheitsmodell ab, das wird verwendet.

SNMPv3 stellt wichtige Sicherheitseigenschaften zur Verfügung:

• Vertraulichkeit - Verschlüsselung von Paketen, um zu verhindern, durch eine nicht bevollmächtigte Quelle herumzuschnüffeln.
• Integrität - Nachrichtenintegrität, um sicherzustellen, dass an einem Paket in der Durchfahrt einschließlich eines fakultativen Paket-Wiederholungsspiel-Schutzmechanismus nicht herumgebastelt worden ist.
• Beglaubigung - um nachzuprüfen, dass die Nachricht von einer gültigen Quelle ist.

der IETF erkennt Einfache Netzverwaltungsprotokoll-Version 3, wie definiert, durch RFC 3411-RFC 3418 (auch bekannt als STD0062) als die aktuelle Standardversion von SNMP an. Der IETF hat SNMPv3 ein voller Internetstandard, das höchste Reife-Niveau für einen RFC benannt. Es denkt, dass frühere Versionen (Kennzeichnung von ihnen "Historisch") veraltet sind.

In der Praxis unterstützen SNMP Durchführungen häufig vielfache Versionen: normalerweise SNMPv1, SNMPv2c und SNMPv3.

Durchführungsprobleme

SNMP Durchführungen ändern sich über Plattform-Verkäufer. In einigen Fällen ist SNMP ein Komfortmerkmal, und wird ernstlich genug nicht genommen, um ein Element des Kerndesigns zu sein. Einige Hauptausrüstungsverkäufer neigen dazu, ihre Befehl-Linieneigentumsschnittstelle (CLI) zentrische Konfiguration und Regelsysteme zu übererweitern.

Die anscheinend einfache Baumstruktur von SNMP und das geradlinige Indexieren dürfen ganz gut innerhalb der inneren Datenstrukturen nicht immer verstanden werden, die Elemente eines grundlegenden Designs einer Plattform sind. Infolgedessen kann die Verarbeitung von SNMP Abfragen auf bestimmten Dateien auf höhere Zentraleinheitsanwendung hinauslaufen als notwendig. Ein Beispiel davon würde große Routenplanungstische, wie BGP oder IGP sein.

Das Quellenindexieren

Modulgeräte können dynamisch vergrößern oder ihre SNMP Indizes vermindern (auch bekannt als Beispiele), wann auch immer Schlitzhardware hinzugefügt oder entfernt wird. Obwohl das mit der Hardware am üblichsten ist, haben virtuelle Schnittstellen dieselbe Wirkung. Index-Werte werden normalerweise in der Ladezeit zugeteilt und bleiben fest bis zum folgenden Neustart. Hardware oder virtuelle Entitäten haben beigetragen, während das Gerät 'lebend' ist, kann ihre Indizes am Ende der vorhandenen Reihe und vielleicht wiederzugeteilt am folgenden Neustart zuteilen lassen. Netzwarenbestand und Mithörwerkzeuge müssen die Gerät-Aktualisierungsfähigkeit durch das richtige Reagieren auf die kalte Anfang-Falle vom Gerät-Neustart haben, um Bestechung und Fehlanpassung von befragten Daten zu vermeiden.

Index-Anweisungen für ein SNMP Gerät-Beispiel können sich von der Wahl bis Wahl größtenteils infolge Änderungen ändern, die durch das System admin begonnen sind. Wenn Information für eine besondere Schnittstelle erforderlich ist, ist es befehlend, den SNMP Index vor dem Wiederbekommen der erforderlichen Daten zu bestimmen. Allgemein wird ein Beschreibungstisch wie ifDescr einen benutzerfreundlichen Namen wie Serien-0/1 (Klinge 0, Hafen 1) zu einem SNMP Index kartografisch darstellen.

Sicherheitsimplikationen

• SNMP Versionen 1 und 2c sind dem Paket-Schnüffeln der klaren Textgemeinschaftsschnur vom Netzverkehr unterworfen, weil sie Verschlüsselung nicht durchführen.
• Alle Versionen von SNMP sind der rohen Gewalt und den Wörterbuch-Angriffen unterworfen, für die Gemeinschaftsschnuren, Beglaubigungsschnuren, Beglaubigungsschlüssel, Verschlüsselungsschnuren oder Verschlüsselungsschlüssel zu erraten, weil sie keinen Herausforderungsantwort-Händedruck durchführen.
• Obwohl SNMP über TCP und andere Protokolle arbeitet, wird es meistens über UDP verwendet, der connectionless und verwundbar für IP Manipulationsangriffe ist. So sind alle Versionen dem Umleiten von Gerät-Zugriffslisten unterworfen, die durchgeführt worden sein könnten, um SNMP Zugang zu beschränken, obwohl SNMPv3's andere Sicherheitsmechanismen einen erfolgreichen Angriff verhindern sollte.
• Die starke Konfiguration von SNMP (schreibt), dass Fähigkeiten von vielen Verkäufern teilweise wegen eines Mangels an der Sicherheit in SNMP Versionen vor SNMPv3 und teilweise nicht völlig verwertet werden, weil viele Geräte einfach dazu nicht fähig sind, über individuelle MIB-Gegenstand-Änderungen konfiguriert zu werden.
• SNMP übersteigt die Liste der Allgemeinen Verzug-Konfigurationsprobleme des OHNE Instituts mit dem Problem des Verzugs SNMP Gemeinschaftsschnur-Satz zum 'öffentlichen' und 'privaten' und war Nummer zehn auf der OHNE 10 ersten Kritischsten Internetsicherheit Drohungen für das Jahr 2000.

Autoentdeckung

SNMP ist allein einfach ein Protokoll, um Information zu sammeln und zu organisieren. Die meisten toolsets, die SNMP durchführen, bieten eine Form des Entdeckungsmechanismus, eine standardisierte Datenerfassung an, die für die meisten Plattformen und Geräte üblich ist, um einen neuen Benutzer zu bekommen, oder implementor hat angefangen. Eine dieser Eigenschaften ist häufig eine Form der automatischen Entdeckung, wo neue im Netz entdeckte Geräte automatisch befragt werden. Für SNMPv1 und SNMPv2c präsentiert das ein Sicherheitsrisiko, in dem gelesenen Gemeinschaften Ihres SNMP im Klartext zum Zielgerät übertragen werden. Während sich Sicherheitsvoraussetzungen und Risikoprofile von der Organisation bis Organisation ändern, sollte Sorge genommen werden, wenn man eine Eigenschaft wie das, mit der speziellen Rücksicht auf allgemeine Umgebungen wie Mischmieter datacenters, Server-Bewirtung und colocation Möglichkeiten und ähnliche Umgebungen verwendet.

RFC Verweisungen

• RFC 1155 (STD 16) — Struktur und Identifizierung der Verwaltungsinformation für das TCP/IP-based Internet
• RFC 1156 (Historisch) — Verwaltungsinformationsbasis für das Netzmanagement des TCP/IP-based Internets
• RFC 1157 (Historisch) — Simple Network Management Protocol (SNMP)
• RFC 1213 (STD 17) — Verwaltungsinformationsbasis für das Netzmanagement des TCP/IP-based Internets: MIB-II
• RFC 1452 (Informations-) — Koexistenz zwischen Version 1 und Version 2 des Internetstandardnetzverwaltungsfachwerks (Obsoleted vor RFC 1908)
• RFC 1901 (Experimentell) — Einführung in Gemeinschaftsbasierten SNMPv2
• RFC 1902 (Draftstandard) — Struktur der Verwaltungsinformation für SNMPv2 (Obsoleted durch RFC 2578)
• RFC 1908 (Standardspur) — Koexistenz zwischen Version 1 und Version 2 des Internetstandardnetzverwaltungsfachwerks
• RFC 2570 (Informations-) — Einführung in die Version 3 des Internetstandardnetzverwaltungsfachwerks (Obsoleted durch RFC 3410)
• RFC 2578 (STD 58) — Struktur der Verwaltungsinformationsversion 2 (SMIv2)
• RFC 3410 (Informations-) — Einführung und Anwendbarkeitsbehauptungen für das Internetstandardverwaltungsfachwerk
• STD 62
• RFC 3411 — Eine Architektur für das Beschreiben des Verwaltungsfachwerks von Simple Network Management Protocol (SNMP)
• RFC 3412 — Nachrichtenverarbeitung und das Verschicken für Simple Network Management Protocol (SNMP)
• RFC 3413 — Anwendungen von Simple Network Management Protocol (SNMP)
• RFC 3414 — User-based Security Model (USM) für die Version 3 des Einfachen Netzverwaltungsprotokolls (SNMPv3)
• RFC 3415 — View-based Access Control Model (VACM) für Simple Network Management Protocol (SNMP)
• RFC 3416 — Version 2 der Protokoll-Operationen wegen Simple Network Management Protocol (SNMP)
• RFC 3417 — Transportmappings für Simple Network Management Protocol (SNMP)
• RFC 3418 — Management Information Base (MIB) für Simple Network Management Protocol (SNMP)
• RFC 3430 (Experimentell) — Simple Network Management Protocol (SNMP) über den Transport von Transmission Control Protocol (TCP), der Kartografisch darstellt
• RFC 3584 (BCP 74) — Koexistenz zwischen der Version 1, Version 2 und Version 3 des Internetstandardnetzverwaltungsfachwerks
• RFC 3826 (Vorgeschlagen) — Der Ziffer-Algorithmus von Advanced Encryption Standard (AES) im SNMP Benutzerbasiertes Sicherheitsmodell
• RFC 5343 (Vorgeschlagen) — Zusammenhang von Simple Network Management Protocol (SNMP) Entdeckung von EngineID
• RFC 5590 (Entwurf) — Transportsubsystem für Simple Network Management Protocol (SNMP)
• RFC 5591 (Entwurf) — Transportsicherheit Modell für Simple Network Management Protocol (SNMP)
• RFC 5592 (Vorgeschlagen) — Sichern Transportmodell von Shell für Simple Network Management Protocol (SNMP)
• RFC 5608 (Vorgeschlagen) — Entferntes Beglaubigungszifferblatt - im Benutzerdienst (RADIUS) Gebrauch für Transportmodelle von Simple Network Management Protocol (SNMP).
• RFC 6353 (Entwurf) — Transportmodell von Transport Layer Security (TLS) für Simple Network Management Protocol (SNMP)

Siehe auch

• AgentX, ein Untervertreter-Protokoll für SNMP
• CMIP über TCP/IP (CMOT)
• Allgemeines Verwaltungsinformationsprotokoll (CMIP), ein Verwaltungsprotokoll durch ISO/OSI, der durch Fernmeldegeräte verwendet ist
• Allgemeiner Verwaltungsinformationsdienst (CMIS)
• IEC 62379
• Verwaltungsinformationsbasis (MIB)
• Netz-SNMP, eine offene Quellbezugsdurchführung von SNMP
• Netconf, ein Protokoll, das ein XML-basiertes Konfigurationsprotokoll für die Netzausrüstung ist
• Netzmithörvergleich
• Gegenstand-Bezeichner (OID)
• Entfernte Überwachung (RMON)
• Simple Gateway Monitoring Protocol (SGMP), ein veraltetes Protokoll, das durch SNMP ersetzt ist
• SNMP Simulator

Links

• SNMP Portal
• SNMP, der Startpunkt und Verweisung Programmiert
• SNMP Produkte und technische Artikel
• Die Beschreibung von Cisco von SNMP, und wie man in ihren Produkten verwendet
• SNMP: Einfach? Netzverwaltungsprotokoll
• Suchen Sie Motor für MIB-Dateien
• Emnico SNMP MIB-Bibliothek: Eine Sammlung von SNMP MIBs
• SNMP v1, v2, und v3 Nachrichtenprotokoll Handliche Verweisung (pdf) (geschaffen von einem älteren Satz von RFCs)