Netzwerkmanagement 0 Motivation für den Einsatz von ... · 1.2 Aufgaben des Netzwerkmanagements...

1

Netzwerkmanagement

0 Motivation für den Einsatz von Netzwerkmanagement ........2 1 Aufgaben des Netzwerkmanagements.................................11

1.1 Gegenstand und Einordnung des Netzwerkmanagements ..................................11 1.2 Aufgaben des Netzwerkmanagements (FCAPS) .................................................11

1.2.1 Fehlermanagement (Fault Management) ......................................................14 1.2.1.1 Vorgehen bei der Fehlerbehebung.............................................................16 1.2.1.2 Informationssammlung / Problemdefinition.................................................16 1.2.1.3 Auswahl und Einsatz von Messtools ..........................................................16 1.2.1.4 Problemlösung............................................................................................16 1.2.1.5 Eskalation...................................................................................................17 1.2.2 Konfigurationsmanagement (Configuration Management) ............................18 1.2.3 Abrechnungsmanagement ............................................................................20 1.2.4 Leistungsmanagement (Performance Management).....................................21 1.2.5 Sicherheitsmanagement (Security Management)..........................................22

1.3 Managementsysteme...........................................................................................23 1.3.1 Der Bedarf für das Netzwerkmanagement ....................................................23 1.3.2 Management Domains ..................................................................................24 1.3.2 Aufbau eines Netzwerk-Managementsystems (Topological Framework) ......26 1.3.3 Management Application Domains ................................................................28

1.4 Überblick über Netzwerkmanagementmodelle.....................................................29 1.4.1 Common Management Information Protocol (CMIP).....................................29 1.4.2 Simple Gateway Monitoring Protocol (SGMP)...............................................29 1.4.3 Das SNMP-Modell .........................................................................................30

2 Das Netzwerk Management Modell SNMP ...........................31

2.0 Vortrag SNMP, RMON und DMI ..........................................................................31 2.1 Das OSI-Organisationsmodell des Netzwerkmanagements (ISO 10040) ............39

2.1.1 Die Management Station ...............................................................................40 2.1.2 Das Agent Processing ...................................................................................41

2.2 Managed Objects und MIBs.................................................................................41 2.2.1 Mangaged Object ..........................................................................................42 2.2.2 Die Management Information Base (MIB) .....................................................44

2.3 ASN.1 als Beschreibungssprache für MIB-Objekte..............................................48 2.4 Austauschparadigmen für Managementinformationen.........................................50 2.5 Aufbau einer SNMP-Nachricht .............................................................................51 2.6 Authentifikation einer SNMP-Nachricht ................................................................53

3. Using MIB...............................................................................54

3.1 Download der MIB-Browser und MIB-Files ..........................................................54 3.1.1 Download des MIB-Browsers ........................................................................54 3.1.2 Download der MIB-Files ................................................................................54

3.2 MIB Examples......................................................................................................55 3.2.1 MIBs supported by Switch Catalyst 2950 series............................................55 3.2.2 Router MIB Support Lists ..............................................................................56

3.3 SNMP Configuration on CISCO 2600 Router ......................................................58 4 Relevante Links ......................................................................59

2

Document History

Version Date

Author(s) Email-Adress

Changes and other notes

29.6.2005 [email protected]

0 Motivation für den Einsatz von Netzwerkmanagement

Dr.-Ing. Ludwig EckertPage 1

Aktuelle Situation in der Automatisierungstechnik

Warum Netzwerkmanagement?

Struktur von Netzwerkmanagementsystemen?

Wie funktioniert Netzwerkmanagement (SNMP)?

Benefits

Referenzen

Netzwerkmanagementin der

Automatisierungstechnik

Dr.-Ing. Ludwig Eckert

Beispiel: Verfahrenstechnische Anlage aus der Chemie

3

Dr.-Ing. Ludwig Eckert

Profibus DPV1, ≤ 12 Mbit/s

Feld

eben

e ContransFB

Ex

PLC (SPS)

DPDPPAPA

. . .

Profibus PA, 31,25 kbit/s

TZID Flow

GatewayF-Net

HART

ConventionalI/OBoards

Temperature transmitter

p/dptransmitter

Actuator

Sensor/Actuator:

WS

Composer

O-Net

X-Terminals/ PC-Clients

X-Net

Printer

X-Net

Printer

Workstation (WS)Leite

bene

. . .

Steu

erun

gs-

eben

e

C-Net (C)

C-Net (O)

Process Station CMC

Gateway CCO

. . .

Architektur von Prozeßautomatisierungssystemen


Aktuelle Entwicklungen

• Komponentenzahl wächst sprunghaft=> höheres Ausfallrisiko (Π Pi)

• Komplexität und Funktionalität der IT- Komponenten nimmt zu=> längere Diagnose- und Remote-Session Zeiten

• Komponenten werden an Auslastungsgrenzen betrieben=> Überlastprobleme in Kommunikationsnetzen häufen sich

4


Planbarkeit

Verfügbarkeit

Erweiterbarkeit

Redundanz

Spezielle Netzwerktechnologien

System-/Netzwerkmanagement


Einsatz struktureller Redundanz

Proc

ess

Con

trol

Plan

t Man

agem

et L

ayer

Redundante Applikationz. B. Archiv

RedundanteProzeßrechner

RedundanteGateways

RedundantesPower Supply

Redundantes Netzwerk

RedundanterFeldbus

(2 bus coupler)

5


CCOx(Ethernet Based PLC)

WS

Redundancy Manager

Flow Meter

WS

Hirschman Rail-Switches RSX

Profibus

CCOxCMCx

HMI

Ethernet Switching

Fiber, Coax or Twisted Pair

Rail Switch10/100TX/TX

FieldbusFoundation H1

Rail Switch10/100

TX/FX(SM)

Rail Switch10/100

TX/FX(SM)

Rail

Switc

h10

/100

TX/T

X

B2

B3B4

B1

Spezielle Technologien: Ring-Redundanz Netzwerk



Fiel

d D

evic

e La

yer

ContransFB

Ex

PLC (SPS)

DPDPPAPA

. . .


TZID Flow

GatewayF-Net

HART



p/dptransmitter

Actuator

Sensor/Actuator:

ComposerRemote PC

O-Net


X-Net

Printer

Workstation (WS)

Plan

t Man

agem

et L

ayer

. . .

C-Net (C)

C-Net (O)

Process Station CMC

Gateway CCO

. . .

Pro

cess

Con

trol

Composer

Agent

MIB

Agent

MIB

Agent

MIB

Agent

MIB

Manager

Agent

MIB

Agent

MIB

Agent

MIBAgent

MIBAgent

MIB

Agent

MIB

Agent

MIB

Gateway CCO

Einsatz zentraler System- und Netzwerkmanagement Tools

6



Fiel

d D

evic

e La

yer

ContransFB

Ex

PLC (SPS)

DPDPPAPA

. . .


TZID Flow

GatewayF-Net

HART



p/dptransmitter

Actuator

Sensor/Actuator:

ComposerRemote PC

O-Net


X-Net

Printer

Workstation (WS)

Plan

t Man

agem

et L

ayer

. . .

C-Net (C)

C-Net (O)

Process Station CMC

Gateway CCO

. . .

Pro

cess

Con

trol

Composer

Agent

MIB

Agent

MIB

Agent

MIB

Agent

MIB

Manager

Agent

MIB

Agent

MIB

Agent

MIBAgent

MIBAgent

MIB

Agent

MIB

Agent

MIB

Gateway CCO

Einsatz zentraler System- und Netzwerkmanagement Tools


AgentProgramm in einer Automatisierungs- oder Netzkomponente• sammelt Status-Daten in der Komponente und stellt diese in MIBs (Management Information Basis - RFC1213) zur Verfügung

• stellt Informationen für den Manager bereit

ManagerProgramm in einer zentralen Managementkonsole• ruft Informationen von den Agenten ab und stellt sie übersichtlich dar• wertet Statusinformationen statistisch aus • empfängt spontane Ereignisse (Traps) von den Agenten• wirkt über die Agenten auf die Netzkomponenten ein

Komponenten des Manager/Agent-Konzepts

RFC = Request For Comment, vorläufige Internet-Spezifikation mit der Bitte um Kommen-tierung und Ergänzung

7


Simple Network Management Protokoll-Kommandos

• Standardisierte Kommunikation zwischen Manager und Agent• Kommunikationsprotokoll SNMP basiert auf IP und UDP

MIB abfragen

MIB setzen

spontanesEreignis

get Request

get Response

set Request

get Response

Trap

Manager Agent

z.B. Anzahl der gesendetenPakete ermitteln.

Manager <-> Agent

z.B. Konfigurationsänderungder Netzkomponente

z.B. Port einer Brücke Sperren.

Agent -> Manager


root3 - ISO/CCITT Objekte2 - CCITT Objekte 1 - ISO Objekte

0 - standard1 - registration-authority2 - member-body3 - org Objekte anderer internationaler Organisationen

1 - n.n:

6 - dod Objekte des Department of Defense1 - internet Objekte im Internet

1 - directory2 - mgmt Objekte des IAB Internet Architection Board

1 - mib-2 MIB-II Standard3 - experimental4 - private

1 - enterprises Objekte privater Unternehmen1 - Proteon:

248 - Hirschmann

Struktur und Inhalt der MIB (1)• die Datenspeicherung erfolgt auf Agentenseite in einer MIB• beschreibt die Daten, die der Manager beim Agent abfragen und ändern kann• Zugriff über Object-Identifier (OID)

8


Gesucht: Version der Brücken Firmware ?MIB-Objekt: hirmaBasBridgeSoftVersion

OID 1.3.6.1.4.1.248.2.1.1.1.3.0InstanzSoftwareVersionbas = Basis Capabilitiesbridgemnmt = Brückenmanagement bridge1 = Brücke 1bridge = Brückehirma = Hirschmannenterprise = Hersteller spezifischprivate = nicht genormtinternet = Internet Objektedod = Department of Defenseorg = Obj. anderer Organisationeniso = Objekte der ISO

OID Hirma.bridge.bridge1.bridgemnmt.bas.SoftwareVersion.0

Bsp.: Abfrage eines MIB-Objekts


Struktur und Inhalt der MIB (2): MIB-II Gruppen

9


Logfiles / EventLogsz.B. Applikationen, Systemlogs(Unix/NT)

Schwellwertüberprüfungz.B. Filesystem, Prozesse, Platten

Netzwerk-Alarme(“Traps”)z.B. Hirschman RSx, printer box...

Applikation / SkriptMeldungenz.B. Eigene Skripte, Smart PlugIns

Korrelatierte Meldungenz.B. Zusammenfassung mehrerer Meldungen

Architektur der Managementkonsole


User Interface des Management Tools (Bsp.)

10


Benefits System-/Netzwerkmanagement

Automatische Erkennung von Totalausfällen von Komponentendurch zyklische Überwachung der Komponenten

Reduzierte Diagnose- und Remote Session Zeitendurch automatisch generierte, fehlergetriggerte Detaildiagnosen und Reports

