labor für university of applied sciences netzwerktechnik und … · 2009-04-26 · 2.4.5...

Fachhochschule Würzburg–Schweinfurt University of Applied Sciences

Fakultät Elektrotechnik Department of Electrical Engineering

Labor für Netzwerktechnik und

Netzwerkmanagement Prof. Dr.-Ing. Ludwig Eckert

Prof. Dr.-Ing. Ludwig Eckert Email: [email protected] Internet: www.fh-sw.de/pdv

Title: Netzwerkmanagement mit Hilfe von SNMP und des Open Source-Tools Nagios

Version: V3.10

Date: 16.04.2009

Classification

- binding - public

The information contained in this document may be subject to change without prior notice. The Head of the Department does not make any representation, warranty or undertaking (express or implied) with respect to, and does not accept any responsibility for, (and hereby disclaims liability for) the accuracy or completeness of the information contained in this document.

Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.

Access to and distribution of this document by the editor is made pursuant to the regulations of the department.

List of Contents: 1. See

Reference: 2. No references

Language of original: Deutsch

Number of pages: 47

Document History

Version Date

Author(s) email address

Changes and other notes

V1.00/01.07.2008 [email protected] Erstentwurf

V1.10/22.07.2008 [email protected] Überarbeitung

V1.20/29.08.2008 [email protected] Punkt 2.3 erweitert

V2.00/15.09.2009 [email protected] Punkt 2.3.4 hinzugefügt

V2.10/23.09.2009 [email protected] Überarbeitung

V2.20/28.10.2009 [email protected] Anpassung an LiveCD

V3.00/05.03.2009 [email protected] Neufassung für VMWare

V3.10/16.04.2009 [email protected] Anpassung nach Feedback

Fakultät Elektrotechnik LABOR FÜR NETZWERKTECHNIK UND NETZWERKMANAGEMENT

FH Würzburg-Schweinfurt Seite 2 / 43

Inhaltsverzeichnis

GLOSSAR ................................................................................................................................................. 4

1 EINLEITUNG ................................................................................................................................. 5

1.1 Ziele .......................................................................................................................................................... 5

1.2 Aufgabenbeschreibung .............................................................................................................................. 5

1.3 Versuchsvorbereitung ............................................................................................................................... 5

2 TEILVERSUCH1: INSTALLATION UND KONFIGURATION DER SNMP AGENTEN ................................................................................................................................................ 6

2.1 Ziele .......................................................................................................................................................... 6

2.2 Aufgabenbeschreibung .............................................................................................................................. 6

2.3 Einführung in das Simple Network Management Protocol (SNMP) ............................................................. 6 2.3.1 Aufbau eines SNMP‐Pakets ........................................................................................................................ 6 2.3.2 Syntax eines SNMP‐Befehls ....................................................................................................................... 8 2.3.3 Einführung in das Prinzip der Management Information Base (MIB) ........................................................ 9 2.3.4 Erklärung des Aufbaus einer MIB anhand der MIB‐2 ............................................................................... 11

2.4 Versuchsdurchführung ............................................................................................................................ 17 2.4.1 Konfiguration des Netzwerks und Installation der Pakete ....................................................................... 17 2.4.2 Konfiguration der SNMP‐Agenten ........................................................................................................... 18 2.4.3 Anwendungsaufgabe zur SNMP‐Konfiguration ....................................................................................... 19 2.4.4 Lesen einer herstellerspezifischen MIB mit Hilfe eines MIB‐Browsers .................................................... 21 2.4.5 SNMP‐Protokollanalyse mit Hilfe von Wireshark..................................................................................... 21 2.4.6 Trap‐Management mit Protokollanalyse ................................................................................................. 24

3 TEILVERSUCH2: ÜBERWACHUNG DER VERFÜGBARKEIT VON NETZWERKKOMPONENTEN UND DIENSTEN MIT NAGIOS ........................................ 27

3.1 Ziele ........................................................................................................................................................ 27

3.2 Aufgabenbeschreibung ............................................................................................................................ 27

3.3 Einführung in die NMS‐Architektur anhand von Nagios ............................................................................ 27 3.3.1 Definieren von Objekten in Nagios .......................................................................................................... 29 3.3.2 Was ist ein Nagios‐Plug‐In? ...................................................................................................................... 32

3.4 Versuchsdurchführung ............................................................................................................................ 33 3.4.1 Hinzufügen von neuen Hosts und Services .............................................................................................. 33 3.4.2 Nutzung des Nagios SNMP‐Plug‐Ins ......................................................................................................... 33

4 TEILVERSUCH 3: ÜBERWACHUNG DER PERFORMANCE EINES NETZWERKS ....................................................................................................................................... 35

4.1 Ziele ........................................................................................................................................................ 35

4.2 Aufgabenbeschreibung ............................................................................................................................ 35



4.3 Welchen Zweck haben Performance‐Daten? ............................................................................................ 35

4.4 Versuchsdurchführung ............................................................................................................................ 35 4.4.1 Konfiguration von Nagios ......................................................................................................................... 35 4.4.2 Auswertung von Countervariablen .......................................................................................................... 37

4.5 Abzuliefernde Ergebnisse......................................................................................................................... 41

5 LITERATURVERZEICHNIS ........................................................................................................ 41

6 FEEDBACKFORMULAR ........................................................................................................ 42



GLOSSAR

Aptitude: Paketmanager für GNU/Linux Systeme

ASN.1: Beschreibungssprache zur Definition von Datenstrukturen

Daemon: Programm das im Hintergrund läuft und einen Dienst zur Verfügung stellt (ssh, httpd,…)

Ifconfig: Programm zum konfigurieren der Netzwerkkarten unter Linux. Die Syn-tax lautet: ifconfig [Interface][ip]

MIB: Die Management Information Base beschreibt die Informationen, die über ein Netzwerk-Management Protokoll (zum Beispiel SNMP) abgefragt oder modifiziert werden können. Diese Informationen werden Managed Objects genannt.

Nagios: Nagios ist eine frei erhältliche Software für Linux. Sie dient zur Überwachung von Netzwerkkomponenten und deren Diensten

NET-SNMP: Das Net-SNMP Softwarepaket dient der Bereitstellung und Nutzung des SNMP Protokolls unter Linux

Netstat: Kommandozeilen Tool das die aktuellen Rechnerverbindungen zeigt.

NMS: Network Management Station, zentrales Überwachungssystem in einer Netzwerkumgebung. Objekt (Nagios): In Nagios wird ein Host, ein Service, ein Kontakt, eine Gruppe und auch ein Kommando als Objekt definiert. Der Grund liegt in der Vererbung der Eigenschaften die in Nagios möglich ist. OID: Der Object Identifier ist ein eindeutiger Bezeichner innerhalb einer Datenstruktur wie z.B. einer MIB PDU: Protocol Data Unit, ein Datensatz der durch eine Netzwerkschicht gesendet wird. Plug-in: kleines Programm oder Skript welches ein Programm erweitert.

SNMP: Das Simple Network Management Protocol wurde entwickelt um Netzwerkkomponenten von einer zentralen Stelle aus zu überwachen.

SNMP-TRAP: Paket das von einer Netzwerkkomponente mit SNMP Unterstützung unaufgefordert an eine NMS gesendet wird. (Meist im Fehlerfall)



1 EINLEITUNG

1.1 Ziele In dem Versuch soll den Studierenden die Grundlagen der Netzwerkverwaltung mit Hilfe von Open Source Tools, hier am Beispiel von Nagios gezeigt werden. Dazu werden im ers-ten Teilversuch die SNMP Grundlagen geschaffen und vertieft. Im zweiten Teil wird Na-gios als Netzwerkmanagementsystem verwendet.

1.2 Aufgabenbeschreibung Die Studierenden sitzen an eine Windows XP System, in dem ein jeweils identisches Linux System (Debian 5.0) per VMWare betrieben wird. Die Systeme sind über den Switch C mit dem Windows Server 2003 (Internet-Gateway) verbunden sind. Vor dem Versuch sol-len diese Verbindungen zuerst auf Korrektheit überprüfen. Anschließend wird der NET-SNMP Agent konfiguriert und getestet. Am Ende des Versuchs steht dann die grafische Überwachung des Netzwerks im Mittelpunkt. Dazu wird das ebenfalls kostenlose Tool Nagios verwendet.

Debian 3192.168.0.23

Win 2003192.168.0.1(Gateway)

Debian 1192.168.0.21

Debian 2192.168.0.22

Switch (KTI)

Switch C, Cisco 2950192.168.0.33

Bild 1-1: Versuchsaufbau

1.3 Versuchsvorbereitung Da einige Teile des Versuchs unter Linux stattfinden, ist es erforderlich die wichtigsten Befehle dieses Betriebssystems zu kennen. Ebenfalls ist es notwendig mit einem Texteditor umgehen zu können. Das Rechenzentrum der FH-Schweinfurt bietet hierzu zwei Doku-mente an. Wenn Sie keinerlei Erfahrung mit Linux haben wird Ihnen die Arbeit mit dem Editor nano am leichtesten fallen, da dieser relativ ähnlich zu den Dos/Windows Editoren ist.

http://www.fh-sw.de/sw/rz/sammlung/dokumente/unixkommandos.pdf http://www.fh-sw.de/sw/rz/sammlung/dokumente/vi.pdf

