3. The SNMP Architecture
Der SNMP-Architektur ist implizit eine Menge von Network-Management-Stationen und Netzwerkelementen zugrunde gelegt. Network-Management-Stationen führen Management-Anwendungen aus, die Netzwerkelemente überwachen und steuern. Netzwerkelemente sind Geräte wie Hosts, Gateways, Terminal-Server und ähnliche, die Management-Agenten besitzen, welche die vom Management-Stationen angeforderten Netzwerkmanagement-Funktionen ausführen. Das Simple Network Management Protocol (SNMP) wird verwendet, um Management-Informationen zwischen den Management-Stationen und den Agenten in den Netzwerkelementen auszutauschen.
3.1 Goals of the Architecture
Die SNMP minimiert explizit die Anzahl und Komplexität der vom Management-Agenten selbst realisierten Management-Funktionen. Dieses Ziel ist in mindestens vier Hinsichten attraktiv:
-
Die Entwicklungskosten für die zur Unterstützung des Protokolls nötige Management-Agenten-Software werden entsprechend reduziert.
-
Der Grad der fernunterstützten Management-Funktionen wird entsprechend erhöht und damit die volle Nutzung der Internet-Ressourcen bei der Management-Aufgabe ermöglicht.
-
Der Grad der fernunterstützten Management-Funktionen wird entsprechend erhöht und damit dem Form und der Raffinesse der Management-Werkzeuge möglichst wenig Einschränkungen auferlegt.
-
Vereinfachte Mengen von Management-Funktionen sind für Entwickler von Network-Management-Werkzeugen leicht zu verstehen und zu verwenden.
Ein zweites Ziel des Protokolls ist es, dass das funktionale Paradigma für Überwachung und Steuerung hinreichend erweiterbar ist, um zusätzliche, möglicherweise unvorhergesehene Aspekte des Netzbetriebs und -managements aufzunehmen.
Ein drittes Ziel ist es, dass die Architektur soweit wie möglich unabhängig von der Architektur und den Mechanismen bestimmter Hosts oder bestimmter Gateways ist.
3.2 Elements of the Architecture
Die SNMP-Architektur beschreibt eine Lösung für das Network-Management-Problem im Hinblick auf:
-
den Umfang der vom Protokoll kommunizierten Management-Information,
-
die Darstellung der vom Protokoll kommunizierten Management-Information,
-
die am Protokoll unterstützten Operationen auf Management-Information,
-
die Form und Bedeutung des Austauschs zwischen Management-Entitäten,
-
die Definition administrativer Beziehungen zwischen Management-Entitäten und
-
die Form und Bedeutung von Referenzen auf Management-Information.
3.2.1 Scope of Management Information
Der Umfang der durch den Betrieb von SNMP kommunizierten Management-Information ist genau der, der durch Instanzen aller nicht-aggregierenden Objekttypen dargestellt wird, die entweder im Internet-Standard-MIB definiert sind oder an anderer Stelle gemäß den in der Internet-Standard-SMI [5] festgelegten Konventionen definiert sind.
Die Unterstützung aggregierender Objekttypen in der MIB ist weder für die Konformität mit der SMI noch durch SNMP realisiert.
3.2.2 Representation of Management Information
Die durch den Betrieb von SNMP kommunizierte Management-Information wird gemäß der in der SMI für die Definition nicht-aggregierender Typen spezifizierten Teilmenge der ASN.1-Sprache [9] dargestellt.
Das SGMP übernahm die Konvention, eine wohldefinierte Teilmenge der ASN.1-Sprache [9] zu verwenden. SNMP setzt diese Tradition fort und erweitert sie, indem es eine moderat komplexere Teilmenge von ASN.1 zur Beschreibung verwalteter Objekte und der zum Verwalten dieser Objekte verwendeten Protokolldateneinheiten nutzt. Zudem führte das Bestreben, den späteren Übergang zu OSI-basierten Network-Management-Protokollen zu erleichtern, zur Definition einer Internet-Standard Structure of Management Information (SMI) [5] und Management Information Base (MIB) [6] in der ASN.1-Sprache. Die Verwendung von ASN.1 wurde unter anderem durch den erfolgreichen Einsatz von ASN.1 in früheren Bemühungen, insbesondere dem SGMP, gefördert. Die Einschränkungen bei der Verwendung von ASN.1, die Teil der SMI sind, tragen zur Einfachheit bei, die durch die Erfahrung mit dem SGMP bestätigt wurde.
Ebenfalls der Einfachheit halber verwendet SNMP nur eine Teilmenge der Basic Encoding Rules von ASN.1 [10]. Insbesondere verwenden alle Kodierungen die Form mit bestimmter Länge. Ferner werden, wo immer zulässig, Nicht-Konstruktor-Kodierungen anstelle von Konstruktor-Kodierungen verwendet. Diese Einschränkung gilt für alle Aspekte der ASN.1-Kodierung, sowohl für die Protokolldateneinheiten auf oberster Ebene als auch für die darin enthaltenen Datenobjekte.
3.2.3 Operations Supported on Management Information
Das SNMP modelliert alle Management-Agenten-Funktionen als Änderungen oder Prüfungen von Variablen. Folglich interagiert eine Protokollentität auf einem logisch entfernten Host (möglicherweise dem Netzwerkelement selbst) mit dem auf dem Netzwerkelement residerenden Management-Agenten, um Variablen abzurufen (get) oder zu ändern (set). Diese Strategie hat mindestens zwei positive Konsequenzen:
-
Sie bewirkt, dass die Anzahl der vom Management-Agenten realisierten wesentlichen Management-Funktionen auf zwei begrenzt wird: einen Operator zum Zuweisen eines Werts an einen angegebenen Konfigurations- oder anderen Parameter und einen zum Abrufen eines solchen Werts.
-
Eine weitere Wirkung dieser Entscheidung ist, dass die Aufnahme von imperativen Management-Befehlen in die Protokolldefinition vermieden wird: die Anzahl solcher Befehle wächst in der Praxis ständig, und ihre Semantik ist im Allgemeinen beliebig komplex.
Die im SNMP implizite Strategie besteht darin, dass die Überwachung des Netzzustands in nennenswertem Detailgrad primär durch Abfragen (Polling) nach entsprechenden Informationen seitens der Überwachungszentrale(n) erfolgt. Eine begrenzte Anzahl unaufgeforderter Nachrichten (Traps) lenkt den Zeitpunkt und Fokus des Pollings. Die Begrenzung der Anzahl unaufgeforderter Nachrichten steht im Einklang mit dem Ziel der Einfachheit und der Minimierung des durch die Network-Management-Funktion erzeugten Verkehrs.
Der Ausschluss imperativer Befehle aus der Menge der explizit unterstützten Management-Funktionen schließt kaum eine wünschenswerte Management-Agenten-Operation aus. Gegenwärtig sind die meisten Befehle entweder Anfragen, einen Parameterwert zu setzen, oder einen solchen abzurufen, und die Funktion der wenigen gegenwärtig unterstützten imperativen Befehle wird in diesem Management-Modell leicht asynchron aufgenommen. In diesem Schema ließe sich ein imperativer Befehl als Setzen eines Parameterwerts realisieren, der nachfolgend die gewünschte Aktion auslöst. Anstatt etwa einen „Reboot-Befehl" zu implementieren, könnte diese Aktion etwa durch Setzen eines Parameters, der die Sekunden bis zum Systemneustart angibt, aufgerufen werden.
3.2.4 Form and Meaning of Protocol Exchanges
Die Kommunikation von Management-Informationen zwischen Management-Entitäten wird in SNMP durch den Austausch von Protokollnachrichten realisiert. Die Form und Bedeutung dieser Nachrichten ist in Abschnitt 4 unten definiert.
Im Einklang mit dem Ziel, die Komplexität des Management-Agenten zu minimieren, erfordert der Austausch von SNMP-Nachrichten nur einen unzuverlässigen Datagramm-Dienst, und jede Nachricht wird vollständig und unabhängig durch ein einzelnes Transport-Datagramm dargestellt. Während dieses Dokument den Austausch von Nachrichten über das UDP-Protokoll [11] spezifiziert, sind die Mechanismen von SNMP allgemein für die Verwendung mit einer Vielzahl von Transportdiensten geeignet.
3.2.5 Definition of Administrative Relationships
Die SNMP-Architektur lässt eine Vielzahl administrativer Beziehungen zwischen Entitäten zu, die am Protokoll teilnehmen. Die auf Management-Stationen und Netzwerkelementen residerenden Entitäten, die über SNMP miteinander kommunizieren, werden als SNMP-Anwendungsentitäten bezeichnet. Die Peer-Prozesse, die SNMP implementieren und damit die SNMP-Anwendungsentitäten unterstützen, werden als Protokollentitäten bezeichnet.
Eine Paarung eines SNMP-Agenten mit einer beliebigen Menge von SNMP-Anwendungsentitäten wird als SNMP-Community bezeichnet. Jede SNMP-Community wird durch eine Oktettkette benannt, die als Community-Name dieser Community bezeichnet wird.
Eine von einer SNMP-Anwendungsentität stammende SNMP-Nachricht, die tatsächlich zur SNMP-Community gehört, die durch die Community-Komponente dieser Nachricht benannt wird, wird als authentische SNMP-Nachricht bezeichnet. Die Menge der Regeln, durch die eine SNMP-Nachricht als authentische SNMP-Nachricht für eine bestimmte SNMP-Community identifiziert wird, wird als Authentifizierungsschema bezeichnet. Eine Implementierung einer Funktion, die authentische SNMP-Nachrichten gemäß einem oder mehreren Authentifizierungsschemas identifiziert, wird als Authentifizierungsdienst bezeichnet.
Klar ist, dass die effektive Verwaltung administrativer Beziehungen zwischen SNMP-Anwendungsentitäten Authentifizierungsdienste erfordert, die (durch Verschlüsselung oder andere Techniken) authentische SNMP-Nachrichten mit hoher Sicherheit identifizieren können. Einige SNMP-Implementierungen möchten möglicherweise nur einen trivialen Authentifizierungsdienst unterstützen, der alle SNMP-Nachrichten als authentische SNMP-Nachrichten identifiziert.
Für jedes Netzwerkelement wird eine Teilmenge der Objekte in der MIB, die zu diesem Element gehören, als SNMP-MIB-Sicht (MIB view) bezeichnet. Die Namen der in einer SNMP-MIB-Sicht dargestellten Objekttypen müssen nicht zu einem einzelnen Teilbaum des Namensraums der Objekttypen gehören.
Ein Element der Menge { READ-ONLY, READ-WRITE } wird als SNMP-Zugriffsmodus (access mode) bezeichnet.
Eine Paarung eines SNMP-Zugriffsmodus mit einer SNMP-MIB-Sicht wird als SNMP-Community-Profil (community profile) bezeichnet. Ein SNMP-Community-Profil stellt angegebene Zugriffsrechte auf Variablen in einer angegebenen MIB-Sicht dar. Für jede Variable in der MIB-Sicht in einem gegebenen SNMP-Community-Profil wird der Zugriff auf diese Variable durch das Profil gemäß den folgenden Konventionen dargestellt:
-
Ist die Variable im MIB mit „Access:" von „none" definiert, so ist sie als Operand für keinen Operator verfügbar;
-
ist die Variable im MIB mit „Access:" von „read-write" oder „write-only" definiert und ist der Zugriffsmodus des gegebenen Profils READ-WRITE, so ist die Variable als Operand für die Operationen get, set und trap verfügbar;
-
andernfalls ist die Variable als Operand für die Operationen get und trap verfügbar.
-
In den Fällen, in denen eine „write-only"-Variable als Operand für die Operationen get oder trap verwendet wird, ist der für die Variable angegebene Wert implementierungsspezifisch.
Eine Paarung einer SNMP-Community mit einem SNMP-Community-Profil wird als SNMP-Zugriffsrichtlinie (access policy) bezeichnet. Eine Zugriffsrichtlinie stellt ein angegebenes Community-Profil dar, das der SNMP-Agent einer angegebenen SNMP-Community anderen Mitgliedern dieser Community gewährt. Alle administrativen Beziehungen zwischen SNMP-Anwendungsentitäten sind architektonisch in Bezug auf SNMP-Zugriffsrichtlinien definiert.
Für jede SNMP-Zugriffsrichtlinie gilt: Wenn das Netzwerkelement, auf dem der SNMP-Agent für die angegebene SNMP-Community residiert, nicht dasjenige ist, auf das sich die MIB-Sicht für das angegebene Profil bezieht, so wird diese Richtlinie als SNMP-Proxy-Zugriffsrichtlinie bezeichnet. Der mit einer Proxy-Zugriffsrichtlinie verbundene SNMP-Agent wird als SNMP-Proxy-Agent bezeichnet. Während die unvorsichtige Definition von Proxy-Zugriffsrichtlinien zu Management-Schleifen führen kann, ist die umsichtige Definition von Proxy-Richtlinien in mindestens zweierlei Hinsicht nützlich:
-
Sie ermöglicht die Überwachung und Steuerung von Netzwerkelementen, die andernfalls mit dem Management-Protokoll und dem Transport-Protokoll nicht adressierbar sind. Ein Proxy-Agent kann also eine Protokollumsetzungsfunktion bereitstellen, die es einer Management-Station erlaubt, einen einheitlichen Management-Rahmen auf alle Netzwerkelemente anzuwenden, einschließlich Geräten wie Modems, Multiplexern und anderen Geräten, die andere Management-Rahmen unterstützen.
-
Sie kann Netzwerkelemente potenziell vor aufwendigen Zugriffskontrollrichtlinien abschirmen. Ein Proxy-Agent kann beispielsweise eine ausgefeilte Zugriffskontrolle implementieren, durch die unterschiedliche Teilmengen von Variablen innerhalb der MIB verschiedenen Management-Stationen zugänglich gemacht werden, ohne die Komplexität des Netzwerkelements zu erhöhen.
Als Beispiel veranschaulicht Abbildung 1 die Beziehung zwischen Management-Stationen, Proxy-Agenten und Management-Agenten. In diesem Beispiel ist der Proxy-Agent als ein normales Internet Network Operations Center (INOC) einer administrativen Domäne vorgesehen, das eine Standard-Management-Beziehung zu einer Menge von Management-Agenten hat.
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
|PCommunity=pub, |
| slate |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+
Domain: die administrative Domäne des Elements PCommunity: der Name einer Community, die einen Proxy-Agenten nutzt DCommunity: der Name einer direkten Community
Figure 1 Example Network Management Configuration
3.2.6 Form and Meaning of References to Managed Objects
Die SMI verlangt, dass die Definition eines konformen Management-Protokolls Folgendes adressiert:
-
die Auflösung mehrdeutiger MIB-Referenzen,
-
die Auflösung von MIB-Referenzen bei Vorliegen mehrerer MIB-Versionen und
-
die Identifikation bestimmter Instanzen von in der MIB definierter Objekttypen.
3.2.6.1 Resolution of Ambiguous MIB References
Da der Umfang jeder SNMP-Operation konzeptuell auf Objekte beschränkt ist, die für ein einzelnes Netzwerkelement relevant sind, und da alle SNMP-Referenzen auf MIB-Objekte (implizit oder explizit) über eindeutige Variablennamen erfolgen, besteht keine Möglichkeit, dass eine SNMP-Referenz auf einen in der MIB definierten Objekttyp zu mehreren Instanzen dieses Typs auflöst.
3.2.6.2 Resolution of References across MIB Versions
Die durch eine SNMP-Operation referenzierte Objektinstanz ist genau die, die als Teil der Operationsanforderung angegeben ist oder (im Fall einer get-next-Operation) deren unmittelbare Nachfolger in der MIB insgesamt. Insbesondere löst eine Referenz auf ein Objekt als Teil einer Version des Internet-Standard-MIB nicht auf ein Objekt auf, das nicht Teil dieser Version des Internet-Standard-MIB ist, außer im Fall, dass die angeforderte Operation get-next ist und der angegebene Objektname lexikographisch der letzte unter den Namen aller Objekte ist, die als Teil dieser Version des Internet-Standard-MIB dargestellt werden.
3.2.6.3 Identification of Object Instances
Die Namen für alle Objekttypen in der MIB sind entweder explizit im Internet-Standard-MIB oder in anderen Dokumenten definiert, die den Benennungskonventionen der SMI entsprechen. Die SMI verlangt, dass konforme Management-Protokolle Mechanismen zur Identifikation einzelner Instanzen dieser Objekttypen für ein bestimmtes Netzwerkelement definieren.
Jede Instanz eines in der MIB definierten Objekttyps wird in SNMP-Operationen durch einen eindeutigen Namen identifiziert, der als ihre „Variablenname" (variable name) bezeichnet wird. Im Allgemeinen hat der Name einer SNMP-Variablen die Form x.y, wobei x der Name eines im MIB definierten nicht-aggregierenden Objekttyps ist und y ein OBJECT IDENTIFIER-Fragment ist, das auf eine Weise, die für den benannten Objekttyp spezifisch ist, die gewünschte Instanz identifiziert.
Diese Benennungsstrategie erlaubt die volle Ausnutzung der Semantik der GetNextRequest-PDU (siehe Abschnitt 4), da sie Namen für verwandte Variablen so zuweist, dass sie in der lexikographischen Ordnung aller im MIB bekannten Variablennamen zusammenhängend sind.
Die typ-spezifische Benennung von Objektinstanzen ist unten für eine Reihe von Klassen von Objekttypen definiert. Instanzen eines Objekttyps, auf den keine der folgenden Benennungskonventionen anwendbar ist, werden durch OBJECT IDENTIFIERs der Form x.0 benannt, wobei x der Name des betreffenden Objekttyps in der MIB-Definition ist.
Beispielsweise sei angenommen, man wolle eine Instanz der Variablen sysDescr identifizieren. Die Objektklasse für sysDescr ist:
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1
Somit wäre der Objekttyp x gleich 1.3.6.1.2.1.1.1, an den ein Instanz-Subidentifier von 0 angehängt wird. Das heißt, 1.3.6.1.2.1.1.1.0 identifiziert die einzige Instanz von sysDescr.
3.2.6.3.1 ifTable Object Type Names
Der Name einer Subnetz-Schnittstelle s ist der OBJECT IDENTIFIER-Wert der Form i, wobei i den Wert jener Instanz des Objekttyps ifIndex hat, der mit s assoziiert ist.
Für jeden Objekttyp t, dessen definierter Name n das Präfix ifEntry hat, wird eine Instanz i von t durch einen OBJECT IDENTIFIER der Form n.s benannt, wobei s der Name der Subnetz-Schnittstelle ist, über die i Informationen darstellt.
Beispielsweise sei angenommen, man wolle die Instanz der Variablen ifType identifizieren, die der Schnittstelle 2 zugeordnet ist. Entsprechend würde ifType.2 die gewünschte Instanz identifizieren.
3.2.6.3.2 atTable Object Type Names
Der Name einer AT-cache-Netzwerkadresse x ist ein OBJECT IDENTIFIER der Form 1.a.b.c.d, wobei a.b.c.d der Wert (in der üblichen „Punkt"-Notation) des Objekttyps atNetAddress ist, der mit x assoziiert ist.
Der Name einer Adressübersetzungsäquivalenz e ist ein OBJECT IDENTIFIER-Wert der Form s.w, sodass s der Wert jener Instanz des Objekttyps atIndex ist, der mit e assoziiert ist, und w der Name der mit e assoziierten AT-cache-Netzwerkadresse ist.
Für jeden Objekttyp t, dessen definierter Name n das Präfix atEntry hat, wird eine Instanz i von t durch einen OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name der Adressübersetzungsäquivalenz ist, über die i Informationen darstellt.
Beispielsweise sei angenommen, man wolle die physische Adresse eines Eintrags in der Adressübersetzungstabelle (ARP-Cache) finden, der einer IP-Adresse 89.1.1.42 und Schnittstelle 3 zugeordnet ist. Entsprechend würde atPhysAddress.3.1.89.1.1.42 die gewünschte Instanz identifizieren.
3.2.6.3.3 ipAddrTable Object Type Names
Der Name eines IP-adressierbaren Netzwerkelements x ist der OBJECT IDENTIFIER der Form a.b.c.d, sodass a.b.c.d der Wert (in der üblichen „Punkt"-Notation) jener Instanz des Objekttyps ipAdEntAddr ist, der mit x assoziiert ist.
Für jeden Objekttyp t, dessen definierter Name n das Präfix ipAddrEntry hat, wird eine Instanz i von t durch einen OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name des IP-adressierbaren Netzwerkelements ist, über das i Informationen darstellt.
Beispielsweise sei angenommen, man wolle die Netzwerkmaske eines Eintrags in der IP-Schnittstellentabelle finden, der einer IP-Adresse 89.1.1.42 zugeordnet ist. Entsprechend würde ipAdEntNetMask.89.1.1.42 die gewünschte Instanz identifizieren.
3.2.6.3.4 ipRoutingTable Object Type Names
Der Name einer IP-Route x ist der OBJECT IDENTIFIER der Form a.b.c.d, sodass a.b.c.d der Wert (in der üblichen „Punkt"-Notation) jener Instanz des Objekttyps ipRouteDest ist, der mit x assoziiert ist.
Für jeden Objekttyp t, dessen definierter Name n das Präfix ipRoutingEntry hat, wird eine Instanz i von t durch einen OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name der IP-Route ist, über die i Informationen darstellt.
Beispielsweise sei angenommen, man wolle den nächsten Hop eines Eintrags in der IP-Routing-Tabelle finden, der dem Ziel 89.1.1.42 zugeordnet ist. Entsprechend würde ipRouteNextHop.89.1.1.42 die gewünschte Instanz identifizieren.
3.2.6.3.5 tcpConnTable Object Type Names
Der Name einer TCP-Verbindung x ist der OBJECT IDENTIFIER der Form a.b.c.d.e.f.g.h.i.j, sodass a.b.c.d der Wert (in der üblichen „Punkt"-Notation) jener Instanz des Objekttyps tcpConnLocalAddress ist, der mit x assoziiert ist, und f.g.h.i der Wert (in der üblichen „Punkt"-Notation) jener Instanz des Objekttyps tcpConnRemoteAddress ist, der mit x assoziiert ist, und e der Wert jener Instanz des Objekttyps tcpConnLocalPort ist, der mit x assoziiert ist, und j der Wert jener Instanz des Objekttyps tcpConnRemotePort ist, der mit x assoziiert ist.
Für jeden Objekttyp t, dessen definierter Name n das Präfix tcpConnEntry hat, wird eine Instanz i von t durch einen OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name der TCP-Verbindung ist, über die i Informationen darstellt.
Beispielsweise sei angenommen, man wolle den Zustand einer TCP-Verbindung zwischen der lokalen Adresse 89.1.1.42 an TCP-Port 21 und der entfernten Adresse 10.0.0.51 an TCP-Port 2059 finden. Entsprechend würde tcpConnState.89.1.1.42.21.10.0.0.51.2059 die gewünschte Instanz identifizieren.
3.2.6.3.6 egpNeighTable Object Type Names
Der Name eines EGP-Nachbarn x ist der OBJECT IDENTIFIER der Form a.b.c.d, sodass a.b.c.d der Wert (in der üblichen „Punkt"-Notation) jener Instanz des Objekttyps egpNeighAddr ist, der mit x assoziiert ist.
Für jeden Objekttyp t, dessen definierter Name n das Präfix egpNeighEntry hat, wird eine Instanz i von t durch einen OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name des EGP-Nachbarn ist, über den i Informationen darstellt.
Beispielsweise sei angenommen, man wolle den Nachbarzustand für die IP-Adresse 89.1.1.42 finden. Entsprechend würde egpNeighState.89.1.1.42 die gewünschte Instanz identifizieren.
Return: RFC 1157 Home