Fehlerprädiktion / Proaktives Fehlermanagement durch kontinuierliche Beobachtung von Performancedaten und Auswerten der historischen Daten (Trendanalyse)

Detektion von Performance-Engpässendurch Performance-Messung anhand der dynamischen Daten von Komponenten

Planbare „Shut Down“- Zeitendurch proaktives Fehlermanagement und Fehlerprädiktion auf Basis von Trendanalysen der Historien von Komponenten und Alarmen


www.snmpworld.com=> World of SNMP and Network Management

www.protocols.com=> World of Protocols

http://www.ietf.org=> The Internet Engineering Task Force => The list of current Internet-Drafts (RFCs)

Simple Network Management Protocol (SNMP) - Status

http://www.ibr.cs.tu-bs.de=> Institut für Betriebssysteme und Rechnerverbund, Verteilte Systeme

und Netzwerkmanagement, Prof. Dr. Langendörfer

www.bgnw.de=> Benutzergruppe Netzwerk

Referenzen – Zusammenfassung

11

1 Aufgaben des Netzwerkmanagements

1.1 Gegenstand und Einordnung des Netzwerkmanagements In der Vergangenheit konnten die homogenen Büronetze, die mit Komponenten eines Herstellers aufgebaut wurden, auch durch die vom Hersteller angebotenen proprietären Managementsysteme gepflegt und administriert werden. Auf Grund stetig anwachsen-der Netze und das Zusammenwachsen unterschiedlichster Netztypen zu einem Netz-verbund (z.B. Intranet) stießen diese proprietäten Managementsysteme häufig an ihre Grenzen.

Ebenso ist bereits seit einiger Zeit die Entwicklung der industriellen Netze zu immer größeren Netzstrukturen zu beobachten. Die vertikale Integration, wie das Zusammen-wachsen von Industrienetz und Büronetz auch genannt wird, bringt einerseits transpa-renten Durchgriff auf alle Daten, braucht aber andererseits eine ebenso durchgängige Diagnosemöglichkeit.

Gelöst wurden diese beispielhaft angeführten Probleme, als in den 80er Jahren von der Internet Activities Board (IAB) das Simple Network Management Protocol (SNMP) ein-geführt wurde. Mit diesem Standard, der von der Netzwerkindustrie sehr schnell akzep-tiert wurde, werden die grundlegenden Aufgaben eines Netzwerkmanagementsystems erfüllt.

Das Netzwerkmanagement hat die Aufgabe, den ordnungsgemäßen Betrieb eines Netzwerks zu gewährleisten. Der Betrieb eines Netzwerks ist das Zusammenspiel der Funktionen der eingesetzten Netzwerkkomponenten mit dem Verhalten der Endgeräte und deren Installationen.

Die IT Infrastruktur eines Unternehmens besteht aus:

Einer Vielzahl von Klienten- und Server Rechnern, die über Netzelemente mitein-ander verbunden sind,

Prozessen und Verfahren, die im Normal- und im Störfall einen reibungslosen Betrieb ermöglichen,

Einrichtungen, die eine zentrale oder hierarchische Verwaltung der Infrastruktur, sowie ihre Anpassung an sich ständig ändernde Verhältnisse, mit einem Mini-mum an menschlichen Ressourcen ermöglichen.

Definition: Die Summe der Einrichtungen, die zur Steuerung, Verwaltung und Anpassung der IT Infrastruktur dienen, werden als Netzwerk- und System Management (NSM) bezeich-net.

Gegenstand des Netzwerkmanagement sind vor allem Vermittlungs- und Weiterlei-tungssysteme, wie z. B.: Router, Bridges, Hubs, Endsysteme (hosts).

1.2 Aufgaben des Netzwerkmanagements (FCAPS) Die funktionale Bereiche des Netzwerkmanagements betreffen das Fault-, Configura-tion-, Accounting-, Performance- und Securitymanagement, die auch mit dem Akronym FCAPS bezeichnet werden.

12

Bild: OSI-Funktionen des Netzwerkmanagements

Bild: Einsatz von Managementwerkzeugen

13

Bild: Managementbereiche

Page 5HauptvortragNM.ppt 05/2000

Dr. Ludwig Eckert

IT-M

anag

emen

t

Network Management- Device Status / Availability- Network Connectivity / Network

healty reports- Traffic Monitoring / Performance

Checks

Network Management- Device Status / Availability- Network Connectivity / Network

healty reports- Traffic Monitoring / Performance

Checks

E-MailE-MailFinanceFinance Online BankingOnline BankingAccountingAccounting

Supply ManagementSupply Management Online ShoppingOnline ShoppingE-CommerceE-Commerce

Service Management- Business process- Status of Service Level

Agreements (SLA)- Help Desk

Service Management- Business process- Status of Service Level

Agreements (SLA)- Help Desk

SAPSAP DominoDominoInformixInformix ExchangeExchange WWWWWWSQLSQL OracleOracle

Service OfferingsBusiness-Processes

ApplicationServer

HP-UXHP-UXNovellNovell LinuxLinux

IBMIBM

SNI SINIXSNI SINIXSun SolarisSun SolarisWin NTWin NT

Server Hardware

Computer/Clients

Multi-Port Token RingEthernetFDDIATMFast EthernetCISCO HP Bay Networks XXX3COM HP

InternetInternetRouter

Network Infra-

structure

System Management- System Monitoring- Performance - Utilization- Resources

Desktop Management- Software Distribution- Configuration- Inventory- Remote Control Maintenance

System Management- System Monitoring- Performance - Utilization- Resources

Desktop Management- Software Distribution- Configuration- Inventory- Remote Control Maintenance

Application Management- Verfügbarkeit der Prozesse- Performance

Application Management- Verfügbarkeit der Prozesse- Performance

Security

Data Backup

Trend: Wachsende Kundenwünsche...

Bild: Anwendungen und Managementbereiche

14

Netzwerkmanagement Gegendstand des Netzwerksmanagements: →Systeme: vor allem Vermittlungs- und Weiterleitungssysteme • Reuter, Bridges, Hubs, aber natürlich auch die Endsysteme (hosts) Aufgaben → ISO Network Management Model: FCAPS → Fault Management → Configuration Management → Accointing Management → Pervormance Management → Security Management Oft unterschiedliche Systeme und Programme für unterschiedliche Aufgaben

Darüber umfasst das Netzwerkmanagement weitere Aufgaben, wie z. B. das Report Management. Inventory Management, Service Management (SLA), Policy Manage-ment.

Die einzelnen Managementbereiche (siehe Bild Anwendungen und Managementberei-che) sind nicht strikt voneinander getrennt. Vielmehr können einzelne Funktionen meh-reren Managementbereichen zugeordnet werden. Allgemein gilt jedoch, dass Funktio-nen eines Bereiches die Grundlage für die Funktionen des nächst- höheren Bereiches darstellen.

1.2.1 Fehlermanagement (Fault Management) Um einen einwandfreien, ununterbrochenen Netzwerkbetrieb gewährleisten zu können, muss auf die Funktionalität des Netzes als Ganzes, aber auch jeder einzelnen Kompo-nente geachtet werden Das Fault Management will die Verfügbarkeit des Netzwerkes erhöhen. Die Dienste des Fault Managements umfassen Tests zur Überprüfung von Netzkomponenten bzw. zur Lokalisierung, es können aber auch Fehlermeldungen aus-getauscht oder Fehlerstatistiken

Die Funktionen des Fehler-Managements befassen sich mit abnormen Zuständen im Netzbetrieb und beinhalten drei Aufgabenbereiche:

Erkennen (Fehlerdetektion),

Diagnostizieren (Fehleridentifikation, Fehleranalyase),

Beheben (Fehlerbeseitigung).

Fehlererkennung: Dazu werden in Intervallen Diagnosetests durchgeführt (Polling), oder es wird, sofern möglich, eine Fehlermeldung von einem Managed Object an den Manager gesendet (Trapping).

Tritt ein Fehler auf, so ist es wichtig, folgende Schritte möglichst schnell auszuführen:

15

a) Exakt feststellen, woran der Fehler liegt.

b) Isolation des restlichen Netzwerkes von der Störungsstelle, so dass es ohne Un-terbrechung weiter verwendet werden kann.

c) Modifikation oder ReKonfiguration des Netzwerkes, um eine Verwendung der fehlerhaften Komponente(n) zu minimieren oder Umschalten auf redundante Netzkomponenten.(z. B. Umleiten des Datenverkehrs über einen anderen Router durch entsprechenden Eintrag in der Routingtabelle oder der Access Liste)

d) Reparatur oder Austausch der fehlerhaften Komponenten, um das Netzwerk wie-der in seinen ursprünglichen Zustand zu bringen.

Fehlerdiagnose: um die Art und die Ursache des Fehlers zu erforschen, müssen die Aktivitäten der Objekte aus den Ereignis- und Fehler-Reports analysiert und ggf. Diag-noseprogramme gestartet werden.

Zur Fehlerbehebung bedient sich das Fault Management der Dienste des ConBildation Managements, startet passende Fehlerbehebungs-Programme oder fordert einen akti-ven Eingriff des Administrators.

Wenn der Fehler korrigiert wurde und das System sich wieder in seinem ursprünglichen Zustand befindet, muss der Administrator sicherstellen, dass das Problem auch tat-sächlich beseitigt wurde und dabei keine neuen Probleme entstanden sind.

Fault Management (1) Management von im Netz auftretende Fehlfunktionen Ziel: Aufrechterhaltung oder schnellstmögliche Wiederherstellung des Netzbetriebs beim Eintritt von Fehlfunktionen → Erkennung von Fehlfunktionen → Protokollierung von Fehlfunktionen, → Benachrichtigung der Betroffenen Benutzer und Betreuer über erkannte Fehlfunktion → Behebung der Fehlfunktionen Motivation: Ausfall von Netzdienste kann zu hohen unerwartete Kosten und anderen Nachteile für Betreiber und Benutzer führen

Benutzer erwarten schnelle und zuverlässige Problemlösungen. Durch die Verwendung von schnellen und zuverlässigen Fehlerverwaltungstechniken. Die Verwendung syste-matischer Vorgehensweisen bei der Fehlersuche.

16

1.2.1.1 Vorgehen bei der Fehlerbehebung Um einen Fehler schnell zu analysieren und zu beheben, ist es wichtig systema-tisch an das Problem heranzugehen. Nach einer ausführlichen Informations-sammlung kommen evtl. Messtools für die zusätzliche Informationsgewinnung zum Einsatz.

Nach der Problemidentifikation folgt die Lösung. Evtl. ist es notwendig an einer bestimmten Stelle im Problemlösungs-Prozess zu eskalieren.

1.2.1.2 Informationssammlung / Problemdefinition Zu Beginn ist es wichtig, das Problem wirklich richtig einzuordnen. Nur wenn man den wahren Fehler gefunden hat, sollte man handeln. Folgende Fragestellungen können hier weiterhelfen:

• Wobei tritt der Fehler auf? - während der Datensicherung, immer beim Drucken etc.

• Welche Systeme sind betroffen? – das gesamte Netzwerk, nur ein Gebäude, nur eine Etage, ein Endgerät, alle Windows-Rechner etc.