Weiterhin sollten die Studierenden ein Medium zur Sicherung Ihrer Versuchsergebnisse mitbringen (Diskette, USB-Stick). Auf der Linux Konsole kann auch zu jedem Befehl per man „Befehl“ eine Hilfedatei zum selbigen geöffnet werden.

Achtung: Wenn ein Befehl mit Pfadangabe in der Anleitung steht z.B. /etc/init.d/snmpd restart dann ist dieser genau so auf der Konsole auszuführen. Würde man in das Verzeich-nis /etc/init.d wechseln und dort snmpd restart eingeben, wird nichts passieren.

.



2 TEILVERSUCH1: INSTALLATION UND KONFIGURATION DER SNMP AGENTEN

2.1 Ziele Das Ziel des ersten Teilversuchs ist es, den grundlegenden SNMP Aufbau sowie den Um-gang mit einer MIB kennen zu lernen.

2.2 Aufgabenbeschreibung Die Studierenden müssen das Netzwerk für die Benutzung vorbereiten. Anschließend wird die Konfiguration der SNMP Agenten durchgeführt, eine MIB von einem Hersteller unter-sucht und eine SNMP-Protokollanalyse durchgeführt.

2.3 Einführung in das Simple Network Management Protocol (SNMP) Im folgenden Abschnitt werden die SNMP Grundlagen erklärt. SNMP steht für Simple Network Management Protocol. Es wird genutzt um die Komponenten, Systeme und Dienste einer Netzwerkumgebung zentral zu überwachen. Die Kommunikation findet immer zwischen dem SNMP-Manager und einem SNMP-Agenten statt und verläuft auf 2 Arten. Im Normalfall sendet der SNMP-Manager einen Request an den Agenten (per UDP, Destination Port 161) welchen der Agent mit einer Response (UDP, Port161) beantwortet. Eine Ausnahme bilden Traps(UDP, Port162), da diese unaufgefordert von dem Agenten im Problemfall an den Manager versendet werden.

Port 161SNMP‐Response

Port 161SNMP‐Request

Port 162SNMP‐Trap

SNMP‐Manager(NMS)

Linux HostSNMP‐Agent

Linux HostSNMP‐Agent SNMP‐Manager

(NMS)

Bild 2-1: SNMP Kommunikation

2.3.1 Aufbau eines SNMP-Pakets1 Ein SNMP Paket ist nach dem ASN.1 Standard aufgebaut. Dies ist eine Sprache zur Defi-nition von Datenstrukturen um so ein weltweit einheitliches Format zu erhalten. Durch ASN.1 ist es möglich Systeme die intern unterschiedliche Datendarstellungen nutzen mit-einander kommunizieren zu lassen. ASN.1 beschreibt neben der Struktur einer Anwendung auch PDUs (Protocol Data Units) welche zwischen den verschiedenen OSI Schichten ausgetauscht werden.

In den folgenden Abbildungen wird der Aufbau näher erläutert. Eine SNMP Anfrage durchläuft jede Schicht des OSI Modells und bekommt von jedem Protokoll seinen „Stem-pel“ also den Header angehängt.

1 http://tools.ietf.org/html/rfc1157#section-4



Bild 2-2: OSI-Modell

Nach Durchlauf aller Schichten sieht ein SNMP Paket also wie folgt aus.

Bild 2-3: SNMP-Paket mit allen Headern

Auf den Ethernet, IP und UDP Header wird hier nicht näher eingegangen, da diese auch im Unterricht behandelt werden. Der SNMP Header enthält die in Bild 2-4 dargestellten Ele-mente.

Bild 2-4: SNMP-Header

Die Paketgröße bzw. die Länge der Nachricht wird in Bytes angegeben. Danach folgt die Angabe der SNMP Version die genutzt wird und der Communitystring (Passwort).

Die PDU selbst enthält auch wieder einen Header und einen Body. Da der Header abhän-gig von der Art des SNMP Pakets (Request/Response oder Trap) ist wird dieser gesondert betrachtet. Zuerst wird ein Standard PDU-Header beschrieben. Dieser trifft auf die folgen-den Operationen zu:

GET REQUEST fordert einen Datensatz an GETNEXT REQUEST fordert den folgenden Datensatz an (für Tabellen) GET RESPONSE Antwort auf eine vorherige Anfrage SET REQUEST ändert einen Datensatz

Bild 2-5: PDU (kein Trap)

Im Pakettyp steht der gewünschte SNMP Befehl (get, set,…) und anschließend die Länge der PDU. Die Request ID wird verwendet um Antwortpaketen vorhergehenden Anfragen

7 application

1 physical

2 data link

3 network

4 transport

6 presentation

5 session

SNMP

UDP

IP

Ethernet II

OSI‐Layer Protokoll

IP

Header

Ethernet II

Header

UDP

Header

SNMP

Header

PDU

Paketgröße Version Community

Pakettyp Länge RequestID ErrorStatus ErrorIndex



zuzuordnen. Der Error Status kann in SNMPv1 sechs verschiedene Zahlenwerte (Integer) annehmen2:

noError(0) tooBig(1) noSuchName(2) badValue(3) readOnly(4) genErr(5)

Ist der Error Status ungleich 0, dann ist ein Fehler aufgetreten. In diesem Fall kann der Er-rorindex weiterführende Informationen enthalten, z.B. den Verursacher.

Bild 2-6: PDU (Trap)

Im Falle eines Traps sieht der Aufbau des PDU-Header etwas anders aus. Der Anfang ist identisch. Aus dem Pakettyp geht hervor, dass es sich um einen Trap handelt. Ebenso wird die Länge des Paketes mit angegeben. Danach folgt die Angabe der OID, also welcher Agent den Trap verursacht hat. Im Anschluss an die OID wird ebenfalls die IP-Adresse des Trapverursachers (agent-address) übermittelt. Die Trap ID kann sieben Werte annehmen:

coldStart(0) Ein Gerät wird reinitialisiert nach Änderung (z.B. der Konfiguration)

warmStart(1) Ein Gerät wir reinitialisiert ohne Änderung linkDown(2) Fehler in Kommunikation (Netzwerk unterbrochen) linkUp(3) Kommunikation wieder OK authenticationFailure(4) Fehler bei Authentifizierung egpNeighborLoss(5) EGP Nachbar verloren (weitere Infos unter 3) enterpriseSpecific(6) Ein Herstellerspezifischer Trap wurde ausgelöst.

Nach der generischen Trap-ID folgt die Angabe des spezifischen Traps (Integer). Dieser ist abhängig vom Hersteller und enthält dessen vorher in einer MIB definierte Daten. Falls die Trap-ID nicht (6) ist, ist dieser Abschnitt trotzdem vorhanden, allerdings ohne Wirkung. Am Ende des Pakets steht noch ein Zeitstempel (time-stamp), so können in einer großen Netzwerkumgebung die eintreffenden Traps der Reihe nach bearbeitet werden.

Der PDU-Body ist bei den verschiedenen Paketen identisch.

Bild 2-7: PDU-Body

Am Anfang steht wieder die Größe gefolgt von der OID und dem Datentyp des folgenden Wertes. Im Wert Feld selbst stehen die Informationen die eigentlich gewünscht sind.

2.3.2 Syntax eines SNMP-Befehls

Die Syntax eines SNMP-Befehls ist lautet folgendermaßen (hier anhand von snmpwalk aus dem NET-SNMP Paket):

2 http://tools.ietf.org/html/rfc1157#section-4.1.1 3 http://tools.ietf.org/html/rfc1157#section-3.2.6.3.6

Pakettyp Länge OID agent‐address

specific‐trap

time‐stamp

Trap ID

Größe OID Datentyp Wert



snmpwalk <version> <community> Agent <oid>

Zuerst kommt der eigentliche Befehl. Zur Auswahl stehen hier unter anderem folgende

snmpget fragt einen spezifischen Wert ab. snmpgetnext fragt den nächsten Wert ab (zum durchlaufen von Tabellen) snmpwalk gibt alle Werte einer Gruppe wieder. snmpset ändert einen Wert.

Als nächstes folgt die Angabe welche SNMP Version genutzt wird.

v1 In der ersten SNMP-Version waren fast keine Sicherheitsmechanismen vorhan-den. So wird hier der Community-String unverschlüsselt übertragen und kann des-halb leicht mit Hilfe von Netzwerkanalysetools ermittelt werden.

v2c auch als Community-Based SNMP bezeichnet, wurde eingeführt um die Kom-munikation zwischen mehreren Netzwerkmanagern zu ermöglichen, sicherheits-technisch ist SNMPv2c jedoch auf SNMPv1 Niveau.

v3 In der 3. Version wurden wesentliche Sicherheitsmechanismen eingeführt. Al-lerdings ist dies teils recht komplex, weshalb viele Geräte diese Version nicht un-terstützen. Man muss deshalb vor der Verwendung prüfen, ob die verwendeten Ge-räte SNMPv3 kompatibel sind.

Auf die Version folgt immer die Angabe der Community, dies sind Gruppen in denen die Zugriffsrechte stehen. Der Community-String ist also eine Art Passwort. Der SNMP Agent erkennt so ob der zugreifende Rechner überhaupt die Berechtigung hat ist4von ihm Infor-mationen anzufordern.

Schließlich muss noch der Agent angegeben werden der abgefragt werden soll, und der OID mit der Instanznummer, welcher die gewünschte Information bereithält.

Im folgenden Beispiel wird localhost als Ziel angegeben. Möchte man auf einen Computer im Netzwerk zugreifen, so gibt man einfach dessen IP an bzw. seinen Namen sofern er im DNS Register eingetragen ist.

