AIX - Probleme mit snmpd und dpid2

orm@doc-tcpip.org

Erstellt: Juli 2001 - Letzte Modifikation: April 2005

Der SMUX Peer fehlt - snmpd und dpid2

Der dpid2 Service - ein snmpd Agent

Ab AIX 4.3 läuft auf den Maschinen ein Dämon unter der Kontrolle des SRC der sich dpid2 nennt. Das ist ein Dämon, der zwischen zwei Protokollen bzw. Formaten der Nachrichten des snmpd konvertiert. Er funktioniert also als Übersetzer zwischen SNMP und allen Dämonen oder Applikationen, die das erweiterte Protokoll benutzen.

Bei diesen Protokollen handelt es sich um das klassische SNMP MUX (SMUX) Protokoll in Verbindung mit entsprechenden MIBs (RFC 1227) sowie um SNMP DPI 2.0 (Distributed Protocol Interface, RFC 1592).

Da der Standard-snmpd DPI nicht versteht, benötigen alle DPI-Subagenten diesen Konverter. Ein Beispiel wäre der Dämon /usr/sbin/hostmibd. Dessen Nachrichten werden vom dpid2 in Standard-snmpd, also SMUX, Nachrichten übersetzt und weitergeleitet. Umgekehrt sendet der snmpd Nachrichten an einen DPI-Subagenten auch über den Konverter dpid1. Der Service dpid2 ist also ein SMUX-DPI2.0 Konverter.

Wichtigster Unterschied zwischen SMUX und DPI ist, daß das Distributed Program Interface (DPI) es ermöglicht, dynamisch Variablen in der lokalen Management Information Base (MIB) hinzuzufügen, zu ändern und zu löschen. Im klassischen SNMP erfordert daß, den SNMP Agenten neu zu kompilieren.

Funktion

Der snmpd stellt auf Port 199 einen SMUW Server zur Verfügung. Der dpid2 verhält sich einmal wie jeder SMUX Peer und verbindet sich auf diesen Port. Gegenüber einem DPI2 Subagenten verhält er sich wie ein Server (Agent) und lauscht auf einem frei gewählten TCP Port auf Verbindungs-Anfragen seitens der Subagenten.

Den Port, auf dem der dpid2 lauscht, registriert er beim snmpd über die MIB Variable dpiPortForTCP (1.3.6.1.4.1.2.2.1.1.1). Ein DPI2 Subagent sendet ein get-request, indem er nach der Instanz dpiPortForTCP.0 (1.3.6.1.4.1.2.2.1.1.1.0) fragt. Über diese Port Nummer nimmt der DPI2-Agent Verbindung mit dem dpid2 auf und sendet seine Nachrichten im DPI2.0 Format.

Gestartet wird der dpid2 in der /etc/rc.tcpip bzw. über den SRC.

Was ist mit SNMPv3 und AIX 5.2 bzw. 5.3?

Die Version 3 des SNMP (snmpdv3) integriert die Konverter-Funktion in den SNMP Dämon. Der entsprechende Port wird wie im Fall der getrennten Services registriert und über die MIB abgefragt. Daher ist der dpid2 nicht mehr nötig, und er wird daher nicht mehr gestartet.

Die Protokolle SMUX und DPI

Das SMUX-Protokoll ist ein sehr einfaches Protokoll, siehe [8]. Der Agent wartet auf einen Verbindungsaufbauwunsch eines Subagenten, sobald die Verbindung aufgebaut ist, erhält er ein OpenPDU vom Subagenten. Diesen Verbindungsaufbauwunsch kann er ablehnen, indem er ein ClosePDU sendet und die Verbindung abbricht oder er akzepiert es und wartet anschließend auf die RReqPDUs, mit denen sich die Teilbäume vom Subagenten anmelden. Auf die RReqPDUs antwortet der Agent mit RRspPDUs um den Erfolg der Registrierung der Teilbäume anzuzeigen. Der Subagent kann auch TRAPs an den Agenten schicken, die dieser an die Managementstation weiterleitet. Erhält der Agent eine SNMP GetRequest PDU, GetNextRequest PDU oder SetRequest PDU, welche Variablen beinhaltet, die bei einem Subagenten registriert sind, wird eine entsprechende SNMP PDU erzeugt, in der nur die Variablen enthalten sind, welche beim Subagenten registriert sind. Diese SNMP PDU wird vom Subagenten durch eine SNMP GetResponse PDU beantwortet, worauf der Agent die einzelnen PDUs von den verschiedenen Subagenten wieder zu einer SNMP Response PDU vereinigt und an die Managementstation zurücksendet. Bei einer SetRequest PDU ist die Abwicklung etwas aufwendiger, hier muß die Bearbeitung über ein einfaches zwei-phasen Bestätigungsprotokoll, zwischen dem Agenten und Subagenten, abgewickelt werden, da die Setoperation atomar ist. Desweiteren ist es dem Subagenten gestattet jederzeit einen seiner Teilbäume wieder abzumelden. Soll die Verbindung geschlossen werden, wird ein ClosePDU gesendet, wobei sowohl der Agent als auch der Subagent den Abbruch der Verbindung veranlassen können.

Das Problem

Auf der Maschine finden sich - je nach Fehler und installierter Software - in den Logs /usr/tmp/snmpd.log, /usr/tmp/dpid2.log und /usr/es/adm/cluster.log massenweise Meldungen dieser Art:

Apr 28 14:07:42 rosel syslog: 2 dpid2    17812 (root    )  lost connection to agent
Apr 28 14:07:47 rosel snmpd[430164]: NOTICE: SMUX relation started with (127.0.0.1+53850+1124)
Apr 28 14:07:47 rosel snmpd[430164]: NOTICE: SMUX packet from (127.0.0.1+53850+1124)
Apr 28 14:07:47 rosel snmpd[430164]: EXCEPTIONS: simpleOpen rejected (badIdentity): risc6000sampleAgents.2 (SMUX 127.0.0.1+53850+1124)

Je nachdem, wie die Logs definiert sind, laufen sie gnadenlos voll, da die Meldung alle 5 Sekunden erscheint. In diesem Fall bekommt der snmpd eine Verbindungsanforderung von Jemandem, den er in seiner Konfiguration nicht findet - daher schmettert er die Anfrage mit einem simpleOpen rejected ab und generiert die Meldung.

Alle SMUX Peers, die der snmpd anerkennt, sind in der /etc/snmpd.conf definiert:

....
#smux           1.3.6.1.4.1.2.3.1.2.1.2         gated_password  # gated
#smux            1.3.6.1.4.1.2.3.1.2.2.1.1.2     dpid_password   #dpid
....

Im File /etc/snmpd.peers stehen die SMUX Peers, die der snmpd versucht zu kontaktieren:

....
# "gated"     1.3.6.1.4.1.2.3.1.2.1.2   "gated_password"
"dpid2"     1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
....

In diesem Fall ist es so konfiguriert, daß der snmpd den dpid2 zwar kontaktiren soll, aber keine Nachrichten von ihm empfangen darf. Das führt natürlich zur gezeigten Fehlermeldung.

Die Einträge in den Dateien müßen sich entsprechen (oft sind auch die Passwörter unterschiedlich gesetzt). Nach einer Korrektur muß der snmpd gestoppt und gestartet werden.

Eine andere, ähnliche Fehlermeldung wird erzeugt, wenn der dpid2 nicht läuft, aber als Peer definiert ist. Fehlerbehebung ist analog.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]