• Wann tritt der Fehler auf? - ständig, zu einer bestimmten Zeit

• Welche Netzkomponenten sind betroffen? - alle, eine bestimmte Bauart etc.

• Welche Anwendungen sind betroffen? - alle, SAP, Oracle etc.

• Wie sieht mein Netzwerk aus? - Netzwerkdokumentation

• Wurde am Netzwerk etwas geändert? - Software-Upgrade, Hardware-Tausch etc.

• Ist das Problem reproduzierbar?

• Gab es schon einmal ähnliche Probleme?

Für den Fall, dass das so ermittelte Wissen nicht ausreicht, muss man sich wei-tere Informationen verschaffen. Dies geschieht oft mit Hilfe von Netzmessungen.

1.2.1.3 Auswahl und Einsatz von Messtools Das Ziel dieser Stufe ist die Fehlereingrenzung. An dieser Stelle gilt es, be-stimmte Fehlermöglichkeiten auszuschließen. Für die Entscheidung über den Einsatz der Mess-Werkzeuge können folgende Fragestellungen weiterhelfen: • Welche Informationen liegen bereits vor? • Welches Tool kann was? Bei Problemen im Netzwerk können natürlich auch Messungen im Netzwerk er-schwert, verfälscht oder unmöglich gemacht werden.

1.2.1.4 Problemlösung In diesem Schritt wird nun das Problem gelöst, in dem die Fehlerquelle/Ursache beseitigt wird. Ist dies geschehen, findet eine Prüfung statt um sicherzugehen, dass der Fehler nicht mehr vorhanden ist.

17

Nachdem das Problem gelöst ist, sollte eine genaue Dokumentation von Ursa-che, Auswirkungen und Lösung vorgenommen werden. Bei neuen Problemen kann man dann auf diese Erfahrungen zurückgreifen. Natürlich sollten auch die Veränderungen in einem Logbuch festgehalten werden.

1.2.1.5 Eskalation Ist es notwendig mehr Ressourcen für die Problemfindung /-lösung einzubinden, wird das Problem eskaliert. Dies geschieht meist über den Vorgesetzten. Folgende Informationen müssen bei einer Eskalation zur Verfügung stehen:

• Beschreibung der Fehlersituation • Netzwerkdokumentation • Zugang zu Messtools • Konfigurationen der Netzwerkkomponenten • Physikalischer Zugang zu den Netzwerkschränken/-komponenten • Passwörter für den Zugriff • Was wurde bereits geprüft? Was hat es gebracht?

Fault Management (2) Vorwiegende Aktionen → Bearbeitung eingehender Meldungen aus dem Netz (traps) → Durchführung von „health checks“ für Systeme und Netzwerke (polling) Bewältigung mit vielfältigen Systemlösungen, Anwendungen und Modulen Behebung von Fehlern nur begrenzt automatisiert. → Bestimmung der Symptome → Isolation des Fehlers → Behebung des Fehlers → Test der Fehlerbehebungsmaßnahmen → Dokumentation der Fehlerinstanz, der Umstände und der Behebungsmaßnahme

Isolation eines Fehlers Typische Situation: → Ein Fehler in einer unteren Netzwerkschicht tritt auf. → Aufgrund der Schichtstruktur treten in den höheren Schichten große Mengen von Fehlern auf. → Beim Fault Management-System geht eine Flut von Fehlermeldungen ein.

18

Vorgehensweise: → Automatischer Filter für eingehende Fehlermeldungen, die auf der Korrelationen von Ereignissen beruhen → Automatische Filter, die auf dem Prinzip des Verursachers in der untersten Schichten arbeiten. → Der Erfahrene Blick des Betreuers Einige Softwarelösungen schlagen sogar nach der Isolation Fehlerbehebungsmaßnahmen vor.

1.2.2 Konfigurationsmanagement (Configuration Management) Das Konfigurationsmanagement bietet dem Netzwerkadministrator die Möglichkeit, Kontrolle über das System bzw. Netz auszuüben.

Das Konfigurationsmanagement will die im Netz vorhandenen Komponenten überwa-chen, deren Bestandteile und Einstellungen kontrollieren und ggf. verändern. Die Konfi-guration von bestimmten Netzkomponenten bestimmt das Verhalten des Datennetzwer-kes.

Deswegen umfasst das ConBildation Management alle Funktionen, die im Zusammen-hang mit Konfigurationsdaten stehen: Sammeln und Darstellen, Kontrollieren und Aktu-alisieren von bestimmten Konfigurationsparametern.

Folgende Aspekte zählen ebenso zum Konfigurationsmanagement:

• Existenz und Namen von Netzkomponenten

• Technische Daten von Netzkomponenten

• Beziehungen zwischen Netzkomponenten

• Status (aktiv/inaktiv) von Netzkomponenten

• Adressierungen

• Routing-Kontrolle

Spezielle Softwaretools sind in der Lage (teil-)automatisiert die Konfiguration eines Netzwerkes, der Rechnersysteme und der darauf applizierten Anwendungen zu erfas-sen, zu protokollieren und zu archivieren (Inventory Management).

19

Configuration Management Die Konfiguration ist die wichtigste Aufgabe des Netzwerkmanagements. (Fast) alle Vorgänge beim Management der Netzwerkkonfiguration müssen mit den anderen Managementsystemen (und den Betreuern) koordiniert werden. Aufgaben → Installation neuer Systeme → Installation von Software-Updates → Installation neuer Module → Installation neuer Anwendungen und Dienste → Regelmäßiger Abgleich (ist - soll) der Konfiguration

Configuration Management: Inventory Management Inventarisierung aller Geräte → Router, Switches, Bridges, Hubs → Leitungen, Netzanschlüsse → Zugangsgeräte (Modems, Gateways,...) Grundlage für die Planung von Optimierungen und Erweiterungen Übliche Softwarelösungen sind Datenbanken, die das Inventar selektiv darstellen können.

Cofiguration Management: Traffic Management Konfiguration von Parametern für die Verkehrssteuerung Ziele: → Vermeidung von Stauungen im Datenfluss → Minimierung von Intensität, Ausdehnung und Dauer von Stauungen Bereiche des traffic management:

→ Provisioning : Konfiguration von Verbindungen und Übertragungsstrecken → Connection Admission Control ( CAC ): Zulassungskontrolle von Benutzern zu Diensten

20

→ Unsage Parameter Control: Überprüfung der Einhaltung eines Service Level Agreement (LSA) durch den Benutzer → Priority Control: Welche Pakete oder andere Daten werden bei Überlast zuerst gelöscht ?

→ Traffic Shaping

1.2.3 Abrechnungsmanagement Die Funktionen des Accounting Management möchten die Nutzung von Netzwerk-ressourcen quantifizieren bzw. die mit dem Netzwerk erbrachten Leistungen benutzer-bezogen identifizieren und abrechnen (Gebührenverwaltung). Um die Kosten, die durch das Netzwerk entstehen zu decken, muss dessen Verwendung berechnet und bezahlt werden.

Die Zuteilung von benötigten Ressourcen erfolgt durch die Vergabe von Prioritäten und Benutzerrechten. Eventuell sind Limits zu setzen, nach deren Überschreitungen der Zugang zum Netz eingeschränkt wird. Die Funktionen beinhalten auch den Austausch von Kosteninformationen.

Der Netzwerkadministrator sollte zu jedem Zeitpunkt feststellen können, welche Anwen-dungssoftware, welcher Benutzer oder welche Benutzergruppe das Netzwerk verwen-det, und zwar aus folgenden Gründen:

• Ein Benutzer oder eine Benutzergruppe missbraucht Zugriffsprivilegien und belastet das Netzwerk unnötig auf Kosten der anderen Benutzer. (z. B. Web-Radio, Video-Onlinestreaming etc.)

• Benutzer können das Netzwerk ineffizient verwenden, so dass der Netzwerk-administrator sie dabei unterstützen kann, einzelne Prozeduren zu verändern, um die Leistung zu verbessern.

• Der Netzwerkmanager kann die Erweiterung des Netzwerkes besser planen, wenn er die Benutzeraktivitäten und die Netzwerkverwendung in ausreichen-dem Maße kennt.

Accounting Management Erfassung der Benutzung des Netzwerks, so dass Personen, Gruppen oder Unternehmen die Benutzung in Rechnung gestellt werden kann. Je nach Netzwerk kann die Erfassung und Rechnungsstellung die primäre geschäftliche Grundlage für den Betrieb des Netzes sein. Abrechnungsmodelle schwanken stark abhängig von der Art des Netzwerks und dem Betriebsort.

21

1.2.4 Leistungsmanagement (Performance Management) Das Performance Management überwacht die Leistungsfähigkeit der einzelnen Sys-teme und des gesamten Netzes. Moderne Datenkommunikationsnetzwerke bestehen aus vielen und unterschiedlichen Komponenten, die miteinander kommunizieren und Daten sowie Ressourcen teilen müssen. Falsche Konfigurationen der Netzkomponen-ten sowie eine ungünstige Wegewahl des Datenverkehrs können zu Datenengpässe (sog. bottle necks) führen. Solche Engpässe müssen frühzeitig festgestellt und besei-tigt werden. Aus diesem Grund und um die Leistungsfähigkeit zu verbessern, enthält das Performance Management Funktionen, die die statistischen Informationen bzgl. der Leistungsfähigkeit des Systems abrufen können und die Konfiguration von Netzkompo-nenten modifizieren (-> Konfigurationsmanagement).

Insbesondere moderne Anwendungen wie Netmeeting, Voice-over-IP oder Multimedia-Streaming-Anwendungen stellen hohe Anforderungen an die Performance eines Netz-werkes und der entsprechenden Server und Applikationen. Genaue Informationen über die durchschnittliche und schlechteste Verzögerungszeit, die Antwortzeit, der minimale und maximale Durchsatz sowie die Zuverlässigkeit von Netzwerkdiensten sind hier wichtige Kriterien, die letztlich die Qualität des Dienstes bestimmen.

Netzwerkadministratoren benötigen Durchsatzstatistiken zur Planung, zur Fehlersuche und zur Verwaltung von großen Netzwerken. Ebenso dienen sie auch dazu, potentielle Engpässe zu entdecken und geeignete Verbesserungsmaßnahmen anzuwenden, noch bevor sie den Endbenutzern Probleme bereiten.

Der Bereich des Performance Management beinhaltet somit Funktionen zur quantitati-ven Analyse und Bewertung relevanter Kommunikationsprozesse. Die Funktionen sam-meln ständig die über Polling oder Trapping erhaltenen Informationen und ermöglichen eine benutzerdefinierte Anzeige und Auswertung.

Dazu muss der Administrator in der Lage sein,

• selbständig Grenzwerte und Pollingfrequenzen zu bestimmen,

• Leistungsreports über alle wichtigen Variablen zu generieren und dazu den

• Zeitraum zu bestimmen, über den sich diese Reports erstrecken sollen.