Konkretes Beispiel:

snmpget –v2c -c public localhost sysContact.0

SNMPv2-MIB::sysContact.0 = STRING: Jürgen Erhard [email protected]

2.3.3 Einführung in das Prinzip der Management Information Base (MIB)

MIB steht für „Management Information Base“. Sie ist eine Art Datenbank, in der die In-formationen definiert sind welche der Agent an den Manager auf Anfrage sendet. Unter Linux findet man die installierten MIBs unter /usr/share/snmp/mibs. In Windows liegen die MIBs meist im Verzeichnis des installierten MIB-Browsers. Im Falle des iReasoning MIB-Browsers welcher im Versuch verwendet wird liegen diese unter C:\Programme\ireasoning\mibbrwoser\mibs

4 In den meisten Fällen ist public der vom Hersteller voreingestellte Community-String.



Der Aufbau ist hierarchisch und gleicht einer Baumstruktur. Auf die einzelnen Elemente der MIB greift man via object identifiers, den so genannten OIDs zu. In Bild 2-2 sieht man, dass hinter jedem Namen eines Baumastes eine Zahl steht. Auf die einzelnen Ele-mente kann zugegriffen werden, indem die Namen von oben nach unten mit einem Punkt getrennt geschrieben oder die entsprechende Zahl dahinter gesetzt wird. Soll nun auf die MIB-2 verwiesen werden schreibt man also entweder iso.org.dod.internet.mgmt.mib-2 oder einfach 1.3.6.1.2.1. (Instanz)

Iso(1)

org(3)

mib‐2(1)

directory(1)

dod(6)

Internet(1)

mgmt(2)

system(1) Interfaces(2) icmp(5)ip(4)at(3) Bild 2-8: Aufbau der MIB

In der MIB-2 stehen die wichtigsten Funktionen für Netzwerkgeräte. Sie gilt deshalb als Standard MIB die von nahezu allen SNMP-fähigen Netzwerkkomponenten zur Verfügung gestellt wird.

Die MIB-2 enthält neun Gruppen welche im Folgenden erläutert werden. Die genaue Be-schreibung findet man in der RFC12135.

system in Ihr stehen Informationen zum System (Standort, Administrator, Betriebssystem,…)

interfaces enthält Informationen über die Netzwerkkarten at Adress Translation Group, wird mittlerweile nicht mehr verwendet ip Gruppe für Komponenten welche das IP Protokoll nutzen. Enthält

Statistiken (z.B. Traffic) und Tabellen (z.B. welches Interface welche IP-Adresse oder Subnetmaske hat)

icmp falls im IP Protokoll ein Problem auftritt wird eine ICMP Message zurückgesendet. Diese Gruppe enthält nur Countervariablen welche für die verschiedenen ICMP Errors hochgezählt werden.

tcp enthält Statistiken über das TCP Protokoll udp enthält Statistiken über das UDP Protokoll

5 http://tools.ietf.org/html/rfc1213



egp das EGP Protokoll wird von Routern verwendet um Informationen zwischen Autonomen Systemen auszutauschen. In der Gruppe stehen Informationen zum Nachbarsystem (z.B. die IP) so wie weitere Statistiken

snmp enthält Statistiken zum SNMP Protokoll transmisson enthält die verwendete Übertragungstechnologie (Ethernet, Token

Ring,…)

Als Hilfsmittel nützlich ist auch ein MIB-Browser, welche es für jedes Betriebssystem im Internet verfügbar sind. Empfehlenswert ist der kostenlose MIB-Browser von iReasoning http://www.ireasoning.com/mibbrowser.shtml.

In Bild 2-3 die Beschreibung der Funktion sysContact. Diese liefert üblicherweise den Namen des Administrators bzw. dessen Email-Adresse zurück.

Bild 2-9: MIB Variable sysContact dargestellt mit MIB-Browser von iReasoning

Da die MIB-2 einen sehr großen Stellenwert besitzt, ist es nicht nötig ihre übergeordneten Knoten mit anzugeben. So kann auf jeden Wert direkt verwiesen werden, indem man den Namen angibt. In unserem Fall also einfach sysContact.0

Die 0 steht für die Instanz6 und muss immer mit angegeben werden! Bei einem System mit mehreren Netzwerkkarten greift man auf die einzelnen Karten durch die Angebe der jewei-ligen Instanz zu z.B.

IF-MIB::ifDescr.1 = STRING: lo (Loopback)

IF-MIB::ifDescr.2 = STRING: eth0 (Netzwerkadapter 1)

IF-MIB::ifDescr.3 = STRING: eth1 (Netzwerkadapter 2)

2.3.4 Erklärung des Aufbaus einer MIB anhand der MIB-2

Es ist für die Praxis sehr wichtig die Struktur einer MIB zu verstehen, deshalb wird diese im folgenden Abschnitt anhand der MIB-2 erklärt. Definiert ist diese wie weiter oben schon erwähnt in der RFC1213. Da die MIB-2 insgesamt knapp 50 Seiten lang ist wird

6 Hinweis: Die Instanz ist nicht immer durchgehend nummeriert.



hier der Einfachheit halber nur eine der 10 Gruppen erklärt, da diese vom Aufbau her iden-tisch sind.

RFC1213-MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [14]; -- MIB-II (same prefix as MIB-I) mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- textual conventions DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having -- SIZE (0..255) PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets. -- groups in MIB-II system OBJECT IDENTIFIER ::= { mib-2 1 } interfaces OBJECT IDENTIFIER ::= { mib-2 2 } at OBJECT IDENTIFIER ::= { mib-2 3 } ip OBJECT IDENTIFIER ::= { mib-2 4 } icmp OBJECT IDENTIFIER ::= { mib-2 5 } tcp OBJECT IDENTIFIER ::= { mib-2 6 } udp OBJECT IDENTIFIER ::= { mib-2 7 } egp OBJECT IDENTIFIER ::= { mib-2 8 } -- historical (some say hysterical) -- cmot OBJECT IDENTIFIER ::= { mib-2 9 } transmission OBJECT IDENTIFIER ::= { mib-2 10 } snmp OBJECT IDENTIFIER ::= { mib-2 11 }



Die Definition beginnt mit dem Namen der MIB (::= definiert ein Objekt). In diesem Falle also RFC1213-MIB. Dieser folgt der IMPORT Abschnitt. Die hier erwähnten Objekte werden von anderem RFC Definitionen importiert. Hier also mgmt, NetworkAdress, IpAddress, Counter, Gauge, TimeTicks aus der RFC11557. Der Titel dieser RFC lautet „Structure and Identification of Management Information for TCP/IP-based Internets“. In ihr ist der exakte Aufbau von Managed Objects definiert. Ein kurzer Auszug zeigt fol-gendes.

As of this writing, the DoD has not indicated how it will manage its subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will allocate a node to the Internet community, to be administered by the Internet Activities Board (IAB) as follows: internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1. This memo, as a standard approved by the IAB, now specifies the policy under which this subtree of OBJECT IDENTIFIERs is administered. Initially, four nodes are present: directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 }

Anfangs wird internet als die OID 1.3.6.1 deklariert, im Anschluss noch die Subtrees da-von. Dadurch das mgmt in die RFC1213 importiert wird, weis diese welche OID damit angesprochen wird. Ein paar Zeilen weiter steht noch der Ausdruck

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

dadurch wird jedes Mal wenn in der RFC1213 mib-2 erwähnt wird auf die OID 1.3.6.1.2.1 verwiesen. Die restlichen Importe sind Definitionen von Dateitypen.

NetworkAddress ::= CHOICE { internet IpAddress } IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)

7 http://www.ietf.org/rfc/rfc1155.txt



Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)

Counter, Gauge und TimeTicks sind z.B. als 32Bit Integer Werte festgelegt.

Der folgende Teil aus der RFC1213 bezieht sich auf die Definition der System Gruppe. -- the System group -- Implementation of the System group is mandatory for all -- systems. If an agent is not configured to have a value -- for any of these variables, a string of length 0 is -- returned. sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 } sysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'." ::= { system 2 } sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } sysContact OBJECT-TYPE



SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The textual identification of the contact person for this managed node, together with information on how to contact this person." ::= { system 4 } sysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name." ::= { system 5 } sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The physical location of this node (e.g., `telephone closet, 3rd floor')." ::= { system 6 } sysServices OBJECT-TYPE SYNTAX INTEGER (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "A value which indicates the set of services that this entity primarily offers. The value is a sum. This sum initially takes the value zero, Then, for each layer, L, in the range 1 through 7, that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs primarily routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values should be calculated accordingly: layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 internet (e.g., IP gateways) 4 end-to-end (e.g., IP hosts) 7 applications (e.g., mail relays) For systems including OSI protocols, layers 5 and 6 may also be counted." ::= { system 7 }



Die Gruppe System enthält 7 Subtrees (sysDescr, sysObjectID, sysUpTime, sysContact, sysName, sysLocation, sysServices). Die weiteren Details werden Anhand von sysDescr erklärt.

OBJECT-TYPE wurde aus der RFC1212 importiert. In ihr ist definiert wie MIBs geschrieben werden

SYNTAX beschreibt den Datentyp. Im Falle von sysDescr also ein String mit 255 Zeichen.

ACCESS beschreibt die Art des Zugriffs. Möglich sind read-only, read-write, write-only und not-accessible.

STATUS hier steht ob das Objekt vorhanden sein muss (mandatory), optional (optional) oder überholt (obsolete) ist.

DESCRIPTION enthält die genaue Beschreibung des Objektes, hier also die Sys-tembeschreibung.

Am Ende wird dem Objekt noch eine OID zugewiesen. ::= { system 1 }. Es besitzt da-durch die OID 1.3.6.1.2.1.1.1. Greift nun jemand per SNMP auf diese OID zu enthält er als Antwort die in Ihr gespeicherte Systembeschreibung.

Analog dazu verhalten sich alle weiteren MIB Definitionen. Besitzt man eine Netzwerk-komponente die SNMP fähig ist, kann durch lesen der herstellerspezifischen MIB heraus-gefunden werden welche SNMP Funktionen diese unterstützt. Jeder Hersteller und auch jede Privatperson kann bei der IANA (Internet Assigned Numbers Authority) eine eigene enterprise OID beantragen und unter dieser weitere Funktionen bereitstellen.

Beispiele sind:

Cisco iso.org.dod.internet.private.enterprises.cisco oder 1.3.6.1.4.1.9 HP 1.3.6.1.4.1.11 Novell 1.3.6.1.4.1.23 Microsoft 1.3.6.1.4.1.311

Alle aktuell vergebenen (~32000 Stand 09/2008) enterprise OIDs kann man unter der fol-genden Adresse einsehen. http://www.iana.org/assignments/enterprise-numbers



2.4 Versuchsdurchführung

Starten Sie die Virtuelle Maschine sofern noch nicht geschehen über die VMware Work-station Konsole. Nach das System gestartet ist loggen Sie sich als Benutzer „root“ mit dem Passwort „fh“ ein

2.4.1 Konfiguration des Netzwerks und Installation der Pakete Am Anfang wird die Verbindung zum Internet über das Gateway hergestellt. Um die Netzwerkverbindungen unter Linux aufzulisten nutzt man den Befehl ifconfig (unter Windows lautet selbiger ipconfig). Dieser listet alle Netzwerkcontroller und deren Para-meter auf. Sind mehrere Netzwerkkarten vorhanden, so werden diese vom Betriebssystem aufsteigend nummeriert (eth0, eth1,...). Die Schnittstelle lo steht für den Loopback. Netzwerkkonfiguration

Die Studierenden müssen nun den Netzwerk-Adapter welcher an den Switch angeschlos-sen ist, mit folgendem Befehl konfigurieren:

ifconfig ethx 192.168.0.2x netmask 255.255.255.0 broadcast 192.168.0.255 mit x ε [1,2,3,…]

für ethx trägt man die aktive Netzwerkkarte ein. Falls in einem Rechner mehr als eine Netzwerkkarten aktiv sind, zieht man kurz das angeschlossene Netzwerkkabel ab und ver-bindet es anschließend wieder. Daraufhin erscheint eine Meldung auf der Konsole in wel-che Karte das Kabel gesteckt wurde. Bei der IP der Netzwerkkarte hält man sich am Na-men des Servers (Debian1 = .21,...)

Nachdem die IP-Adresse festgelegt wurde, muss man die Gateway IP-Adresse auf jedem PC als Route hinzufügen, da sonst keine Verbindung mit dem Internet hergestellt werden kann.

route add default gw 192.168.0.1

Ob der Internetzugang funktioniert, testet man per ping www.google.de . Falls man eine Antwort bekommt funktioniert der Internetzugang (Abbruch per Strg+C).

Zum Abschluss ändert man noch den Hostnamen seines Systems mit dem Befehl

hostname debianX mit x ε [1,2,3,…]

Installation der Pakete

Als nächstes müssen die SNMP-Komponenten unter Linux installiert werden. Debian und Ubuntu verwenden dafür den Paketmanager Aptitude8. Die wichtigsten Funktionen davon werden per apt-get Befehl [Paketname] aufgerufen. Als Option steht u.a. zur Verfügung

install installiert das angegebene Paket. remove löscht das Paket, behält allerdings die Konfigurationsdatei. dist-upgrade führt ein Distributionsupdate durch. upgrade aktualisiert die installierten Pakete

8 Aptitude ist ein Frontend für das Advanced Packaging Tool (APT). Es zeigt eine Liste von Software-Paketen an und erlaubt dem Benutzer, interaktiv Pakete zu verwalten. (Wikipedia)



update neue Liste von Paketen einlesen

Das Paketverzeichnis selbst kann man per apt-cache search ... durchsuchen.

Für den folgenden Versuch benötigen wir die Pakete snmp (Tools) und snmpd (Agent). Installieren sie diese auf ihrem Rechner.

apt-get install snmp snmpd

Bei der Installation erkennt das Programm das schon eine Konfigurationsdatei vorhanden ist und frägt nach ob er diese Überschreiben soll. Wählen Sie hier „N“. Nach der Installati-on überprüfen sie die Installation mit dem Befehl

snmpwalk -v1 -c public localhost mib-2.system

2.4.2 Konfiguration der SNMP-Agenten Nach der Installation der SNMP Pakete wurde der SNMP Dämon vom System automatisch gestartet, allerdings mit Zugriffsbeschränkungen, weshalb der Zugriff auf den SNMP- Agenten nur lesend erfolgen kann. Deshalb sollen die Studierenden im Anschluss eine ei-gene Community erstellen um damit später weitere Aktionen durchführen zu können. Die Konfiguration der Zugriffsrechte erfolgt über die Datei snmpd.conf im Verzeichnis /etc/snmp und erfolgt in 3 Schritten. Zuerst wird der Communitystring, also das Passwort mit dem man auf die Agenten zugreifen kann festgelegt. Weiterhin kann man einen IP-Bereich mitgeben aus welchem Zugriffe stattfinden dürfen. Diese Festlegung von Commu-nity und IP-Bereich nennt man security name. Im Nächsten Schritt wird der erstellte secuirty name einer Gruppe zugeordnet. Hier wird auch festgelegt welche SNMP Protokollversionen unterstützt werden. Zuletzt werden noch per access Befehl die Lese- und Schreibrechte für die erstellten Grup-pen zugewiesen. Konfiguration der Linux-Hosts

Jetzt muss die Datei snmpd.conf bearbeitet werden. Öffnen sie die Datei mit einem Text-editor z.B. vi snmpd.conf oder nano snmpd.conf .

Die Kommentare am Anfang wurden gekürzt

…

####

# First, map the community name (COMMUNITY) into a security name

# (local and mynetwork, depending on where the request is coming

# from):

# sec.name source community

#com2sec paranoid default public

com2sec readonly default public

com2sec readwrite default private

####

# Second, map the security names into group names:

# sec.model sec.name

group MyROSystem v1 paranoid

group MyROSystem v2c paranoid



group MyROSystem usm paranoid

group MyROGroup v1 readonly

group MyROGroup v2c readonly

group MyROGroup usm readonly

group MyRWGroup v1 readwrite

group MyRWGroup v2c readwrite

group MyRWGroup usm readwrite

####

# Third, create a view for us to let the groups have rights to:

# incl/excl subtree mask

view all included .1 80

view system included .iso.org.dod.internet.mgmt.mib-2.system

####

# Finally, grant the 2 groups access to the 1 view with different

# write permissions:

# context sec.model sec.level match read write notif

access MyROSystem "" any noauth exact system none none

access MyROGroup "" any noauth exact all none none

access MyRWGroup "" any noauth exact all all none

# -----------------------------------------------------------------------------

Der Rest der Datei wurde ebenfalls gekürzt

Am Anfang der Datei stehen Kommentare welche das Wichtigste erklären. Zeilen die mit einer Raute beginnen werden als Kommentare interpretiert und vom System nicht beachtet.

Als erstes muss mittels com2sec ein frei wählbarer Securityname festgelegt werden. Sour-ce steht für die IP-Adresse bzw. den IP-Adressbereich, von der der Zugriff gestattet wird. Die Community ist ebenfalls frei wählbar. Die Syntax lautet:

com2sec <securityname> <source> <community>

Als nächstes muss der gerade erstellte Securityname einer Gruppe zugewiesen werden. Dies geschieht mit Hilfe des group Befehls weiter unten in der snmpd.conf.

group <groupname> <version> <securityname>

Den Gruppennamen können Sie selbst bestimmen, allerdings müssen Sie für jede SNMP Version einen eigenen Eintrag erstellen.

Zum Abschluss werden der Gruppe noch Zugriffsrechte zugewiesen. Dies geschieht mit Hilfe des access Befehls, gefolgt von dem Gruppennamen und sieben Parametern. Wichtig für den Versuch sind sec.model, read und write.

access <groupname> context <sec.model> sec.level match <read> <write> notif

Das Sec.Model gibt an für welche SNMP Version die Rechte gelten (v1, v2c, v3 oder any), die Schreib und Leserechte werden mit read bzw. write gesetzt. Die restlichen Werte blei-ben unverändert, da diese nur für SNMPv3 gültig sind.

2.4.3 Anwendungsaufgabe zur SNMP-Konfiguration



Erstellen Sie einen eigenen Securityname für den Bereich 192.168.0.0/24, weisen diesen einer Gruppe zu und erteilen Sie dieser Lese und Schreibrechte. Einigen Sie sich in Ihrer Gruppe auf eine gemeinsame Community!

Überprüfen der Konfiguration

Auf der Konsole muss der Befehl netstat -nulp eingegeben werden. Netstat ist ein Kommandozeilentool welches die aktiven Netzwerkverbindungen (Sockets) auflistet. Die Ausgabe kann über Parameter beeinflusst werden. Die hier verwendeten Parameter haben folgende Bedeutung:

n listet die IP-Adressen statt der symbolischen u zeigt nur UDP Verbindungen l zeigt nur offene Sockets p listet das zugehörige Programm mit auf

Nach der Befehlseingabe erscheint eine ähnliche Ausgabe wie auf Bild 2-10.

Bild 2-10: netstat

Sollte in der Zeile mit dem snmpd-Dienst unter „Local Address“ 127.0.0.1 stehen bedeutet dies, dass der Zugriff auf den Dienst nur von lokaler Seite aus erlaubt ist, also vom System selbst.

Der globale Zugriff, also der Zugriff von jedem System das auf den PC zugreifen kann wird aktiviert, indem die Datei /etc/default/snmpd bearbeitet wird. In ihr steht die Zeile SNMPDOPTS=... am Ende steht hier 127.0.0.1. Löschen sie den Zahlenwert und starten daraufhin auf der Konsole den Dienst neu. Dadurch wird die Zugriffsbeschränkung aufge-hoben und der Zugriff von anderen Systemen ist möglich

/etc/init.d/snmpd restart

Nach erneuter Eingabe von netstat –nulp steht unter Local Address 0.0.0.0. Der snmpd-Dienst ist nun für alle Teilnehmer erreichbar.

Testen Sie nun Ihre Konfiguration, indem Sie per snmpget die Systembeschreibung eines benachbarten Linux Systems abfragen mit sysDescr.0 oder mib-2.system.1.0. Protokolie-ren Sie das Ergebnis anhand eines Screenshots.

Bild 2-11: Antwortbeispiel



2.4.4 Lesen einer herstellerspezifischen MIB mit Hilfe eines MIB-Browsers Nun soll anhand der MIB eines Herstellers erklärt werden, welche Werte ein snmpwalk auf den Printserver liefert. Starten sie den MIB-Browser auf dem Windows Desktop und geben Sie unter Address: 192.168.0.10 an. Klicken sie auf die Schaltfläche Advanced… und geben als read und write Community public ein. Als OID wird .1.3.6.1.4. gewählt und unter operations walk. Die Angabe der Instanz ist bei einem snmpwalk überflüssig, da dieser sämtliche Untergruppen der MIB durchläuft. Nach drücken von Go gleicht das Ergebnis Bild 2-12

Bild 2-12: Snmpwalk auf den enterprise tree des Printservers

Aufgabe: Erklären sie die ersten 4 Zeilen der Antwort des Printservers anhand der DP-301U.mib.

ftp://ftp.dlink.de/dp/dp-301u/driver_software/DP-301u_mib_revALL_100_ALL_en_040909.zip

2.4.5 SNMP-Protokollanalyse mit Hilfe von Wireshark Die Analyse kann wahlweise unter Windows oder Linux durchgeführt werden. Entschei-den Sie sich für eine bevor Sie weitermachen. Protokollanalyse unter Linux

Starten sie Wireshark per tshark -V -f "port 161“ | tee /tmp/ergebnis1 & . Wireshark erstellt nun eine Datei ergebnis1 im Verzeichnis /tmp welche sie am Ende per Disket-te/USB Stick speichern können.



Bild 2-13: tshark

Das & Zeichen sorgt dafür, dass Wireshark im Hintergrund ausgeführt wird. Schicken Sie jetzt einen SNMP-Request an ein benachbartes System mit der OID sysName.0 woraufhin eine Antwort ähnlich Bild 2-13 eintreffen sollte.

Mit dem Befehl fg bringt man das Programm tshark wieder in den Vordergrund und be-endet es per Strg+C.

Aufgabe: Erklären sie in ihrer Ausarbeitung die entstandenen Frames. Protokollanalyse unter Windows

Starten sie Wireshark vom Desktop aus. Unter dem Menüpunkt Capture/Interfaces… er-scheint ein Dialogfenster. Wählen sie den Button Optionen bei der aktiven Netzwerkkarte ihres PCs. Im folgenden Fenster wird unter Capture Filter „port 161“ eingetragen, siehe Bild 2-14

Bild 2-14: Einstellen des Capture Filters für das Logging desw SNMP Datentransfers

Nach dem Drücken von Start erscheint das Hauptfenster und überwacht den Verkehr auf Port 161. Minimieren sie Wireshark und rufen Sie den MIB-Browser auf.



Auf der linken Seite des MIB Browsers sieht man alle eingebundenen MIBs. Beim erstma-ligen Ausführen sind das die HOSTS9 und die MIB-2. Durch Klicken auf selbige kann man sich die MIB genauer anschauen und findet dort auch eine Beschreibung zur jeweiligen OID. Siehe auch Bild 2-9.

Als nächstes wird das Optionsfenster unter Tools/Options aufgerufen und der Tab Agents gewählt. Hier stehen die dem Programm bekannten SNMP-Agenten. Fügen sie einen der benachbarten Debian Server mit der zugehörigen „read-“ und „write-“ Community hinzu und bestätigen Sie dies.

Bild 2-15: Hinzufügen der Agenten

Im Hauptfenster zurück kann jetzt per Rechtsklick auf einen beliebigen MIB Wert ein GET-Request gesendet werden (z.B. sysDescr in Bild 2-16).

Bild 2-16: Antwort eines Agenten

Nachdem sie eine Antwort erhalten haben wechseln sie zurück zu Wireshark. Dort sind zwei Frames eingegangen die dem Bild 2-17 ähneln.

9 http://www.faqs.org/rfcs/rfc2790.html Die HOSTS MIB enthält allgemeine Informationen zum Betriebs-system, dem Speicher und den Komponenten eines Systems



Bild 2-17: SNMP Pakete in Wireshark

Aufgabe: Speichern bzw. Drucken Sie das Ergebnis und erläutern Sie die entstandenen Frames.

2.4.6 Trap-Management mit Protokollanalyse Bis jetzt wurden SNMP Befehle immer manuell aufgerufen. Für die effektive Überwa-chung eines Computernetzwerks ist es allerdings notwendig, dass Systeme und Geräte au-tomatisch eine Fehlermeldung erzeugen, sobald sich ein kritischer Zustand einstellt. Auf diese Weise wird der Administrator sofort über entstandene Probleme wie den Ausfall ei-ner Festplatte oder den Verlust einer Netzwerkverbindung informiert. Zur Lösung dieser Aufgabe wurden die SNMP-Traps eingeführt.

Bild 2-18: Beispiel verschiedener Traps

Gateway

Webserver

Switch

Zeit

Internetverbindung unterbrochen

Last zu hoch

Datenbank voll

Trap

NMS



SNMP-Traps sind automatisch generierte Pakete, die an einen eingestellten Netzwerkma-nager versendet werden, sobald etwas Unvorhergesehenes eintritt. In unserem Fall soll der Switch so konfiguriert werden, dass er einen Trap sendet, sobald eine Verbindung zu Ihm Hergestellt bzw. getrennt wird. Konfiguration des Cisco Switch

Zuerst muss eine Verbindung zu Switch C via Hyperterminal hergestellt werden. Nutzen sie dazu einen beliebigen Windows PC und verbinden ihn per V24-Kabel mit dem Konso-lenport des Switch (Einstellungen HT: 9600,8,N,1). Eine genauere Anleitung finden sie in dem Dokument HyperTerminalSitzung.pdf welches ebenfalls mit dem Versuch ausgelie-fert wird.

Auf dem Switch wechselt man dann per enable und configure terminal in den CISCO Konfigurationsmodus. Dort gibt man folgende Zeilen ein:

snmp-server enable traps snmp linkdown linkup

snmp-server host 192.168.0.x [community]

Aufgabe: Protokollieren Sie Ihre Eingabe anhand eines Screenshot

Bild 2-19: Verbinden eines PC mit dem Konsolenport eines Cisco Switch



Bild 2-20: Konfiguration des Switch

In der ersten Zeile aktiviert man die SNMP Traps des Cisco Routers für die Events linkup und linkdown. In der zweiten Zeile wird der Netzwerkmanager (IP-Adresse eines Win-dows PCs der Praktikumsgruppe) zusammen mit dem zugehörigen Communitystring an-gegeben. Trapüberwachung

Starten Sie nun Wireshark wie im letzten Abschnitt erklärt, ändern jedoch den Port von 161 auf 162. Entfernen sie das Netzwerkkabels von einem der Debian-Server für ein paar Sekunden und stecken es wieder ein.

Erklären sie anhand des Wireshark Ergebnisses was genau passiert ist.



3 TEILVERSUCH2: ÜBERWACHUNG DER VERFÜGBARKEIT VON NETZWERKKOMPONENTEN UND DIENSTEN MIT NAGIOS

3.1 Ziele Erstellen einer Netzwerküberwachung mit Hilfe des Netzwerkmanagementsystems Nagios.

3.2 Aufgabenbeschreibung Die Studierenden werden eigene Host- und Service-Checks definieren sowie Plugins zur Überwachung von Netzwerkkomponenten einbinden.

3.3 Einführung in die NMS-Architektur anhand von Nagios

NMS (Nagios)

Switch

Windows Host

Linux Host

Apache

FTP

Postfix

DNS

SSH

HTTP

Link

Host‐Checks Service‐Checks

Bild 3-1: Nagios Prinzip

Nagios ist eine frei erhältliche Software für Linux http://www.nagios.org und dient zur Überwachung von Netzwerkkomponenten (Hosts) und deren Diensten (Services). Ziel der Software, ist es den Administrator(en) einer Netzwerkumgebung schnell über kritische Zu-stände zu benachrichtigen. Was kritische Zustände sind legt der Administrator vorher in der Konfiguration fest.

Eine übersichtliche Webseite http://192.168.0.2x/nagios/ (Benutzername und Passwort lau-ten nagios) informiert hierbei über den Zustand der einzelnen Hosts und Services via Am-pelsystem. Grün (OK) bedeutet keinerlei Probleme, gelb (WARNING) weist auf eventuelle Gefahren hin, während rot (CRITICAL) über kritische Zustände informiert.

Nagios bietet die Möglichkeit im Fehlerfall Netzwerkadministratoren automatisch per Email oder Telefon/SMS zu benachrichtigen, was besonders wertvoll außerhalb der Ge-schäftszeit ist. Bei der Überprüfung selbst unterscheidet Nagios zwischen Host-Checks und Service-Checks. Unter einem Host versteht man ein physikalisch vorhandenes Gerät (Server, Dru-cker,…). Ein Service ist ein Dienst der auf einem Host läuft. Nagios überprüft den Zustand der Hosts über sog. Host-Checks. Ein solcher testet einen Rechner auf seine Erreichbarkeit, wofür in der Regel einfach ein Ping (ICMP) verwendet wird. Ein Service-Check prüft dagegen gezielt den Status von laufenden Diensten (Apache, DNS, ...) sowie von laufenden Prozessen (z.B. CPU-Last). Host-Checks führt Nagios nur



durch falls kein zu überwachender Dienst erreichbar ist. Sofern ein Service erreichbar ist, gilt dies auch für den kompletten Rechner weshalb die Prüfung entfallen kann. Im folgenden Bild ist die Architektur auf der Nagios aufbaut grafisch dargestellt10.

Zur Erläuterung der Grafik dient die folgende Tabelle check_xyz hier wird per Plug-In der Dienst direkt Abgefragt check_by_ssh wird verwendet um lokale Plug-Ins über eine Secure Shell auf

einem entfernten Server aufzurufen check_nrpe der Nagios Remote Plug-In Executor (NRPE) dient ebenfalls zur

Ausführung von Plug-Ins auf entfernten Servern (ebenfalls verschlüsselt)

snmp SNMP Abfrage von Servern NSCA der Nagios Service Check Acceptor führt im Gegensatz zu den

anderen keinen Check aus sondern wartet auf Ergebnisse die er von anderen Hosts gesendet bekommt.

Der Unterschied zwischen check_by_ssh und check_nrpe liegt im Detail. Der Vorteil des ssh-Checks liegt darin das kein weiterer Port in der Firewall geöffnet werden muss. Weiterhin muss kein eigener Dienst auf dem Zielserver laufen, da die Daten über den ssh-Daemon gesendet werden. Allerdings benötigt man einen eigenen Shell-Benutzer. Bei dem NRPE-Check muss auf dem Zielserver der NRPE Daemon installiert werden und für diesen ein Port auf der Firewall geöffnet werden. Ein eigener Shell-Benutzer wird allerdings nicht benötigt. Falls mehrere Checks auf einem Server ausgeführt wer-den sollte der NRPE verwendet werden da dieser eine geringere Last verursacht.

10 Quelle: http://www.tu-chemnitz.de/urz/kurse/unterlagen/rsrc/nagios1.jpg

Bild 3-2: Check-Möglichkeiten in Nagios



3.3.1 Definieren von Objekten in Nagios In Nagios wird ein Host, ein Service, ein Kontakt, eine Gruppe und auch ein Kommando als „Objekt“ definiert. Der Grund liegt in der Vererbung der Eigenschaften, die in Nagios möglich ist. Den Zusammenhang der Konfigurationsdateien zeigt Bild 3-311

Einen Blick in /etc/nagios zeigt Bild 3-4.Das Verzeichnis enthält 3 Config Dateien, das Verzeichnis mysite und eine Passwortdatei. Bild 3-4: /etc/nagios

Erklärung der Dateien:

nagios.cfg: Legt diverse Grundeinstellungen für Nagios fest cgi.cfg: Definiert das Aussehen des Webfrontends von Nagios resource.cfg: Hier werden Makros festgelegt.

Bild 3-5: /etc/nagios/mysite

Das Verzeichnis mysite enthält alle Objektdefinitionen12 ,die für Nagios gültig sind. Nagios wertet jede Datei im Verzeichnis und den Unterverzeichnissen aus, die auf .cfg endet. Der Übersichtlichkeit wegen wurden drei Verzeichnisse erstellt, welche die Host und Service Definitionen für die Linux/Windows Server und den Switch enthalten.

11 Quelle: http://www.sd-project.de/produkte/nagios/infos/nagios-config.gif 12 Was ein Objekt ist wird im Glossar erläutert.

Bild 3-3: Zusammenhang der Konfigurationsdateien



Die hosts.cfg im Verzeichnis linux beinhaltet alle Linux basierenden Hosts siehe auch Bild 3-6. Jeder Host der später im Webfrontend überwacht werden soll, muss vorher definiert werden. Ebenso jeder Service

Bild 3-6: hosts.cfg

Ein Objekt wird immer per define deklariert. In diesem Fall handelt es sich um ein Host Objekt. In der Definition eines Hosts muss folgendes stehen:

host_name: Name der in Nagios für den Host erscheint address: IP des Hosts max_check_attempts: Anzahl der Wiederholungen bis Fehler gemeldet wird check_period: Überwachungszeitraum (hier 24Stunden/7Tage) contact_groups: Kontakte die benachrichtigt werden falls ein kritischer

Zustand eintritt notification_interval: Minuten bis die Fehlermeldung wiederholt wird. notification_period: Benachrichtigungszeitraum notification_options: Zustände über deren Eintreten Nagios informieren soll

d: down u: unreachable (fällt ein Netzwerkknoten aus erhalten die Hosts dahinter den Status unreachable) r: recovery (OK-Zustand nach Fehler) f: flapping (Zustand wechselt ständig) s: scheduled downtime (Wartungszeitraum)

Die weiteren Attribute sind optional. So wird mit

alias dem Host eine erweiterte Beschreibung zugeteilt check_command gibt das Kommando an mit dem der Host geprüft wird

(Diese werden in der Datei commands.cfg definiert). parents bestimmt den übergeordneten Netzwerkknoten icon_image enthält das Icon das der Host in der Weboberfläche er

hält.

In der Datei hostgroups.cfg werden einzelne Hosts zu Gruppen zusammengefasst. Dies macht vor allem bei großen Netzwerkumgebungen Sinn um eine bessere strategische Übersicht zu erhalten (z.B. alle Webserver, alle SAP-Server, alle Server in Gebäude A,…)

In der folgenden Abbildung wurde die Hostgroup debian-servers erstellt mit den Mitglie-dern debian1 und debian2.



Bild 3-7: hostgroups.cfg

Die Dateien contacts.cfg und contactgroups.cfg in /etc/nagios/mysite sind vom Aufbau fast identisch zu den hosts* Dateien, nur mit dem Unterschied das in ihnen die Kontaktper-sonen festgelegt werden.

Für die Überwachung von Diensten werden Services definiert. Dies geschieht in der Datei services.cfg.

Bild 3-8: Auszug aus der Datei services.cfg

Hier wird den Hosts debian1, debian2 und nagios der Service PING zugeordnet. Dieser wird dann im Nagios Portal dargestellt und überwacht, siehe Bild 3-9. Die Überwachung erfolgt mit dem Nagios-Plug-In check_ping. Auf dem Portal selbst ist das Linke Frame für die Navigation zuständig. Auf der rechten Seite sieht man den aktuellen Status der Hosts. debian1 ist momentan nicht erreichbar und wird deshalb rot dargestellt. Im oberen rechten Feld sieht man noch eine Zusammenfassung aller Hosts und Services der Netzwerkumge-bung und deren momentanen Status.

Definiert wird dieser Plug-In in der Datei commands.cfg im Verzeichnis mysite. Die Werte hinter dem Ausrufezeichen legen die Schwellen für den WARNING Zustand (Antwort >100ms oder Packetloss >20%) und den CRITICAL Zustand (Antwort >500ms oder Pa-cketloss > 60%)

Bild 3-9: Serviceübersicht als Website des Nagios Portals

In dem Verzeichnis /etc/nagios/mysite/switches wird analog zu /linux die Netzwerkhard-ware definiert. Ebenfalls per Hosts.cfg, Hostgroups.cfg und Services.cfg. Im Verzeichnis



/etc/nagios/mysite/windows wird der Windows Server konfiguriert. Im Gegensatz zu der bisherigen Vorgehensweise allerdings nur in einer Datei windows.cfg. Dies ist problemlos möglich da Nagios sich nur für den Inhalt der .cfg Dateien interessiert und man somit auch alle Hosts einer großen Config-Datei definieren könnte. Sinnvoll ist diese Methode bei größeren Installationen allerdings nicht, da die Übersichtlichkeit sehr darunter leidet.

3.3.2 Was ist ein Nagios-Plug-In? Ein großer Vorteil von Nagios ist sein modularer Aufbau. Der Kern enthält keinen einzigen Check. Dazu werden externe Programme, sogenannte Plug-In verwendet. Zur Grundaus-stattung gehören die Plug-Ins für die wichtigsten Anwendungszwecke. Was man darüber hinaus benötigt, kann man entweder selbst Programmieren oder kostenlos über das Internet beziehen. http://nagiosexchange.org/ Ein Plug-In ist ein kleines einfaches Programm oder Skript, welches einen der Vier Zu-stände OK, WARNING, CRITICAL oder bei der Übergabe von unbekannten Optionen UNKNOWN ausgibt. Dadurch kann Nagios prinzipiell alles prüfen was elektronisch mess- oder zählbar ist (Temperatur, Unbefugtes Betreten eines Raumes,…). Voraussetzung ist man findet einen Weg diese Daten für den Computer verwertbar darzustellen. Plug-Ins selbst werden durch Commands aufgerufen. Anhand von Bild 3-10 wird die Funktionsweise erläutert.

Bild 3-10: Nutzung eines PlugIns per Command

Die Abbildung zeigt einen Ausschnitt der commands.cfg Datei. Der Command check-host-alive wird definiert und als Befehlszeile wird $USER1$/check_icmp mitsamt Parametern übergeben. $USER1$ ist eine Variable die in der resource.cfg festgelegt wird. In ihr ist der Pfad zum Plug-In-Verzeichnis gespeichert $USER1$=/usr/local/nagios/libexec. Die Para-meter lauten wie folgt:

-H: IP Adresse des Zielrechners ($HOSTADDRESS$ ist eine interne Variable welche die IP in der Hostdefinition übernimmt)

-w: Warnschwelle in Millisekunden oder Paketverlust in Prozent -c: Schwelle, die den kritischen Zustand angibt

Man kann denselben Check auch per Hand durchführen. Dazu wechselt man unter Linux in das Verzeichnis und gibt folgenden Befehl ein

cd /usr/local/nagios/libexec ./check_icmp -H 192.168.0.23 -w 3000.0,80% -c 5000.0,100%

Bild 3-11: Verschiedene ICMP Checks



In Bild 3-11 wurden drei Checks mit jeweils anderen Schwellenwerten durchgeführt. Be-achten Sie, dass Nagios je nach Schwellenwert einen anderen Zustand zurückliefert.

3.4 Versuchsdurchführung Der Einfachheit halber wurde das System schon installiert. Die Studierenden müssen sich im weiteren Verlauf nur um das Customizing von Nagios kümmern.

3.4.1 Hinzufügen von neuen Hosts und Services Aufgabe: Fügen sie den Server Debian3 als Host der Hostgroup debian-servers hinzu und weisen sie ihm den Service Ping zu.

Tipp: nachdem die Config Dateien bearbeitet wurden, überprüfen Sie diese auf Fehler mit folgendem Befehl: /usr/local/nagios/bin/nagios -v /etc/nagios/nagios.cfg

Nagios überprüft dadurch die einzelnen Konfigurationsdateien auf Syntaxfehler. Ist die Konfiguration fehlerfrei kann mit /etc/init.d/nagios restart

Nagios neu gestartet und auf dem Portal die Änderungen begutachtet werden (Ergebnis per Screenshot dokumentieren).

Aufgabe: Ändern Sie nun in der services.cfg den Wert normal_check_interval von 5 auf 1. Dies ändert den Zeitraum in dem ein Check ausgeführt wird von fünf Minuten auf einer Minute. Ziehen Sie das Netzwerkkabel eines der Server und erklären sie welche Zustände auf dem Portal angezeigt werden.

Aufgabe: Entfernen sie das Patchkabel welches den Switch C mit dem oberen Switch des Herstellers KTI verbindet. Welchen Zustand nehmen die Server in Nagios ein? Was hat dieser zu bedeuten?

3.4.2 Nutzung des Nagios SNMP-Plug-Ins Der nächste Schritt des Versuchs umfasst die Erstellung eines eigenen Commands, mit dem Ziel den Festplattenspeicherplatz zu überwachen. Dazu wechseln wir auf dem Nagios Server in das Verzeichnis /etc/nagios und öffnen die Datei resource.cfg. In dieser werden Makros definiert, ähnlich der Umgebungsvariablen in Windows. $USER1$ enthält das Verzeichnis zu den Nagios Plug-In. Eine Auflistung aller Plug-Ins inklusive der Anleitung zu Ihnen findet man unter http://nagiosplugins.org/man.

Ändern sie den Wert von $USER3$ in den Communitystring den Sie in Abschnitt 2.1.3 vergeben haben (z.B. $USER3$=public). Vergessen Sie nicht die # am Zeilenanfang zu entfernen da dies sonst als Kommentar gesehen wird. Speichern und verlassen Sie die Da-tei. Erstellen sie danach eine Datei commands.cfg unter /etc/nagios/mysite/linux, identisch zu Bild 3-12.

Bild 3-12: commands.cfg

Erklärung siehe in Kapitel 3.3.2. Neu sind hierbei die folgenden Parameter, die nur für das SNMP-Plug-In gültig sind.

C ist der Communitystring der eben hinterlegt wurde.



P steht für die SNMP Version o für den Wert der MIB der abgefragt werden soll (in diesem Fall die

Festplattenauslastung). l setzt das Präfix der Antwort u setzt das Suffix der Antwort welche im Nagiosportal zum Rückgabewert

angezeigt wird.

Im Gegensatz zur Definition des check_icmp Commands werden hier die Schwellenwerte nicht direkt angelegt sondern per Argument übergeben. Dies geschieht in der Servicedefi-nition.

Öffnen Sie die nun die Datei services.cfg und fügen sie die folgenden Zeilen hinzu

Bild 3-13: Definition eines neuen Services in der Datei services.cfg

Wichtig ist die Zeile check_command. Hier wird das so eben erstelle Kommando namens check_hdd angewendet. Die Zahlen nach dem ! werden von Nagios als Argument inter-pretiert. Deshalb auch $ARG1$ und $ARG2$ in der Definition des Commands. Mit 0:80 legen wir fest dass der Zustand Warning auftritt sobald der Rückgabewert außerhalb des Bereichs 0…80 liegt. Ebenso der Zustand Critical. Speichern und beenden Sie die Datei.

Überprüfen Sie die Konfiguration mit

/usr/local/nagios/bin/nagios -v /etc/nagios/nagios.cfg

Sofern keine Fehler aufgetreten sind, wird Nagios neu gestartet.

/etc/init.d/nagios restart

Wechselt man nun mit dem Browser auf das Nagios Portal sind die Änderungen unter dem Punkt Service Detail ersichtlich.

Bild 3-14: Nagios mit selbst erstelltem Service.



Aufgabe: Drucken sie einen Screenshot für ihre Ausarbeitung aus. Weshalb wurde die Festlegung der Schwellenwerte in der Service- statt in der Commad-Definition durchge-führt?

4 TEILVERSUCH 3: ÜBERWACHUNG DER PERFORMANCE EINES NETZWERKS

4.1 Ziele

Das Ziel des letzten Teilversuchs ist es den Studierenden einen Überblick in der Nutzung von Performancedaten zu geben, mit der Absicht später eine Performanceüberwachung des Netzwerks graphisch darzustellen.

4.2 Aufgabenbeschreibung

Anfangs wird die die Nagios Konfiguration abgeändert, so dass die Sammlung der Perfor-mancedaten aktiviert wird. Danach werden diese mit Hilfe des Tools PNP grafisch darge-stellt. Zum Abschluss des Versuchs wird die Countervariable IfInOctets des Cisco Switch ausgelesen und dadurch eine Traffic Überwachung generiert.

4.3 Welchen Zweck haben Performance-Daten? Bisher wurden in Nagios nur „Zustände“ angezeigt, die Rückschlüsse auf die Verfügbar-keit von Netzwerkteilnehmern und deren Diensten zugelassen haben. Daraus lässt sich zwar schnell erkennen, welcher Service oder Host wann ausgefallen ist, Statistiken über die Netzwerk- oder die CPU Auslastung eines System können auf diese Weise allerdings nicht gewonnen werden. Soll die Performance eines Systems herausgefunden werden, so ist es nötig die relevanten Daten über einen längeren Zeitraum hinweg zu erfassen.

Nagios ermöglicht dies durch die Auswertung der Antworten von Service Checks. In der folgenden Bild sieht man die Antwort auf eine check_icmp Anfrage. Diese frägt die Ant-wortzeit eines Systems ab.

Die Form der Antwort ist standardisiert, und somit für fast alle Plug-Ins gleich. Die Per-formancedaten selbst kommen nach dem |-Zeichen in der Form

name=wert;warning;critical;min;max

Anfangs steht der Name der Variable und der Rückgabewert (in diesem Fall die Latenzzeit von 0,115 Millisekunden). Danach folgen die Schwellen für die Zustände Warning und Critical und schließlich das Minimum und das Maximum.

Das Ziel lautet nun, diese Werte in eine Datenbank zu speichern, um diese später grafisch auszuwerten. Dazu müssen die Konfigurationsschritte im folgenden Abschnitt vorgenom-men werden.

4.4 Versuchsdurchführung

4.4.1 Konfiguration von Nagios Zuerst muss die Datei /etc/nagios/nagios.cfg modifiziert werden. Suchen sie die Zeile pro-cess_performance_data und setzen Sie den Wert auf 1. Dies aktiviert die Verarbeitung von Performancedaten.



Zusätzlich wird das Kommando zum Verarbeiten der Performancedaten in der Datei nagi-os.cfg angegeben.

Die hier referenzierten Kommandos müssen auch Nagios bekannt gemacht werden. Dazu wird die Datei /etc/nagios/mysite/commands.cfg bearbeitet.

Damit von Nagios schnell auf die Graphen zugegriffen werden kann, erstellen wir noch zwei Templates. Diese sorgen dafür dass, auf dem Nagiosportal neben dem Hostnamen bzw. neben dem Servicenamen ein Link dazu erstellt wird. Bearbeiten sie die Datei /etc/nagios/mysite/templates.cfg und fügen Sie am Ende folgende Zeilen an.

Diese beiden Templates können nun über “use srv-pnp” in der Service-Definition oder “use host-pnp” in der Host-Definition verwendet werden.

Als nächstes folgt die Konfiguration des Web-Frontends von Nagios. Zur grafischen Dar-stellung wird das Tool PNP verwendet http://www.pnp4nagios.org/. Seine Konfigurati-onsdatei liegt unter /usr/local/nagios/etc/pnp/config.php. Die Datei ist eigentlich selbster-klärend. Die einzige Änderung, die Erstellung einer neuen Ansicht für den Performance-graphen muss am Ende der Datei angefügt.

Aufgabe: Fügen sie einen fünften view hinzu der für die Zeitdauer von 10 Minuten gilt. Die Art und Weise wie ein view erstellt wird können Sie aus der zu editierenden Datei he-rauslesen.

Wechseln sie jetzt mit Ihrem Browser auf den link http://192.168.0.2x/nagios/pnp und se-hen sich ihr Ergebnis an.



Bild 4-1: PNP nach erfolgreicher Konfiguration

Wählen sie einen Host und einen Service in einer vernünftigen Zeitspanne, und drucken das Ergebnis für ihre Ausarbeitung aus. Mit einem Klick auf das eingekreiste rote A unter Search kann auch eine PDF-Datei des Graphen erstellen werden.

4.4.2 Auswertung von Countervariablen Als letzten Teil des Versuches wird eine Traffic Überwachung für den Switch erstellt. Die-ser enthält einen internen Counter für jeden einzelnen Port. Mit dem MIB Browser können die Werte angesehen werden.

Bild 4-2: Counter-Variablen

In der obigen Bild sieht man, dass es verschiedene Arten von Counter gibt. So z.B. die An-zahl der empfangenen, der verworfenen, der fehlerhaften Pakete etc. in unserem Fall wol-len wir den Traffic an Port 25 (Uplink zum anderen Switch) Monitoren. Zu diesem Zweck verwenden wir das Nagios Plugin check_snmp_int. Es ist Teil der Nagios-SNMP-Plug-



Ins welche unter http://nagios.manubulon.com/ erhältlich sind. Die Plug-Ins sind der Ein-fachheit halber schon auf dem System installiert. Weitere Plug-Ins sind in der folgenden Tabelle aufgelistet.

check_snmp_storage checks storages (disks, swap, memory, etc...)

check_snmp_int checks interface states, usage on hosts, switch, routers, etc....

check_snmp_process checks if process are running, the number that are running, memory and cpu used.

check_snmp_load checks the load or the cpu of a machine

check_snmp_vrrp checks the interface state of vrrp cluster

check_snmp_cpfw checks Checkpoint Firewall-1 status

check_snmp_mem Checks memory and swap usage

check_snmp_win Checks windows services

check_snmp_css Checks css services state

check_snmp_env Checks environemental status (fan, temp, power supply).

Tabelle 4-1: Inhalt des Nagios-SNMP-Plugins Pakets

Aufgabe:

Die Verwendung wird unter http://nagios.manubulon.com/snmp_int.html erklärt. Der erste Schritt ist wieder die Definition des Commands. Dazu fügen wir der Datei /etc/nagios/mysite/commands.cfg die folgenden Zeilen hinzu:

Der Aufbau ist fast identisch zu Punkt 3.4.2. Neu ist der Parameter –n, welcher den abzu-fragenden Netzwerkadapter angibt. Da dieser von System zu System unterschiedlich ist wird er mit einem Argument übergeben welches später in der Servicekonfiguration festge-legt wird.

Nun wird noch ein dazugehöriger Service erstellt. Zum einen in der Datei switch.cfg im Verzeichnis /etc/nagios/mysite/switches/.

Zum anderen in der Datei /etc/nagios/mysite/linux/services.cfg.



In der switch.cfg wird dem Command mit FastEthernet0/24 die Schnittstelle auf dem Switch übergeben (Port24, in unserem Fall der Uplink). Der Parameter

f aktiviert die Performancedatenausgabe k schreibt die Bandbreite dazu w definiert die WARNING Schwelle c definiert die CRITICAL (der erste Wert für die InPackets, der zweite für die Out-

Packets). label ist optional und schreibt nur In/Out vor das Ergebnis.

In der services.cfg wurde eth0 als Argument gewählt, also der erste Netzwerkadapter auf den Linux Hosts.

Nachdem die Konfiguration abgeschlossen ist testen sie diese wieder mit

/usr/local/nagios/bin/nagios -v /etc/nagios/nagios.cfg

Falls kein Fehler auftritt wird Nagios neu gestartet.

/etc/init.d/nagios restart

Zurück auf der Weboberfläche sehen sie das Ergebnis wie in Bild 4-3

Bild 4-3: Nagios mit Performancedaten

Achtung! Unmittelbar nach dem restart von Nagios kann es vorkommen, dass der Service mit dem Status Unknown angezeigt wird und der Status Information: No usable Data on File (X rows). Das liegt daran das Nagios die ersten fünf Minuten noch Daten zur Auswer-tung sammelt. Warten sie in diesem Fall einfach kurz ab. Da normalerweise wenig Traffic im Netzwerklabor entsteht wird mit dem Befehl

Ping –f 192.168.0.1

Ausgeführt von den jeweiligen PCs etwas nachgeholfen. Nach einer kurzen Zeit stellt sich pro Netzwerkkarte ein Traffic von ca. 250kb/s ein. Auf dem Switch selbst ein etwas mehr als doppelt so großer Wert.



Win 2003192.168.0.1(Gateway)

Debian 1192.168.0.21

Debian 2192.168.0.22

KTI Switch

Cisco 2950(Switch C)192.168.0.33

Überwachungspunkt

Überwachungspunkt

Überwachungspunkt

Bild 4-4: Performanceüberwachte Lan-Verbindung

Lassen sie den ping ein paar Minuten laufen, und erstellen Sie dann ein PDF des Traf-ficgraphen. Fügen sie dies Ihrer Ausarbeitung hinzu.

Aufgabe: Finden Sie auf zwei Arten heraus wie viele eingehende Pakete am Port24 des Switch verworfen wurden. Für den ersten Lösungsweg nutzen Sie den MIB Browser, für den zweiten Lösungsweg verwenden Sie das check_snmp_int Plugin. Die richtigen Para-meter finden Sie in der Anleitung von selbigem.



Bild 4-5: Trafficgraph Beispiel

4.5 Abzuliefernde Ergebnisse a.) Die Screenshot und Ausdrucke der einzelnen Teilaufgaben b.) Die Beantwortung der Fragen in der Versuchsdurchführung c.) Warum verwendet SNMP das UDP Protokoll? d.) Welche Probleme könnten bei der Überwachung von sehr großen Netzwerken auftre-

ten? e.) Welches Problem hat man bei der Überwachung mit Countern in Bezug auf die Genau-

igkeit? f.) Der Switch speichert die Counterwerte in einer 32Bit Variable, welches Problem tritt

hierbei auf g.) Welche generellen Sicherheitsprobleme hat SNMP

5 LITERATURVERZEICHNIS

Davin, J. R. (1990, Mai). RFC1157 - Simple Network Management Protocol (SNMP). Retrieved from RFC1157 - Simple Network Management Protocol (SNMP): http://tools.ietf.org/html/rfc1157#section-4

McCloghrie, K., & Rose, M. T. (1991, März). RFC1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II. Retrieved 09 23, 2008, from RFC1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II: http://tools.ietf.org/html/rfc1213



6 FEEDBACKFORMULAR

trifft voll zu

trifft überhaupt nicht zu

Die Dokumentation ist verständlich. o-----------o------------o------------o------------o------------o

Teilversuch 1: INSTALLATION UND KONFIGURAION DER SNMP-AGENTEN

trifft voll zu


Die Versuchsbeschreibung ist verständlich. o-----------o------------o------------o------------o------------o

Der Versuch konnte in der vorgegebenen Zeit durchgeführt werden. o-----------o------------o------------o------------o------------o

Die Lernziele wurden erreicht o-----------o------------o------------o------------o------------o

Verbesserungsvorschläge

Teilversuch 2: ÜBERWACHUNG DER VERFÜGBARKEIT VON

NETZWERKKOMPONENTEN UND DIENSTEN MIT NAGIOS

trifft voll zu trifft überhaupt

nicht zu Die Versuchsbeschreibung ist verständlich. o-----------o------------o------------o------------o------------o



Verbesserungsvorschläge



Teilversuch 3: ÜBERWACHUNG DER PERFORMANCE EINES NETZWERKS

trifft voll zu


Die Versuchsbeschreibung ist verständlich. o-----------o------------o------------o------------o------------o



Verbesserungsvorschläge:

labor für university of applied sciences netzwerktechnik und … · 2009-04-26 · 2.4.5...

Documents