4.7 Wie arbeite ich mit einem Protokoll Analyser...?
Ich denke, daß wir nun genug über den logischen Aufbau von Nachrichten, Datagrammen, Paketen und Rahmen gesprochen haben. Lassen Sie uns nun einen Blick auf die Daten werfen, die wir tagtäglich durch die Kupfer- und Lichtleiter schicken. Dafür benötigen wir einen Protokoll-Analyser.
Wenn in einem Netzwerk Fehler auftreten, sollte man sich immer den Inhalt der empfangenen und gesendeten Rahmen ansehen. Anhand der in diesen Rahmen enthaltenen Daten, kann man verschiedene Fehler relativ schnell einkreisen. Zudem muss man beim Einsatz eines Protokoll Analyser's nicht das Netz auftrennen, und somit andere funktionsfähige Geräte bei Ihrer Arbeit stören. Sie können das mit dem abhören Ihres Herzens vergleichen, auch hier werden keine Körperfunktionen beeinträchtigt......:-)
Um die Arbeit mit einem Protokoll-Analyser verständlich darzustellen, habe ich zwei Rechner über ein Fast-Ethernet miteinander verbunden. Die für uns wichtigen Netzwerkdaten der beiden Rechner:
Rechnername: | MAC-Adresse: | IP-Adresse: | Community |
SERVER1 | 00:10:4B:B9:F4:A3 | 192.168.0.10 | public |
SERVER2 | 00:10:4B:B9:F6:47 | 192.168.0.20 | public |
Auf SERVER2 ist der Standard-SNMP-Dienst von WinNT 4.0 installiert. Auf SERVER1 läuft zusätzlich zum SNMP-Dienst ein Managementsystem mit Protokoll-Analyser. Zuerst starte ich den Protokoll-Analyser auf SERVER1 und wechsle dann auf die Konsole von SERVER2. Hier sende ich mit Hilfe des des SNMP-Werkzeuges "SNMPTOOL" eine GetRequest-Nachricht an SERVER1.
Eingabe Konsole:
![]() | "snmptool get server1 public 1.1.0" |
Mit dieser GetRequest-Nachricht rufe ich den Wert der MIB-Variablen mit der Objekt-ID: 1.3.6.1.2.1.1.1.0 vom Rechner SERVER1 ab. Grafik 19 zeigt uns das gesendete Paket in grafischer Darstellung (erstellt vom Protokoll-Analyser auf SERVER1). Gehen wir noch einmal genauer auf die verschiedenen (für uns wichtigen) Informationen wie der Rahmentyp usw. ein.
Informationen aus der Rahmen-Bereich:
Ganz oben die Ziel- und Quelladressen (MAC).
Es handelt sich um einen 802.3 Ethernet-Rahmen.
Die Größe der Rahmen beträgt 82 Oktetten
Das Rahmen-Protokoll ist IP
Informationen aus dem IP-Bereich:
Zuerst wieder die Quell- und Zieladresse, diesmal als IP-Adresse.
Danach die Versionsnummer des IP-Protokolls: Version 4
Die Größe des IP-Paketes: 68 Oktetten
Die Information, daß das Paket nicht unterteilt wurde: Fragments: No
Welches Transport-Protokoll: UDP
Die Information das mit der Prüfsumme alles in Ordnung ist: FCA0 (GOOD)
Informationen aus dem UDP-Bereich:
Welcher Quell-Port (1084), welcher Ziel-Port (161)
Größe des UDP-Datagramms: 48 Oktetten
Alles klar mit der Prüfsumme: (GOOD)
Grafik
20 zeigt uns die detaillierte Ansicht des SNMP-Bereichs. Es handelt sich um die selbe
Nachricht!
Nun, was lesen wir aus diesen Informationen?
- die Länge des SNMP-Payloads: 40
Oktetten (oder Bytes)
- die SNMP-Version: 0
- der Name der Community: public
- um welche Art von SNMP-Nachricht es sich handelt: SNMP
GetRequest
- ob Fehler aufgetreten sind, und wenn ja welche: PDU Error
Status : 0, Error Index : 0x00
- die Anzahl der Objekte: 1
- die Objekt ID: 1.3.6.1.2.1.1.1.0
- um welchen Datentyps sich handelt: Noch keiner, daher auf
NULL gesetzt
GetRequest-Nachricht mit detaillierter Ansicht der SNMP-Sektion (Grafik 20)
Grafik 21 zeigt uns die aus der GetRequest resultierende GetResponse-Nachricht:
Aus ihr können wir folgende Informationen herauslesen:
- die Länge des SNMP-Payloads: 165
Oktetten (oder Bytes)
- die SNMP-Version: 0
- der Name der Community: public
- um welche Art von SNMP-Nachricht es sich handelt: SNMP
GetResponse
- ob Fehler aufgetreten sind, und wenn ja welche: PDU Error
Status : 0, Error Index : 0x00
- die Anzahl der Objekte: 1
- die Objekt ID: 1.3.6.1.2.1.1.1.0
- um welchen Datentyps sich handelt: Octet String
- der Wert der Variablen: in diesem Fall Informationen
über die Hardware des SERVER1
Wie Sie sehen können, war sowohl die Request wie auch die Response-Nachricht ein Erfolg (Keine Fehlermeldungen im Error Status- und Error Index- Feld).
GetRespone-Nachricht (Grafik 21)
Grafik 21.1 zeigt Ihnen den Konsolenbildschirm von SERVER2. Hier sehen Sie den Eingabe-Syntax und die resultierende GetResponse-Nachricht.
Konsolenbildschirm von SERVER2 (Grafik 21.1)
Jetzt werde ich eine GetRequest-Nachricht mit einer "falschen" Objekt-ID an SERVER1 senden.
Eingabe Konsole:
![]() | "snmptool get server1 public 0.0." |
Mit diesem Syntax starte ich eine GetRequest-Nachricht an SERVER1. Als Objekt-ID habe ich 1.3.6.1.2.1.0.0 angegeben. Dieses Objekt gibt es aber nicht. Sehen wir uns zuerst die GetRequest-Nachricht an (Grafik 22). Wie Sie sehen, sieht diese Nachricht wie die vorhergehende GetRequest Nachricht aus. Lediglich die Größe und Objekt-ID ist anders. Also nicht so interessant!
GetRequest-Nachricht mit falscher "MIB-Adresse" (Grafik 22)
Anders sieht es bei der GetResponse-Nachricht aus (Grafik 23). Hier befinden sich nun Fehlermeldungen in den Error Status- und Error Index-Feldern. Gehen wir genauer auf Sie ein.
Error Status: 2 => das bedeutet, daß ein "noSuchName"-Fehler aufgetreten ist. Das heißt wiederum, daß die angeforderte OID nicht vom Agent unterstützt wird.
Error Index: 1 => das bedeutet, daß der Fehler in der ersten Variablen aufgetreten ist.
GetResponse-Nachricht mit Fehlermeldung (Grafik 23)
Hier die Meldung, die ich auf dem Konsolenbildschirm von SERVER2 erhalten habe (Grafik 23.1)
Konsolenbildschirm von SERVER2 (Grafik 23.1)
Hiermit wäre das ENDE von SNMP Allgemein erreicht!!!
Über FEEDBACK würde ich mich freuen!!!