Für das Performance Management werden typischerweise Echtzeitstatistiken, histo-rische Statistiken (über ein längeren Zeitraum gesammelt) und Gauges (Pegelanzeiger mit Schwellwerten für die automatische Alarmierung) benötigt.

Um bei abnormen Leistungsdaten das Netz-System besser abstimmen zu können, wer-den Funktionen des Konfigurationsmanagements benötigt.

Performance Management Leistungsoptimierung auf der Grundlage von quantitativer Erfassung mehrerer Aspekte der Leistung des Netzes → Netzwerkdurchsatz

22

→ Antwortzeiten → Ausnutzung der Kapazitäten Arbeitsschritte: → Sammeln von Leistungsdaten → Aufstellen von Basisleistungswerten als Maßstab → Festlegung von Grenzwerten für Leistungsparameter, bei deren Überschreitung Maßnahmen zur Optimierung eingeleitet werden sollen. Auch pro-aktive Methoden werden angewendet.

1.2.5 Sicherheitsmanagement (Security Management) Als Security Management wird der Prozess bezeichnet, der die Zugriffsberechtigung auf Netzwerkdaten kontrolliert und schützt. Damit verbunden ist die Generierung, Verteilung und Speicherung von Kodier- und Zugriffsschlüsseln zum Zwecke der Autorisierung und Authentifizierung. Dadurch wird sichergestellt, dass nur autorisierte Benutzer auf die Daten zugreifen können.

Im Falle eines unerlaubten Zugriffs besteht die Möglichkeit, diese Zugriffe aufzuzeich-nen und dadurch die Herkunft der Security-Verletzungen festzustellen und u. U. die ent-sprechende Person festzustellen.

Weiterhin besteht die Möglichkeit, bei unbefugtem Zugriff Alarme automatisiert auszu-lösen.

Die Funktionen des Security Management beziehen sich nur auf die Sicherheit von Diensten und Protokollmechanismen der sieben OSI-Ebenen. Sie sollen vor unberech-tigtem Zugriff auf Datennetze und deren Ressourcen schützen.

Dazu gehören Strategien

gegen nichtautorisierten Datenempfang,

gegen Datenverfälschung bei der Übertragung

und Zugriffsberechtigungen bei der peer-to-peer Kommunikation.

Der Begriff "Sicherheit" hat viele Aspekte, die nicht von einer Management-Norm abge-deckt werden können. In der Praxis überschneiden sich die Aufgaben der vorgenannten fünf Bereiche.

Security Management Kontrolle des Zugangs zu Netzwerkbetriebsmitteln → entsprechend vorgegebener Richtlinien → so dass der Netzwerkbetrieb nicht gefährdet wird (absichtlich oder unabsichtlich)

23

→ so dass Benutzer nicht ohne entsprechende Autorisierung auf vertrauliche Informationen zugreifen können Arbeitsschritte: → Identifikation schützenswerter Betriebsmittel → Vergabe von Zugangsrechten → Überwachung von Zugangspunkten zu schützenswerten Betriebsmitteln

→ Protokollierung von Übertretungen der Zugangsrechte

1.3 Managementsysteme

1.3.1 Der Bedarf für das Netzwerkmanagement Um die gewaltige Anzahl von Kommunikationsressourcen verwalten zu können, wurde das Netz in geographische und administrative Regionen aufgeteilt, um für den normalen Informationsfluss zwischen den einzelnen Netzwerkeinheiten definieren zu können. Wie auch immer diese Aufteilung der Netze geschieht, braucht es Managementsysteme, die für die Überwachung und Kontrolle von Netzwerkressourcen zuständig sind. Neben die-sen zwei wesentlichen Funktionen findet man andere Merkmalen wie das Fault-, Con-Bildation-, Accounting-, Performance- und Securitymanagement, auch FCAPS genannt.

Managementsysteme sind nicht nur Werkzeuge und Technologien, die erlauben, ver-schiedene Netzwerke und Ressourcen zu verwalten. Sie beinhalten auch standardi-sierte Prozeduren und Protokolle darüber, wie Managementinformationen gesammelt und ausgewertet werden. Das gewaltige Wachstum von Netzwerken hat die Rolle von Managementsystemen verändert. Sie sind jetzt Bestandteil der meisten Kommunikati-onstechnologien.

Die reelle Komplexität und Größe von Managementsysteme wird in Umgebungen mit mehreren Protokollen, Geräten unterschiedlicher Hersteller und verschiedenen Techno-logien spürbar. Managementsysteme sollen eine wachsende Anzahl von physischen und logischen Ressourcen verwalten. Das Vorhandensein von verschiedenen (proprie-tären und standardisierten) Architekturen, Betriebssystemen und Kommunikationspara-digmen (Manager / Agent, Remote Procedure Calls (RPC), Distributed Management Interfaces) sind nur ein Teil des Problems. Mit der Migration von zentralisierten Syste-men zu verteilten Client/Server Umgebungen wird die Komplexität der Netzwerkver-waltung ebenfalls erhöht. Eine zusätzliche Komplexitätssteigerung ergibt sich, wenn größere Konzerne die Integration ihrer Netzwerke und lokalen Managementsysteme verfolgen.

Managementsysteme sind Hardware-Komponenten, Software-Applikationen und Pro-zeduren, die folgende Funktionalitäten erbringen: Überwachung, Steuerung, Betrieb, Koordination, Planung, Administration, Verkehrserfassung und Verrechnung im Netz-werk und der Systemressourcen, die eine Kommunikation ermöglichen.

Man kann davon ableiten, dass Managementsysteme nicht nur für die Überwachung und das Controlling geeignet sind, sondern dass sie ebenso komplexe administrative und reporting Funktionen beinhalten.

24

Es existieren verschiedene Merkmale eines Managementsystems. Diese sind verschie-den wichtig, da der Betrachtungswinkel des Benutzers anders als der des Entwicklers ist.

Es werden im Wesentlichen folgende Merkmale unterschieden: Management Domains, Topological Framework, Management Application Domains.

1.3.2 Management Domains Es gibt fünf große Bereiche: Netzwerk Management, Computing System Management, Applikationsmanagement, Datenbankmanagement und Servicemanagement.

Jede dieser Bereiche verwaltet verschiedene Ressourcen. Die Integration dieser Do-mänen ist sehr wichtig, um Managementsysteme zu schaffen und zu benutzen.

Netzwerk-Managements - Network-Maintenance Die unterste Ebene des Netzwerk-Managements ist die Network-Maintenance. Um diese physische Grundlage des LANs zu legen, nutzen Techniker Werkzeuge wie Sei-tenschneider, Abmantelmesser, digitale Multimeter und Netzwerk-Prüfgeräte. Der nächste Level wird ConBildation-Management genannt. Hier gilt es, die physische und logische Anordnung des lokalen Netzwerks zu planen: welche Geräte in einem Netz arbeiten, wie die Komponenten angeschlossen werden und welche Ressourcen freigegeben sein müssen. Der Administrator entscheidet, wie Router einzusetzen sind, ob feste IP-Adressen vergeben werden oder ob ein DHCP-Server zum Einsatz kommt.

Auf der nächsthöheren Stufe befinden sich die Network-Administrators. Diese verwalten das Netzwerk, damit es stabil läuft. Die Aufgabe der Administratoren ist, logische Konfi-gurationen und Service-Operationen auszuführen und zu verbessern. Darüber hinaus bestimmen die Netzwerk-Administratoren die Anzahl der erreichbaren Ports an Swit-ches und Routern und verwalten Clients und Server.

Auf der höchsten Ebene finden sich die Network-User. Für diese bedeutet Manage-ment, sich in das LAN ein- oder auszuloggen und Daten zu bearbeiten.

System-Management

Eng mit dem Netzwerk- ist das System-Management verknüpft. Die Bedeutungen die-ser Begriffe überschneiden sich teilweise. Beide Arten des Managements beinhalten das Sammeln von Daten über Geräte wie Router, Server und Workstations. Beide kümmern sich um Überwachung und Pflege dieser Geräte. Der Unterschied: System-Management betrachtet jedes Gerät als unabhängige Einheit oder als Mitglied in einer logischen Gruppe von Systemen. LAN-Management sieht die einzelnen Geräte als ei-nen Teil des Netzwerks.

System-Management konzentriert sich also auf die Überwachung und Wartung einzel-ner Geräte. Dazu gehören das Installieren und Aktualisieren von Software, Backups, Überwachen der System-Ressourcen, Einrichten von User-Accounts und das (De-)In-stallieren von Systemdiensten.

25

Netzwerk-Management schließt alle Funktionen auf Geräte-Ebene ein, die die Funktio-nalität eines Netzes überwachen und steuern. Komponenten, die keinen Einfluss auf die LAN-Performance haben, fallen in den Bereich des System-Managements. Ein Beispiel hierfür ist ein Drucker, der an einer Workstation angeschlossen ist und nur von dieser benutzt wird.

Bild: Management von verteilten Systemen

Bild: Managementpyramide eines Unternehmens

26

1.3.2 Aufbau eines Netzwerk-Managementsystems (Topological Framework) Wenn man die hierarchische Beziehung zwischen den verschiedenen Komponenten analysiert, lassen sich im Wesentlichen drei Typen von Managementsysteme erkennen:

vollständig zentralisiert (single point management),

logisch zentralisiert und physisch verteilt (manager of manager) und

vollständig verteiltes System (peer-to-peer oder client/server management).

Der erste Frameworktyp weist einen einschichtige Architektur auf und wird somit als “single point management“-Framework bezeichnet.

Bild: “Single Manager” , Quelle [Ghe97]

Generell kann man sich den Aufbau eines Netzwerk-Managementsystems wie nach-folgend skizziert vorstellen:

Bild: Zusammenarbeit NMS und Agent

Der Manager auf der zentralen Workstation, hier mit „Network Management Station“ bezeichnet, kommuniziert mit dem Agenten der managebaren Geräte über das SNMP-Protokoll.

Die auszutauschenden Daten werden auch als Objekte bezeichnet, die in der Gesamt-heit der Management Information Base kurz MIB zusammengefasst sind.

Um auch nicht SNMP managebare Komponenten von zentraler Stelle aus steuern zu können, kommen sogenannte „Proxy-Agents“ zum Einsatz. Sie werden zwischen Net-

27

work Management Station und das Gerät geschaltet. Für die Network Management Sta-tion sieht es somit so aus, als befände sich ein "normaler" Agent in dem zu überwa-chenden Gerät.

Bild: "Manager of Managers", Quelle [Ghe97]


Dr. Ludwig Eckert

Logfiles /EventLogsz.B.Applikationen,Systemlogs(Unix/NT)

Schwellwertüberprüfungz.B.Filesystem,Prozesse,Platten

Netzwerk-Alarme(“Traps”)z.B. Hirschman RSx, printer box...

Applikation / SkriptMeldungenz.B. Eigene Skripte, Smart PlugIns

Korrelatierte Meldungenz.B.Zusammenfassung mehrerer Meldungen

Architecture of local System/Network Management Platforms

Bild: Aufbaustruktur eines „Single Managers“

Die zweite Netzwerk Management Architektur weist zwei oder mehr hierarchische Schichten. Die einzelnen lokalen Element Management Systeme managen dabei einen topologisch abgegrenzten Bereich der IT-Infrastruktur. Die einzelnen Bereiche können sich dabei überlappen (z.B. Redundanz-Strategie).

28


Dr. Ludwig Eckert

Mid-Level Manager

High-LevelManagerMid-Level

Manager

Korrelatierte Meldungenz.B. Zusammenfassung mehrerer Meldungen

IT/O Administrator• Konfiguration von Verantwortlichkeiten, • Eskalations Pfade und Monitoring Parameter

Hierarchical Network-/System Management Structure

Bild: Hierarchische Aufbaustruktur von einem "Manager of Managers" (MOMs)

Der dritte Typ hat die Eigenschaft von eine peer-to-peer Beziehung zwischen benach-barten Managementsystemen.

Bild; "Network of Managers", Quelle [Ghe97]

1.3.3 Management Application Domains Die Managementfunktionen und Managementapplikationen werden typischerweise in fünf Kategorien eingeteilt, dem Fehler-, Konfigurations-, Abrechnungs-, Leistungs- und Sicherheitsmanagement.

29

managing the future

Help-DeskTrouble-Ticketing, Change-Management, Asset-Management

Service-Level-Management, Knowledge-Management

IT-Leitung

NetzwerkmanagementAuto-Discovery, SNMP-Management,

Alarm-Korrelation, Event-Management

Service-Level-Management

Securitymanagement

Desktopmanagement

Komponentenmanagement

Servermanagement

AlarmingPager, eMail, Fax,

SMS, etc.

IT-Personal

Trouble-TicketsHelp-Desk-Client,Web, eMail, Telefon

Anwender

Bild: Managementstrategie eines Unternehmens

1.4 Überblick über Netzwerkmanagementmodelle Als das Internet Mitte der 80er Jahren begann wichtig zu werden, erhöhte sich die Not-wendigkeit für standardisierte Netzwerkmanagementsysteme.

1.4.1 Common Management Information Protocol (CMIP) 1987 schlug OSI sein Common Management Information Protocol (CMIP) vor, als Lö-sung für das Netzwerkmanagement. Das CMIP war schon für das Management von OSI-Netzwerke zuständig. Das Protokoll lautet CMOT (CMIP Over TCP). Die Entwick-ler, die an diesem Protokoll arbeiteten, hatten den Wunsch, alle mögliche Aspekte um ein Netzwerk zu verwalten, abzudecken. Das war wahrscheinlich den Grund für den Misserfolg dieses Protokolles.

1.4.2 Simple Gateway Monitoring Protocol (SGMP). Als die Entwickler nach einigen Monaten an den hohen Ansprüchen zu verzweifeln drohten, begannen einige von ihnen im März 1987 an einer neuen, einfacheren Lösung zu arbeiten: so entstand das Simple Gateway Monitoring Protocol (SGMP).

Im August 1987 wurde SGMP veröffentlicht und wurde sofort wegen seiner Einfachheit übergenommen.

30

Im Februar 1988 entschied die Internet Activities Board (IAB), dass das CMOT zwar in die richtige Richtung wies, dass aber vorläufig SGMP wegen seiner hohen Akzeptanz verwendet werden sollte, bis dass das CMOT vollständig entwickelt sein würde.

1.4.3 Das SNMP-Modell Um die Transition von SGMP auf CMOT zu ermöglichen, wurde das SNMP-Modell ent-wickelt und noch 1988 vorgestellt. Ein Jahr später wurde es von der IAB für die Ver-wendung in TCP/IP-Netzwerken empfohlen ("recommended status").

Als es zwischen den Entwicklern von CMOT und SNMP zu Schwierigkeiten kam, wurde deutlich, daß die Entwicklung eines gemeinsamen Modells nicht mehr möglich war. Die IAB entschied darauf im März 1989, die beiden Gruppen ihre Arbeit unabhängig fortfüh-ren zu lassen.

SNMP benutzt das IP (Internet Protocol) auf der Vermittlungsschicht des ISO/OSI-Schichtenmodells.

Auf der Transportschicht wird UPD (User Datagram Protokol) verwendet, d. h. der Aus-tausch von Nachrichten finden verbindungslos, unsicher und unbestätigt statt. Pakete können demnach verloren gehen, dupliziert, verfälscht oder vertauscht werden. Bei Verwendung von UDP ist es die Aufgabe der Applikation, diese Mängel durch geeignete Maßnahmen (z. B. durch Durchnummerieren der Nachrichten) abzufangen.

Dies ist ein Nachteil von der SNMP Version 1.

SNMP verwendet die Portnummern 161 und 162.

Bild: SNMP am ISO/OSI-Ebenenmodell

31

2 Das Netzwerk Management Modell SNMP 2.0 Vortrag SNMP, RMON und DMI

1

Simple Network Management Protocol

Simple heißt nicht: einfach, mit wenig Möglichkeiten

Sondern: einfach strukturiert

Deshalb: - leicht auf verschiedenen Plattformenimplementierbar

- auch auf preiswerten Netzkomponentenmit geringer Rechenleistung einsetzbar

2

SNMP wurde 1990 zum offiziellen Standard in den 3 Dokumenten:

RFC 1155 (Structure of Management Information) SMI

RFC 1156 (Management Information Base) MIB-I

RFC 1157 (Simple Network Management Protocol) SNMP

Ein Jahr später wurde der Standard ergänzt durch:

RFC 1213 (Management Information Base V.2) MIB-II

Die MIB-II löst die MIB-I vollständig ab und ist weiterhin aktuell.

RFC = Request For Comment, vorläufige Internet Spezifikationmit der Bitte um Kommentierung und Ergänzung,später in vielen Fällen zur Norm oder Standard erhoben.

32

3

SNMP ist mehr als ein Protokoll

SNMP ist ein Management System mit folgenden Komponenten:

Agent, in einer Netzkomponente- stellt Informationen für den Manager bereit.- wirkt auf die Netzkomponente ein.

Manager, ein Programm in einer Managementstation- ruft Informationen von den Agenten ab und stellt sie übersichtlich dar.- empfängt spontane Ereignisse (Traps) von den Agenten.- wirkt über die Agenten auf die Netzkomponenten ein.

Managementprotokoll, SNMP- zum Informationsaustausch zwischen Manager und Agent.

Management Information Base, MIB-II- beschreibt die Daten, die der Manager beim Agent abfragen und ändernkann.

4

SNMP KommunikationDie Kommunikation zwischen Agent und Manager wird durch 5 einfacheFunktionen vollständig ermöglicht:

get Request - Auftrag zur Abfrage einer MIB Instanzget NextRequest - zur einfacheren Abfrage von Listenget Response - Antwort des Agentenset Request - Auftrag zum Setzen einer MIB InstanzTrap - spontanes Ereignis vom Agent zum Manager

MIB abfragen

MIB setzen

spontanesEreignis

get Request

get Response

set Request

get Response

Trap

Manager Agentz.B. Anzahl der gesendetenPakete ermitteln.

z.B. Port einer Brücke Sperren.

z.B. Konfigurationsänderungder Netzkomponente

33

5

SNMP FramesDie Nachrichten zwischen Agent und Manager, welche jeweils alle fürdie Funktion notwendigen Parameter enthalten nennt man:

Protocol Data Unit (PDU)Für einen bestimmten Managementprozess werden durch denManagement Dienst (service) die aufgerufenen Funktionen in eine Folgevon PDUs umgesetzt.

Der Management Dienst erkennt ausgebliebene Responses undführt Wiederholungen durch und er hat Zugriff auf die unterlagerteKommunikationsschicht z.B. UDP.

Ein SNMP Frame würde dann so aussehen:

EthernetHeader

IPHeader

UDPHeader

SNMPHeader PDU ECC

6

SNMP SicherheitÜbertragungssicherheitDie SNMP Nachrichten werden vorzugsweise über ein verbindungslosesProtokoll gesendet (z.B. UDP).Grund: Vermeidung höherer Netzbelastung durch verbindungsorientierteProtokolle (z.B. TCP/IP).Ausgebliebene Responses werden durch den Management Dienst mitWiederholungen der Requests ausgeglichen.

ZugriffssicherheitBestandteil jeder PDU ist die Community, eine Netzbereichskennungwelche dem Agent bekannt sein muß. Jeder Agent kennt verschiedeneCommunities mit unterschiedlichen Zugriffsrechten (Read only, R/W).Der Agent überprüft Community und IP-Adresse des Managers!

Diese Zugriffssicherheit erschien einigen jedoch noch nicht sicher genug.Deshalb wurde SNMPv2 entwickelt, mit weitaus komplexeren Zugriffs-Strukturen. Aufgrund dieser Komplexität konnte sich SNMPv2 bis heutejedoch noch nicht durchsetzen.

34

7

SNMP StrukturenDamit SNMP auf verschiedenen Plattformen implementiert und inunterschiedlichen Programmiersprachen realisiert werden kann, wurdeeine formale Datenbeschreibungsprache gewählt:

ASN.1 (Abstract Syntax Notation Dot One)Dabei wird für SNMP jedoch nur eine Teilmenge benötigt.

ASN.1 wird sowohl für die Formate der PDUs, als auch für den Aufbauder Management Information Base MIB verwendet.

Der Aufbau der Management Information Base ist streng objektorientiert.Jede ansprechbare Variable ist eine Objektinstanz mit übergeordnetenKlassen samt zugehöriger Vererbung.

Die gesamte MIB ist als abstrakte Baumstruktur angelegt. Die Verzwei-gungspunkte sind die Objektklassen, die „Blätter“ der MIB sind diegenerischen Objektklassen. Die Instanzierung erfolgt z.B. durch Angabedes Ports oder der spezifischen Adresse.

8

Aufbau der MIBDas SNMP Protokoll arbeitet ausschließlich mit Objektinstanzen undbenötigt deshalb ein Schema ihrer eindeutigen Benennung.

Der Name eines Objekts (auch Objekt-Identifier = O-ID) wird durch diePosition der Objekttyp-Beschreibung in einem Registrierungsbaumfestgelegt. Dabei kann entweder eine kurze genormte textlicheBeschreibung oder auch ein entsprechender Zahlenwert verwendetwerden.

An der Wurzel des Baumes sind 3 Möglichkeiten festgelegt:

0 = CCITT Objekte1 = ISO Objekte2 = gemeinsame ISO/CCITT Objekte

Für SNMP werden nur zwei Äste der Baumstruktur verwendet:

1.3.6.1.2.1 = MIB-II - muß immer vorhanden sein1.3.6.1.4.1 = Enterprises - herstellerspezifische Objekte

35

9

Baumstruktur der MIBroot

3 - ISO/CCITT Objekte2 - CCITT Objekte 1 - ISO Objekte

0 - standard1 - registration-authority2 - member-body3 - org Objekte anderer internationaler Organisationen

1 - n.n:

6 - dod Objekte des Department of Defense1 - internet Objekte im Internet

1 - directory2 - mgmt Objekte des IAB Internet Architection Board

1 - mib-2 MIB-II3 - experimental4 - private

1 - enterprises Objekte privater Unternehmen1 - Proteon:

248 - Hirschmann

10

Beispiel 1 (aus dem MIB-II Ast)dot1dTpAgingTime = Aging-Zeit in Sekunden, bei dem die gelernten

Adressen aus der Filtertabelle entfernt werden.dot1d-Gruppe = Brückenspezifische ObjekteTp-Gruppe = Transparente Vermittlung

1.3.6.1.2.1.17.4.2.0InstanzAgingTimeTp = Transparente Vermittlungdot1d = Brückenspezifische ObjekteMIB-2 = MIB-II Objektemgmt = Management Objekteinternet = Internet Objektedod = Department of Defenseorg = Objekte anderer Organisationeniso = Objekte der ISO

36

11

Beispiel 2 (aus dem Enterprise Ast)hirmaBasBridgeSoftVersion = Version der Brücken FirmwareHirma-Gruppe = Enterprise HirschmannBas-Gruppe = GrundkonfigurationBridge-Gruppe = Brücke

1.3.6.1.4.1.248.2.1.1.1.3.0InstanzSoftwareVersionbas = Basis Capabilitiesbridgemnmt = Brückenmanagement bridge1 = Brücke 1bridge = Brückehirma = Hirschmannenterprise = Hersteller spezifischprivate = nicht genormtinternet = Internet Objektedod = Department of Defenseorg = Obj. anderer Organisationeniso = Objekte der ISO

12

Proxy-AgentenDie bisher angesprochenen Agenten sind immer Bestandteil einer Netz-komponente (Brücke, Interfacekarte usw.). Nun gibt es aber auch Netz-komponenten, welche keinen eigenen Agenten besitzen, z.B. ein Modem.

In diesem Fall kann in dem entsprechenden Netzteilnehmer (WS, PC)ein Proxy-Agent installiert werden, der Statusleitungen und Statusregisterdes Modems in eine vom Manager lesbare MIB umsetzt.

Eine besondere Art von Proxy-Agent ist der RMON (Remote Monitor).

Der RMON übernimmt zwei Aufgaben:- er „lauscht“ am Netzwerk ähnlich einem Netzanalyser.- er übersetzt die ermittelten Daten in eine MIB

Nur der RMON kann netzspezifische Daten wie Netzauslastung undAnzahl der Kollisionen für das Netz (nicht das Interface) ermitteln.Standard-Agenten können dies nicht!

Der RMON gewinnt deshalb zunehmend an Bedeutung.

37

13

RMON- überwacht das Netz und nicht nur die Schnittstelle aus Sicht desNetzteilnehmers

- arbeitet auf den ISO/OSI Ebenen 1 und 2 und kann dadurch z.B.Kollisionen, defekte Datenpakete und die Netzlast (Utilization) erkennen

- ist in der Lage Historien abzuspeichern, die zu einem späteren Zeitpunktverarbeitet werden können

- agiert als Server, sendet selbstständig und zyklisch RMON-Daten andie zentrale Managementkonsole

- ist als Softwarelösung in einem Netzteilnehmer integriert oder kannals eigenständige Hardware an das zu überwachende Netz ange-schlossen werden (RMON Probe)

- RMONv2 arbeitet zusätzlich auf den höheren OSI-Schichten und kanndadurch Protokolle und Client/Server Beziehungen analysieren

14

RMON in geswitchten NetzenZur Überwachung jedes Netz-Teilsegments müsste an jedem Portdes Switches ein eigener RMON-Agent bzw. eine eigene RMON-Probeinstalliert werden.

Einige Hersteller haben deshalb in ihren Switches ein sogenanntesPort-Mirroring implementiert. Durch einen Befehl im Managementsystemwerden alle an einem zu überpüfenden Port übermittelten Datenpaketeauf einen Analyse-Port gespiegelt, an dem die RMON-Probe ange-schlossen ist. Nachteil: Zusätzliche Belastung des Backbones.

Um diesen Nachteil zu umgehen, werden die zu spiegelnden Datendirekt am zentralen Chip des Switches abgegriffen (RMON Hardwareim Chip integriert).

Dieses Verfahren nennt man SMON. (Switch Monitoring)

Zur Zeit arbeitet man an der Standardisierung von SMONv2, der dannauch die Bereiche VLAN und QoS (Quality of Service) abdeckt.

38

15

Desktop Management InterfaceDMI ist aus Betriebssystem- und Protokollunabhängigen Programm-Interfaces(APIs) aufgebaut, welche es ermöglichen, alle Hard- und Sofwarekomponenteneines PCs zu erfassen.

- Uhrzeit- Prozessor- Motherboard- Bios-Version- RAM Speicher- Festplatte- Grafikkarten- installierte Software- usw.

Vorgesehen ist auch, daß die Managementanwendungen über DMI die einzelnenKomponenten direkt ansteuern können, um Wartungsarbeiten oder Korrekturendurchzuführen.

16

DMI Software Layer- SP Service providerDieser Layer sammelt alle Informationen über die einzelnen Kompo-nenten. Er verwaltet sie in der MIF-Datenbank (Management InformationFormat). Damit der Service Layer überhaupt eine Komponente be-arbeiten kann, muß der Hersteller ein entsprechendes ASCII basiertesMIF-File mitliefern. Darin sind Angaben darüber enthalten, welcheParameter abgefragt und unter Umständen auch neu gesetzt werdenkönnen.

- MI Management InterfaceDieser Layer sorgt für die Kommunikation zwischen Service Layerund Management-Anwendung.

- CI Component InterfaceDieser Layer ist die Schnittstelle zwischen Service Layer und deneinzelnen Hard- und Software-Modulen.

39

17

DMI in der Praxis

- DMI wird von der DMTF (Desktop Management Task Force) betreut,in der alle namhaften PC Hersteller vertreten sind.

- Aktuell ist die Version DMI 2.0

- DMI wird von allen PC – Herstellern unterstützt und bei neuerenSystemen automatisch mitgeliefert.

- Der Hersteller DELL liefert mit seinen Programmen OpenManage Clientund OpenManage Client Administrator ein komplettes DMI System.

- Eine Weiterführung des DMI Konzepts treibt momentan INTEL voran,mit WfM (Wired for Management), mit dem sich wesentlich erweiterteMöglichkeiten für die Managebarkeit von PCs ergeben.

2.1 Das OSI-Organisationsmodell des Netzwerkmanagements (ISO 10040) Netzwerkmanagement – Architektur Management- Management- Management- Netzwerk- Station Agent Information Base management- Protokoll • Management • Antwort auf MIB Ressourcen: • Get Applikation Anfragen • Schnittstelle • Ausführung von Objects (Datenvariablen) • Set Aktionen • Protokoll • Meldung von • Trap Ereignissen Bild: Bestandteile des SNMP Netzwerkmanagement-Systems

Das SNMP-Modell des Netzwerkmanagements besteht aus folgenden Architekturbe-standteilen [Tan96], [Sta98], Bild 2-1:

40

Management-Station

Management-Agent

Management Information Base

Netzwerkmanagement-Protokoll

Das ISO/OSI-Organisationsmodell des Netzwerkmanagements definiert zwei Rollen für das Management: Manager-Rolle

Hat die aktive Funktion. Verbindet die einzelnen Management-Informationen und leitet daraus die notwendigen Handlungen ab.

Wird selbst gemanagt, indem die Management-Policies vorgegeben werden, die vom Manager benutzt werden.

Agenten-Rolle

Liefert die Management-Information zum Manager. Verwaltet die MIB (Management Information Base). Führt die vom Manager angeforderten Operationen auf den MOs aus. Überwacht Schwellwerte, Pegel, Timer und veranlasst spontane Meldungserzeu-

gung an den Manager. Führt die Management-Zugangskontrolle durch.

2.1.1 Die Management Station Das Netzwerkmanagement erfolgt an Managementstationen. Dies können dedizierte Arbeitsstationen sein, oder es erfolgt ein dezentraler Zugriff in verteilten Systemen über einen Internet-Browser. Die minimalen Anforderungen an eine Managementstation sind:

einer Managementsoftware-Suite, mit Diagnosewerkzeugen für Datenanalyse und Filterung von Fehlermeldungen, Behandlung von Ausnahmesituationen etc.

einer heute meist graphischen Schnittstelle für die Überwachung und Kontrolle durch den Netzwerkmanager, für die Anzeige von Alarmmeldungen, Visualisierung des Netzes, Konfiguration und gezielte Auswertung der Diagnosedaten mit graphi-scher Aufbereitung etc

einem Protokoll, über das die Managementsstation mit den verwalteten Geräten kommunizieren kann

einer Datenbank mit den Informationen, die von den verwalteten Knoten zusammen-getragen worden sind, zumindest mit der Essenz aus dieser meist immensen Menge von Einzelinformationen.

Da die Kommunikation von verwalteten Knoten zur Managementstation unbestätigt und somit unzuverlässig ist, fragt der SNMP-Manager in regelmässigen Abständen die SNMPAgenten ab (Polling). Beim Empfang von Traps kann der Manager dabei die Pol-lingstrategie anpassen. Dieses Konzept nennt sich Trap Directed Polling.

41

Beispielsweise wird eine Überschreitung eines gewissen Grenzwertes des IP-Verkehrs auf einem Gateway gemeldet. Um zu verhindern, dass die Anwender in Kürze das In-ternet für die Verbindung nach aussen nicht mehr benutzen können, kann die Manage-mentstation in Frage kommende Knoten abfragen, um die Verursacher der Überlast zu diagnostizieren und geeignete Gegenmassnahmen einleiten zu können.

2.1.2 Das Agent Processing Ein Management-Agent ist eine Software, die auf einem verwalteten Knoten wie einem PC, Drucker, Gateway, Router, Hub oder einer Bridge beispielsweise als SNMP-Pro-zess laufen muss, damit die Managementstation mit dem Knoten kommunizieren kann. Entweder beantwortet der Agent Anfragen über den Status seiner Betriebszustände, oder er führt Aufträge durch wie Konfigurationsänderungen, oder er meldet selbständig wichtige Ereignisse, wenn Aspekte des Systems gewisse vordefinierte Charakteristiken zeigen wie die Überschreitung von Grenzwerten.

Bild: Zugriff auf die „Managed Objects“

2.2 Managed Objects und MIBs An „Managed Objects“ sind relevant für die Überwachung und Steuerung einer speziel-len IT-Komponente. Managed Objects sind, soweit sie standardisiert sind, allgemein verwendbar, d. h. nicht gerätespezifisch.

Auf das Managed Object werden bestimmte Operationen für den lesenden / schreiben-den Zugriff angewendet.

Das OSI-Information-Modell (SMI Structure of Management Information ISO 10165-x) ist vollständig objektorientiert.

42

Managementobjekte (MO) sind Instanzen von Management-Objektklassen (MOC), de-ren von außen sichtbare Eigenschaften allein durch die Klassenspezifikation gegeben sind.

2.2.1 Mangaged Object Das Mangaged Object beschreibt Attribute, Operationen, Meldungen und abstrakte Beschreibungen des Verhaltens.

Bild: Managed Object

Bild: Zusammenwirken Manager und Agent

Beispiel 1: Verwaltung eines Druckers

Attribute des Managed Objects Aktueller Betriebszustand (bereit, druckend, fehlerhaft, in Wartung etc.) Tonerstand (normal, niedrig, leer) Anzahl bereits gedruckter Seiten Informationen über den aktuellen Druckauftrag (Benutzer, Größe des Files,

Zeit, etc.) Operationen lesen von Attributen schreiben von Attributen spontane Meldungsgenerierung, z. B. bei Druckerstörungen

Zusätzliche Operationen

43

Drucke Testseite Reset Drucker Setze auf off-line ....

Beispiel 2: Überwachung einer Kaffeemaschine

Bild: Abstraktion der Managed Objects (MOs)

Ein „managed object“ ist eine abstrakte Sicht auf eine Hardware- oder Software- Res-source, die ihren Zustand zum Zweck des Managements offen legt.

Üblicherweise existieren pro gemanagte Netzkomponente viele Managed Objects. Die Sammlung von Managed Objects wird als Managed Information Base (MIB) bezeichnet (ISO 7498-4). Die MIB stellt ein Container von Managed Objects (MOs) dar.

Die MIB wird von dem jeweiligen Agenten verwaltet und aktualisiert vorgehalten. Die Managed Objects müssen innerhalb der MIB eindeutig adressiert werden können.

Außerdem können Managed Objects mehrfach innerhalb einer MIB auftreten, es muss deshalb eine Unterscheidung zwischen der Definition von MIBs und deren Instanziie-rung in einer Netzkomponente geben. (z. B. mehrere Netzwerkarten in einem PC)

Bild: Die Management Information Base (MIB)

44

2.2.2 Die Management Information Base (MIB) Um in den Knoten geführte Eigenschaften gezielt abfragen zu können, müssen die an-gesprochenen Aspekte von Komponenten und Diensten als Informationen genauer spe-zifiziert sein.

Diese Aspekte werden durch Datenvariablen repräsentiert, die aus historischen Grün-den „Managed Objects (MO)“ genannt werden, obwohl sie mit Objekten im objektorien-tierten Sinne nichts gemein haben, d. h. keine eigenen Methoden ausführen können, sondern nur Zustände repräsentieren.

Die Gesamtheit der Managed Objects bilden die Management Information Base (MIB).

Die MIB ermöglicht der Managementstation über die Agenten auf die interessierenden Objekte von Systemressourcen zuzugreifen. So können Zustände abgefragt, Aktionen oder Konfigurationsänderungen an einem Knoten ausgeführt werden. Der Manage-ment-Agent unterhält dabei die MIB.

Die Management Information Base (MIB) stellt ein logisches Datenmodell dar, das der Manager und die Agenten verwenden.

Um alle Informationen weltweit eindeutig identifizieren zu können hat die ISO und die CCITT1) einen Registrierungsbaum eingeführt. Somit kann jeder Management-Informa-tion ein eindeutiger Objekt-Identifier zugewiesen werden.

1 Comité Consultatif International Téléphonique et Télégraphique, an organization that sets international

communications standards. CCITT, now known as ITU (the parent organization) has defined many im-portant standards for data communications

45

Bild: MIB-2 Standard

Legende: ISO = ISO ORG = Organisationen DoD = Department of Defense (TCP/IP) Internet = Internet mgmt = Management MIB-2 = standard MIB-2 (Internet-MIB 2) IP = Internet Protocol IpInReceives - Counter für empfangene IP-Pakete

Im Beispiel:

Counter für IpInReceives 1.3.6.1.2.1.4.3

Durch den Baum ist eine weltweit eindeutige Identifizierung möglich. Es ist deutlich zu sehen, dass eine Erweiterung problemlos stattfinden kann. Firmen können ihren Pro-dukten im private Ast sog „enterprise“ MIBs zuweisen.

Für die Firma CISCO steht z.B. unter 1.3.6.1.4 ein Teilbaum zur Verfügung, in dem fir-meneigene Entwicklungen eingebunden werden können.

Die konkrete Objektbeschreibung findet in ASN.1 statt.

Bild: Baumstruktur der MIB

46

Bild: Beispiel 1 - aus dem Standard MIB-II Ast

Bild: Beispiel 1 - aus dem „enterprise“ Ast

47

Bild: MIB-Objekt IpInDelivers

48

2.3 ASN.1 als Beschreibungssprache für MIB-Objekte ASN.1 bedeutet Abstract Syntax Notation One und ist eine systemunabhängige Spra-che zur Beschreibung von Objekten.

Eine formale Beschreibung eines Objekts besteht aus:

Name des Objektes

Syntax als ASN.1 Datentyp

optional Beschreibung des Objektes in Textform

Zugriffsrechte auf das Objekt

Statusinformation zum Objekt

Beispiel: ASN.1-Beschreibung eines Zählers für IP-Pakete

IpInDiscards OBJECT-TYPE

SYNTAX Counter

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note, that this counter does not include any datagrams discarded while awaiting re-assembly."

::= { ip 8 }

IpInDelivers OBJECT-TYPE

SYNTAX Counter

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The total number of input datagrams successfully delivered to IP user-protocols (including ICMP)."

::= { ip 9 }

ipOutRequests OBJECT-TYPE

SYNTAX Counter

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note, that this counter does not include any datagrams counted in ipForwDatagrams."

49

::= { ip 10 }

ipOutDiscards OBJECT-TYPE

SYNTAX Counter

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note, that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion."

::= { ip 11 } IpInDelivers ist der Name des Objekts

Das Objekt ist vom Typ Counter (also ein Zähler)

Man darf nur lesend auf das Objekt zugreifen.

Objekt ist für die Anwendung vorgeschrieben.

Es folgt eine Textbeschreibung des Objektes

Zu Beschreibung eines Objektes werden folgende Typen unterschieden: Counter = Zähler von 0 bis (2^32)-1 aufsteigend Gauge = Zähler von 0 bis (2^32)-1 auf- und absteigend NetworkAddress = versch. Netzwerkadressformate IpAddress = 32-Bit-Adresse Timeticks = ein Zähler, der die Zeit in 1/100 s misst Opaque = für eigene Datentyp-Definitionen (Vereinbarungen müssen

zwischen Manager und Agent getroffen werden) Weitere Elemente z.B. Table oder Row zur Darstellung von Tabellen

Des weiteren werden folgende Zugriffrechte auf das Objekt unterschieden: read-only read-write write-only not-accessible

Ebenso wie durch den Status des Objekts:

mandatory (für die Anwendung vorgeschrieben) optional (nach Bedarf verwendbar) obsolete (veraltet)

50

2.4 Austauschparadigmen für Managementinformationen Die zwei wichtigsten Paradigmen, die den Austausch von Informationen zwischen Enti-täten ermöglichen, sind:

Frage-Antwort-Paradigma (zyklische Abfrage von Objektvariablen, sog. Polling);

Meldungs- Paradigma (selbsttätige Benachrichtigung, sog. Trapping).

Bild: Austausch von Managementinformationen

Im ersten Fall beginnt den Manager die Abfrage von Informationen an den Agent in Form vom Befehlen oder regulären Abfragen (polling).

Im zweiten Fall ist es der Agent, der Informationen selber (d.h. selbsttätig) an den Ma-nager schickt. Diese Informationen betreffen die Veränderung des Zustandes eines Managed Object.

Die Kommunikation zwischen den Managementstationen und den Agenten findet über ein Protokoll, das Simple Network Management Protocol im eigentlichen Sinne statt.

Dabei repräsentiert das Protokoll die bereits angesprochenen Hauptfunktionalitäten in der Kommunikation:

Get ermöglicht der Management-Station, die Zustände eines Objekts über einen Agenten abzufragen,

Set ermöglicht die Veränderung Objektwertes

Trap verwenden die verwalteten Knoten, um eingetretene wichtige Ereignisse an die Managementstation zu melden.

51

Bild: SNMP Kommunikation

2.5 Aufbau einer SNMP-Nachricht

Bild: SNMP Frames Beim Aufbau von SNMP-Nachrichten muß grundlegend zwischen Trap- und Nicht- Trap-Operationen unterschieden werden.

52

Hier eine GetRequest, GetNextRequest, SetRequest bzw. GetResponse Operation:

Bild: Aufbau eines SNMP Requests Legende:

Version gibt die Versionsnummer von SNMP an (0=Version 1 und 1=Version 2)

Community enthält den Community-String zur Authentifikation

Die PDU, Protocol Data Unit besteht aus o dem Type der Operation, o der RequestID, damit Responses bestimmten Requests zugeordnet werden

können, o dem ErrorStatus und ErrorIndex, falls bei Requests etwas fehlerbehaftet

angefordert wurde, o sowie einer Liste von Objects mit den dazugehörigen Values

Bild: Aufbau einer Trap-Nachricht Legende:

Version gibt die Versionsnummer von SNMP an (0=Version 1 und 1=Version 2)

Community enthält den Community-String zur Authentifikation

Die PDU, Protocol Data Unit besteht aus o dem Type der Operation (Trap), o der ObjectID des Objektes, o der ObjectAddress des Objektes, o GenericTrap, einer Kennzeichnung für verschiedene vordefinierte Ereignis-

meldungen, o SpecificTrap, einer Kennzeichnung für firmenspezifische Ereignismeldun-

gen,

53

o einem Timestamp der die Zeit enthält, wann das Ereignis eingetreten ist, so-wie

o einem Informationsfeld welches weitere informationen enthalten kann

2.6 Authentifikation einer SNMP-Nachricht Bei SNMP-Version 1 findet die Authentifikation auf eine sehr simple Weise statt: Bei Initialisierung des Agenten werden für Lese- und Schreib-Operationen (Get/Set) unterschiedliche Community-Strings vergeben. Ein Manager kann auf ein Objekt nur zugreifen, wenn er die gleiche Community hat. Diese einfache Methode stellt einen sehr großen Sicherheitsmangel der Version 1 dar, welcher mit der Version 2 behoben wurde. SNMP Version 1 hat noch weitere Sicherheitsmängel: So wäre es z. B. denkbar, dass jemand die Operationen mitliest, verändert und wieder aussendet oder unverändert zu einem späteren Zeitpunkt wieder aussendet (z. B. bei Set Operationen). Erweiterungen der Version 2 In der SNMP-Version 2 beheben neue Sicherheitskonzepte zumindest teilweise die Sicherheitsmängel der Version 1: DES Durch eine Verschlüsselung der Daten mit einem symetrischen Schlüssel soll garantiert werden, das verschlüsselte Daten nicht von anderen entziffert werden können. MD5 Durch MD5 (Message Digest Algorithm) wird eine Authentisierung erreicht. Eine 128 Bit lange Prüfsumme wird verschlüsselt an den Empfämnger weitergegeben, der diese ü-berprüft, somit die Authentisierung und die Gewissheit hat, die Daten richtig empfangen zu haben. Loosely Synchronized Clocks Durch die Loosely Synchronized Clocks Methode wird der Nachricht ein timestamp mit-gegeben. Damit kann der Empfänger überprüfen, ob die Nachricht für ihn noch gültig ist. Ist die Nachricht zu alt, wird sie verworfen. Somit wird eine Wiederholung der Nach-richten durch den timestamp vermieden und die Manipulationsmöglichkeiten stark ein-geschränkt.

54

3. Using MIB

3.1 Download der MIB-Browser und MIB-Files

3.1.1 Download des MIB-Browsers http://www.wtcs.org/snmp4tpc/getif.htm Freeware SNMPviewer MG-SOFT MIB Browser Professional Edition with MIB Compiler, MIB Explorer and Visual MIB Builder, for Windows. Package Version 9.0.3 (published 22-July-2004) http://www.mg-soft.com/download.html

3.1.2 Download der MIB-Files The following URL provides access to general information about Cisco MIBs. Use the links on this page to access MIBs for download, and to access related information (such as application notes and OID listings). http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml Die CISCO MIB Files findet man unter ftp://ftp.cisco.com/pub/mibs/ , hier gibt es auch die OID"s cisco Systems Public MIB Area ================================ cisco's public mib area has been reorganized to make it easier for you to find the mibs that you need. All SNMPv1 mibs are now in the subdirectory "v1". All SNMPv2 mibs are now in the subdirectory "v2". The suggested way to retrieve the MIBs applicable to the cisco products that you wish to man-age is as follows:

1. For each product, retrieve the file supportlists/[product]/supportlist.txt. (or supportlists/[product]/supportlist.html for those using WWW)

1. determine which mibs each product supports from the retrieved file. 2. consult the v2/readme or v1/readme file for brief descriptions of the functionality pro-

vided by each mib. 3. retrieve all mibs which provide the functionality you are interested in, and are applicable

to the cisco products you wish to support.

55

The following is a list of directories which are in this directory. The file you're reading is the one named "README", in directory pub/mibs. =================================================================== app_notes directory w/ application notes for using the mibs. archive directory w/ mibs, oids, schema for IOS 10.0 and earlier releases. contrib directory w/ helpful mib-related scripts/files (see contrib/README) oid directory w/ SunNet Manager OID files for the mibs. schema directory w/ SunNet Manager schema files for the mibs. supportlist directory w/ directories for each product with information about which mibs that product supports. traps directory w/ SunNet Manager trap files for the m ibs. v1 SNMP version 1 mibs and SNMPv1 conversions of the SNMP version 2 mibs. v2 SNMP version 2 mibs.

3.2 MIB Examples

3.2.1 MIBs supported by Switch Catalyst 2950 series MIBs supported in IOS release 12.0(5)WC

BRIDGE-MIB.my ENTITY-MIB.my CISCO-2900-MIB.my CISCO-CDP-MIB.my CISCO-CONFIG-MAN-MIB.my CISCO-IMAGE-MIB.my CISCO-MEMORY-POOL-MIB.my CISCO-PING-MIB.my CISCO-PRODUCTS-MIB.my CISCO-TCP-MIB.my IF-MIB (RFC 1573) OLD-CISCO-CHASSIS-MIB.my OLD-CISCO-CPU-MIB.my OLD-CISCO-INTERFACES-MIB.my OLD-CISCO-IP-MIB.my OLD-CISCO-MEMORY-MIB.my OLD-CISCO-SYSTEM-MIB.my OLD-CISCO-TCP-MIB.my OLD-CISCO-TS-MIB.my RFC1213-MIB (MIB-II)

56

RFC1398-MIB (ETHERNET-MIB) RMON-MIB (RFC 1757) - 4 Groups SNMPv2-MIB.my TCP-MIB.my UDP-MIB.my CISCO-STACKMAKER-MIB.my CISCO-VLAN-MEMBERSHIP-MIB.my CISCO-SMI.my CISCO-TC.my CISCO-VTP-MIB.my IANAifType-MIB.my RS-232-MIB.my SNMPv2-SMI.my SNMPv2-TC.my CISCO-STP-EXTENSIONS-MIB.my CISCO-CLUSTER-MIB.my CISCO-FLASH-MIB.my CISCO-PROCESS-MIB.my CISCO-SYSLOG-MIB.my

Additinal MIBs supported in IOS release 12.1(6)EA2 CISCO-MAC-NOTIFICATION-MIB.my CISCO-PAGP-MIB.my

3.2.2 Router MIB Support Lists The below MIBs are supported by IOS version 10.2 and later. SNMP version 1 MIBs are in the v1 directory and SNMP version 2 MIBs are in the v2 directory. Note that for most every MIB .my in the v2 directory, there exists a SNMP version 1 conversion of the MIB -V1SMI.my in the v1 directory. The exception is SNMPv2-TC.my. At a minimum, you will want to download all of the OLD-CISCO- and CISCO- mibs (including -TC and -SMI) for your network management workstation. IOS 12.2 Support SNMP version 2 MIBs added in IOS 12.2T: CISCO-PIM-MIB.my CISCO-POP-MGMT-MIB.my CISCO-CLASS-BASED-QOS-MIB.my CISCO-CLASS-BASED-QOS-MIB-CAPA BILITY.my SNMP version 2 MIBs in V1 format added in IOS 12.2T: CISCO-PIM-MIB-V1SMI.my CISCO-POP-MGMT-MIB-V1SMI.my CISCO-CLASS-BASED-QOS-MIB-V1SMI.my SNMP version 2 MIBs added in IOS 12.2(1)T: CISCO-MIBILE-IP-MIB.my SNMP version 2 MIBs in V1 format added in IOS 12.2(1)T: CISCO-MOBILE-IP-MIB-V1SMI.my SNMP version 2 MIBs added in IOS 12.2(1):

57

CISCO-SIP-UA-MIB.my CISCO-SIP-UA-CAPABILITY.my SNMP version 2 MIBs added in IOS 12.2(5): CISCO-GATEKEEPER-MIB.my SNMP version 2 MIBs added in IOS 12.2(5)DA: CISCO-ADSL-CAP-LINE-MIB.my CISCO-SDSL-LINE-MIB.my SNMP version 2 MIBs in V1 format added in IOS 12.2(5)DA: CISCO-ADSL-CAP-LINE-MIB-V1SMI.my CISCO-SDSL-LINE-MIB-V1SMI.my SNMP version 2 MIBs added in IOS 12.2(1b)DA: CISCO-ADSL-DMT-LINE-MIB.my CISCO-XDSL-LINE-MIB.my SNMP version 2 MIBs added in IOS 12.2(1)MB1: CISCO-SCTP-MIB.my CISCO-SCTP-CAPABILITY.my CISCO-SP-MIB.my CISCO-SP-CAPABILITY.my SNMP version 2 MIBs in V1 format added in IOS 12.2(1)T: CISCO-SIP-UA-MIB-V1SMI.my SNMP version 2 MIBs in V1 format added in IOS 12.2(2)T: CISCO-SAA-APM-MIB-V1SMI.my SNMP version 2 MIBs added in IOS 12.2(2)T: CISCO-SAA-APM-MIB.my SNMP version 2 MIBs added in IOS 12.2(4): CISCO-ITP-RT-CAPABILITY.my SNMP version 2 MIBs added in IOS 12.2(4)MB1: CISCO-IETF-SCTP-EXT-MIB.my CISCO-IETF-SCTP-MIB.my CISCO-ITP-ACL-MIB.my CISCO-ITP-ACT-MIB.my CISCO-ITP-RT-MIB.my CISCO-ITP-SCCP-MIB.my CISCO-ITP-SP-MIB.my CISCO-ITP-TC-MIB.my CISCO-ITP-ACT-CAPABILITY.my CISCO-ITP-ACL-CAPABILITY.my CISCO-ITP-SCCP-CAPABILITY.my CISCO-ITP-SP-CAPABILITY.my CISCO-IETF-SCTP-CAPABILITY.my SNMP version 2 MIBs in V1 format added in IOS 12.2(4)MB1: CISCO-IETF-SCTP-EXT-MIB-V1SMI.my CISCO-IETF-SCTP-MIB-V1SMI.my CISCO-ITP-ACL-MIB-V1SMI.my CISCO-ITP-ACT-MIB-V1SMI.my CISCO-ITP-RT-MIB-V1SMI.my CISCO-ITP-SCCP-MIB-V1SMI.my CISCO-ITP-SP-MIB-V1SMI.my CISCO-ITP-TC-MIB-V1SMI.my SNMP version 2 MIBs added in IOS 12.2(4)T: CISCO-BSTUN-MIB.my SNMP version 2 MIBs in V1 format added in IOS 12.2(4)T: CISCO-BSTUN-MIB-V1SMI.my SNMP version 2 MIBs added in IOS 12.2(1)XE1:

58

CISCO-SDSL-LINE-MIB.my

3.3 SNMP Configuration on CISCO 2600 Router Collecting data from your routers is the key to understanding the growth patterns of your network. The most common method used to collect data from a router is to use Simple Network Management Protocol (SNMP). A number of applications use SNMP to access the Management Information Base (MIB), for an SNMP-enabled device. The MIB contains a great deal of information about the device itself and each of the individual interfaces on the device. Each router in your network will need to be conBilded to allow SNMP before it will re-spond to SNMP queries. The Cisco IOS supports SNMP versions 1 and 2. The version you need to enable depends on the management software that you will be using. All management software available supports SNMP 1, but not all software supports SNMP 2. For the purpose of collecting data, SNMP is sufficient. The command syntax to enable SNMPv1 access for a Cisco router is:

snmp-server community <community string> {RO | RW} [access-list]

community string is an ASCII string that will be used as a sort of password for clients

trying to retrieve SNMP data from the router. The community string is case-sensitive.

The RO and RW options specify whether the community string entered allows read-only or read-write access to the MIB table.

The optional argument access-list is a basic IP address-list that can be used to restrict the IP hosts that can retrieve SNMP data.

Example 1: The following example is a sample conBildation that defines a read-only community string, defines a read-write community string, and limits access to one trusted host:

snmp-sever community public RO 5 snmp-server community private RW 5 ! access-list 5 permit 192.168.10.10

Example 2: It is possible to conBilde multiple community strings for the same variable type. This is useful when you’re changing community strings. To conBilde multiple community strings on the same router, simply enter multiple snmp-server community commands into the router in global conBildation mode.

59

Here are the commands to have three read-only community strings on the same router:

snmp-server community public RO snmp-server community PuBlIc RO snmp-server community pUbliC RO

4 Relevante Links Institute of Electrical and Electronics Engineers (IEEE)

http://www.ietf.org/

International Telecommunication Union (ITU) http://www.itu.int/

Warriors of the Net http://www.warriorsofthe.net/

Internet Mapping Project http://research.lumeta.com/ches/map/

Cooperative Association for Internet Data Analysis (CAIDA) http://www.caida.org/

The Internet Protocol Journal http://www.cisco.com/ipj/

Netzwerkmanagement 0 Motivation für den Einsatz von ... · 1.2 Aufgaben des Netzwerkmanagements...

Documents

Transcript of Netzwerkmanagement 0 Motivation für den Einsatz von ... · 1.2 Aufgaben des Netzwerkmanagements...