Der Netzwerk Insider - November 1999

Networking ist besserals Notworking – Historie des

Netzwerk- und Systemmanagement

Technologie Information für die Ausbildung zum ComConsult Certified Network Engineer

Schwerpunktthema

Ein Drama in 2 Byte Akten von Dipl.-Inform. Petra Borowka

Der Netzwerk Insider November 1999

ComConsult Certified Network Engineer

Ausbildung zum ComConsultCertified Network Engineer

erreicht hohe Akzeptanzvon

Dr. Jürgen Suppan

Die Ausbildung zum ComConsult Certi-fied Network Engineer wird vom Marktmit einer hohen Akzeptanz aufgenom-men.

Die Unternehmen sehen in dieser Ausbil-dung offenbar das ideale Instrument zurSchaffung des für sie in der Praxis not-wendigen Know-hows und zur Motivationihrer Mitarbeiter.

Parallel ist feststellbar, dass viele derbisherigen Absolventen messbare be-rufliche Vorteile durch den Abschluss hat-ten.

Neuester Meilenstein im Erfolg der Ausbil-dung zum ComConsult Certified NetworkEngineer: das Rechenzentrum der Finanz-verwaltung NRW und die Aachen Münche-ner Informatik schließen Rahmenverträgeüber einen Zeitraum von 3 Jahren zur sy-stematischen Ausbildung ihrer Mitarbeiterdurch die ComConsult Akademie. NachPrüfung von Inhalt, Relevanz und Umfangder Ausbildung sind diese beiden Unter-nehmen überzeugt, in der Ausbildung zumComConsult Certified Network Engineerden idealen Ansatz zur Motivation und Wei-terbildung ihrer Mitarbeiter gefunden zuhaben. Wesentlich war für beide die Pra-xisnähe der ComConsult Seminare beigleichzeitig neuestem Stand der Technik ineiner herstellerneutralen Ausbildung.

Der Ausbildungsplan zum ComConsult Cer-tified Network Engineer wird laufend denaktuellen Technologie-Situationen und demBedarf der Unternehmen und Teilnehmerangepasst. So gibt es für die Seminare imnächsten Jahr u.a. folgende Änderungen:

• Das Seminar TCP/IP und SNMP über-nimmt den Schwerpunkt der TCP/IP-Ausbildung für den ComConsult Certi-fied Network Engineer. Gemäß der ho-hen Bedeutung von TCP/IP für die Pra-xis wird das Seminar auf eine Dauer von5 Tagen ausgebaut. Erfreulicherweisekonnten dabei die Kosten pro Tag deut-lich gesenkt werden.

weiter Seite 6

1999 – Die Statistiken zeigen weiterhinsteigenden Willen der System- und Netz-betreiber, Geld für Management auszuge-ben.

Der Markt hat mit einer steigenden Anzahlvon Einzellösungen für alles und jedes rea-giert:

Komponenten-Manager mit SNMP undBrowsermodulen (beide nicht vollständig,daher beide erforderlich), PC-Manager, Ser-ver-Manager, Softwareverteilung, TroubleTicketing, Problemmanagement, Dokumen-tationssysteme, Backup-Manager, Datenma-nager, Analysetools, Application ResponseTime Tools, Simulationstools und nach wievor Frameworks, wobei sich der Markt aufCA, HP und IBM fokussiert, Sun ist aus dem

Rennen, Cabletron nurmehr im Netzwerk-markt von Bedeutung.

Der Netzwerkteil von WBEM macht mit demSchlagwort DEN (Directory Enabled Net-works) von sich reden: die Vision, mit einemstandardisierten Objektmodell (CIMv2) undeinem standardisierten Zugriffsprotokoll(LDAPv3) alle Konfigurations-Informationenund Profile in einem gemeinsamen Verzeich-nisdienst zu handhaben, korrelieren undzentral steuern zu können, wartet auf ihreImplementierung. Bisher ist die allerdingsbestenfalls in Teillösungen von Teillösungeneinzelner Hersteller (u.a. Cisco, 3Com,Microsoft, Netscape, Nortel, Novell) feststell-bar.

Wie alles begann auf Seite 7

Mein Netz, dasunbekannte Wesen

Impressum

Verlag:ComConsult

Technologie Information GmbHPascalstraße 25

D-52076 AachenTelefon 02408/14907Telefax 02408/149233

Herausgeberund verantwortlich

im Sinne des Presserechts: Dr. Jürgen Suppan

Gestaltung: Zweipfennig

Erscheinungsweise:Monatlich,

12 Ausgaben im Jahr

Bezug:Kostenlos

als PDF-Dateiüber den eMail-VIP-Serviceder ComConsult Akademie

Für unverlangteingesandte Manuskripte

wird keine Haftungübernommen

Nachdruck, auch auszugsweisenur mit Genehmigung des Verlages

© ComConsult Technologie Information

ComConsult Technologie Information • Der Netzwerk Insider • November 1999 • Seite 2

Typische Produkte dieser Phase sind CAUnicenter, die HP OpenView Produkt-Familie und das Tivoli Framework mit sei-nen einzelnen Modulen.

Inzwischen wird immer deutlicher, dass diedamit zu realisierenden Lösungen im we-sentlichen ein hierarchisches Alarm- undEreignis-Management realisieren, das aufden Technologie-spezifischen Einzelwertenaufsetzt und durch Korrelation und Filterungversucht, einen Technologie-übergreifendenGesamtblick zu realisieren.

Die damit bisher zu schaffenden Lösungenwaren sicher im Vergleich zu ihrer Aus-gangslage ein wichtiger Fortschritt, weisenaber einige erhebliche Nachteile auf:

• obwohl sie eine Technologie-übergreifen-de Lösung anstreben, konzentrieren siesich nicht auf das wesentliche: den durchManagement in einer definierten Qualitätsicherzustellenden Geschäftsprozessbeim Anwender. Die Werbung der einzel-nen Hersteller stellt dies zwar anders dar,wer aber jemals mit den bisherigen Pro-dukten versucht hat, einen Geschäftspro-zess so nachzubilden, das dessen Be-triebssituation in ihrer Auswirkung auf denAnwender für einen UHD oder eine Leit-warte intuitiv verständlich zu beurteilenwar, der weiß, das hier zwischen An-spruch und Wirklichkeit große Lückenklaffen. Begründung: der notwendigeAufwand ist extrem hoch, das Ergebnisweder intuitiv nutzbar noch von der Hand-habung für eine größere Menge vonNicht-Systemspezialisten brauchbar.

• Die einzelnen Technologien Netzwerk,Server, Mainframe, Applikation stellen ei-ne solche gigantische Menge an Einzelin-formation dar, dass deren Weiterverarbei-tung durch Filter oder Regeln an Grenzenstößt. Zwar gibt es einige gute und lo-benswerte Grundansätze wie die neuenKorrelations-Möglichkeiten im HP OpenView ECS, wie die objektorientierte Korre-lation in Cabletron Spectrum oder wie dieprogrammatischen Potentiale einer TivoliEnterprise Console. Aber auch mit diesenMöglichkeiten bleibt die Komplexität derEreignis-Verarbeitung zu hoch.

Seit einigen Monaten konzentriert sich Dis-kussion nun um einen neues Schlagwort,das zwar nicht wirklich neu ist, aber erstjetzt so richtig zu rennen beginnt: Service-Level-Management. Damit ist die dritte Pha-se der Entwicklung von Netzwerk- und Sy-stem-Management-Lösungen eingeläutet.In dieser Phase wird primär die Frage nachder Service-Situation beim Anwender ge-stellt. Unter Service versteht man dabei u.a.die Nutzbarkeit der elementaren Geschäfts-Anwendungen im Sinne eines festgelegtenLeistungsumfangs. Leistung unterteilt mandabei in die Bereiche Verfügbarkeit, Trans-aktionszeit, Durchsatz.

Neu an dieser Phase ist, dass dieser Lei-stungsumfang mit direktem Bezug auf dieAnwendung ermittelt wird. Typische Lösun-gen sind:

• Aktive Messung: Ein definierbares undgestaltbares, aber künstliches Lastprofilwird von der Anwenderseite zu einem kor-respondierenden Prozess auf dem Servergeschickt. Im Extremfall wird eine kom-plette Transaktion mit der realen Applika-tion auf dem Server nachgespielt. Durchkontinuierliche Wiederholung im Minuten-bereich sind Aussagen über die Qualitätim Sinne von Verfügbarkeit, Antwortzeitund Durchsatz in ihrer Veränderung überdie Zeitachse möglich. In Wartungsfen-stern können mit dieser Methode durchdie gezielte Simulation größerer Benutzer-Mengen sogar die Leistungsgrenzen desSystems bzw. vorhandene Engpässe fest-gestellt werden.

* Passive Messung: Die Ausführung dernormalen Arbeit an der Applikation durchden Benutzer wird gemessen und überdie Zeit periodisch ermittelt. Dieser An-satz ist komplizierter, weil das Verhalten

Zum Geleit

Der Markt für Netzwerk- und System-Management-Lösungen hat sich in den letz-ten Jahren in mehreren Phasen entwickelt:

• in der ersten Phase, die sich schwer-punktmäßig vor ca. 3 bis 5 Jahren ab-spielte, dominierte die Diskussion um dieElement-Manager speziell in den Berei-chen Netzwerk, Server und Mainframeden Markt. Typische Produkte dieser Pha-se sind HP OpenView Network Node Ma-nager, IBM NetView for AIX, BMC Patrol,Candle Command Center, ...

• in der zweiten Phase, die in den letztenbeiden Jahren stattgefunden hat, konzen-trierte sich die Diskussion auf die Fragevon Vor- und Nachteilen von Framework-Lösungen gegenüber Point-Solutions.

Neue Impulse im Netzwerk- undSystem-Management

Neue Impulse im Netzwerk- und System-Management


des Anwenders die Messung beeinflusstund eine klare Differenzierung zwischeneinzelnen Transaktionen schwierig seinkann.

In beiden Fällen entsteht einerseits ein Be-richtswesen über die Qualität der Servicesund andererseits eine neue Perspektive füreine Alarmierung bei Systemausfällen bzw.Leistungseinbrüchen, die mit wenigerenWerten als bisher eine größere Aussage-kraft erreicht.

Kennzeichnend für die neuen Möglichkei-ten des Service-Level-Management ist ne-ben der hohen Aussagekraft über die Be-tr iebssi tuat ion beim Anwender derwesentlich geringere Implementierungsauf-wand gegenüber den bisherigen Lösun-gen.

Leider gilt dies nicht pauschal. Einige Pro-dukte haben sich als sehr aufwendig in derNutzung erwiesen, bei anderen Produktenist die Prognose-Funktion über eine zukünf-tige Entwicklung mathematisch in keinerWeise akzeptabel. Trotzdem gilt: wer die-sen Markt gut evaluiert, der wird Produktefinden, die mit vertretbarem Aufwand eineneue Qualität für das Netzwerk- und Sy-stem-Management schaffen.

Interessanterweise scheinen einige dergroßen Anbieter diese Entwicklung ver-schlafen zu haben. So finden sich eine Rei-he eher unbekannter Hersteller unter denAnbietern. Compuware, INS/Lucent NetCa-re, Micromuse und Ganymede sind guteBeispiele dafür. Allerdings bewegen sichauch die traditionellen Anbieter: BMC hatim letzten Jahr Best/1 gekauft (hochinteres-sant wegen seiner mathematischen Fähig-keiten und der angestrebten Integration mitden Patrol-Agenten), Tivoli hat gerade dasneue Produkt Decision Support auf denMarkt gebracht. HP befindet sich als tradi-tioneller Anbieter von Messtechnik in einerZwitter-Situation. Einerseits stehen mitder Measureware/Glance/Per fView-Produktreihe interessante Produkte seitJahren zur Verfügung, andererseits sindsie nicht wirklich am Anwender sonderneher mehr an den Einzeltechnologien ori-entiert. Mit Firehunter bietet HP allerdingsauch einen Ansatz in die besprocheneRichtung.

Sind mit dieser neuen Phase im Markt fürNetzwerk- und System-Management diebeiden vorangegangenen Phasen nunnutzlos und vorbei?

Können wir unsere Frameworks bereitswieder einmotten bevor wir sie noch richtiginstalliert haben?

Nein, auf keinen Fall. Allerdings sieht einezeitgemäße Lösung heute anders aus alsvor 12 Monaten. Mit Hilfe der neuen Ser-vice-Level-Management-Funktion kann ausden bisherigen Ansätzen in einem erhebli-chen Umfang Komplexität entfernt werden.Durch die Konzentration auf das Wesentli-che und das Herunterbrechen des System-verhaltens ausgehend vom Nutzungspunktvereinfacht sich der Aufwand in der Über-wachung der einzelnen Technologien undder zentralen Zusammenführung in den Er-eignis-Konsolen. Er wird allerdings nichtüberflüssig.

Auf jeden Fall bietet die dritte Phase desMarktes für Netzwerk- und System-Management eine interessante Perspektive:Projekte können in kürzerer Zeit, mit weni-ger Personalaufwand zu schneller vorzeig-baren Erfolgen geführt werden. Der Nach-teil: die Lizenzkosten der Lösung steigen.

Durch das integrierte Berichtswesen wer-den dafür zwei Fliegen mit einer Klappegeschlagen:

• endlich hat das Top-Management auchein für sich verwertbares Ergebnis vomNetzwerk- und System-Management, derProjekterfolg und die Fortschritte sind klarzu erkennen

• endlich werden Service-Level-Agree-ments in einer prüfbaren und konkretenForm auch im dezentralen Umfeld mög-lich.

Wieder einmal hat sich gezeigt, wie dyna-misch unser Markt ist. Während die einennoch gebannt auf die großen und schein-bar übermächtigen Anbieter wie CA undTivoli starren, haben längst kleinere unddynamischere Unternehmen zu einer signi-fikanten Mehrwert-Situation geführt. Für diegroßen Anbieter ist dies nicht von Nachteil,können sie doch nun in dieser Kombinationauch ihre Lösungen effizienter im Sinnedes notwendigen Personal-Aufwands um-setzen.

IhrDr. Jürgen Suppan


Vom 3. bis 5. April 2000 veranstaltet dieComConsult Akademie das "NetzwerkRedesignForum 2000" in Königswinter.

Bereits jetzt zeichnet sich ab, dass das Jahr2000 durch Umbrüche in den Netzwerk-Technologien geprägt sein wird:• mehr als 100 neue Verfahren und Protokol-

le warten auf ihren Einsatz durch den leid-geprüften Anwender

• die auf dem Markt angebotenen Switch-Systeme werden in ihrer Architektur nocheinmal erheblich überarbeitet werden

Die vier großen Themen des Jahres 2000,die dafür verantwortlich sind, lauten:• Steigerung der Qualität und Verfügbarkeit

von Netzwerken u.a. durch konsequentenEinsatz von Redundanz-Verfahren unddurch Abschirmung der Server gegenüberFehlkonfiguration von Endgeräten

• Einsatz von Gigabit-Ethernet als Standard-Technologie im Backbone

• Erster Einsatz von Voice-over-IP-Lösungenim normalen produktiven Betrieb

• Reduzierung des Betriebsaufwands von

Switch-Systemen sowie der Bedien-Komplexität

Leider zeigen bereits die laufenden Projektedie hohe Komplexität und auch die Risikenin diesem Umfeld auf:• Alle im Moment angebotenen Redundanz-

verfahren haben ihre Tücken, hinzu kom-men erhebliche Erweiterungen und Ände-rungen: Spanning Tree wird auf MultipleTrees umgestellt werden, ggf. kommt aucheine schnellere Umschalttechnik zum Ein-satz. Der Link Aggregation Standard wirdverabschiedet werden

• Eine Reihe der heute kaufbaren Switch-Systeme zeigt ggf. Probleme im Einsatzvon Gigabit-Techniken: Zu kleine Puffer,Instabilitäten im Betrieb von Spanning Tree,Probleme mit internen Redundanzen

• Layer-3-Switching bedarf in der in einigenProdukten vorliegenden Form dringendder Verbesserung, der Konfigurations-Aufwand und die Fehlerempfindlichkeitder Konfiguration sind so nicht tragbar

• Der Einsatz von Voice-over-IP bringt eineFülle neuer Themen mit sich, die im Jahr

2000 in den Markt kommen: Verbindungs-aufbau-Server, Stromversorgung von End-geräten usw.

• Policy-Networking ist für unerfahrene Kon-figurateure eine gute Möglichkeit, ein Netzzum Stillstand zu bringen

Das Netzwerk-Redesign-Forum 2000 ist dieherausragende Veranstaltung, die gezieltüber diese Themen informiert und die vieleumsetzbare und wertvolle Empfehlungen fürdie Netzwerk-Praxis gibt. Erfahrene Beraterund Anwender informieren über die neuenTechnologien, die Betriebserfahrungen undauch über die aufgetretenen Probleme auslaufenden Projekten. Diese Veranstaltungwar 1999 ausgebucht und wir rechnen an-gesichts der Fülle von neuen Themen unddem enormen Bedarf an Information undHilfestellung wieder mit Engpässen bei derBuchung.Bis zum 31.12.99 läuft die Vorbu-chungsphase für den VIP-Verteiler undStammkunden von ComConsult, die nebendem Frühbuchungs-Rabatt von 12% denTeilnehmern gleichzeitig mit höchster Prioritäteinen Platz auf dieser Veranstaltung sichert.

:

Netzwerk-Redesign Forum 2000

Das Netzwerk-Event im Jahr 2000

12 % Vorbuchungs-Rabatt bis zum 31.12.99

Fax-Antwort an ComConsult 02408/149233

Ich melde mich verbindlich an zumNetzwerk-Redesign Forum 2000vom 03.04. - 05.04.00 in Königswinter

Bitte buchen Sie für mich ein Zimmerim Maritim Hotel Königswinter

vom ____________ bis ______________zum Vorzugspreis von DM 199,-- proÜbernachtung mit Frühstück.

_____________________________________Position, Funktion

_____________________________________PLZ, Ort

_____________________________________Telefon, Fax

_____________________________________Unterschrift

_____________________________________Name, Vorname

_____________________________________Firma, Abteilung

_____________________________________Straße

_____________________________________eMail

Für Besucher unserer bisherigen Kongresse bzw. für die Teilnehmer am eMail-VIP-Verteiler bietenwir in diesem Jahr exklusiv eine Vorbuchungsphase für das Netzwerk-Redesign Forum 2000 biszum 31.12.1999 zum Sonderpreis von DM 2.543,-- (EUR 1.300,22) an. Die Buchung ist verbindlich,kann aber jederzeit auf andere Mitarbeiter Ihres Unternehmens übertragen werden.

Faxen Sie uns einfach obigen Abschnitt an 02408/149233 oder schicken Sie eine eMail an [email protected]


Am 1.11.99 ist die zweite Auflage von"Netzwerk-Sicherheit : Konzepte-Produkte-Realisierungen" erschienen.Der Report, der praxisnah über die erfolg-reiche Umsetzung von Sicherheits-Lösungen für Netzwerke informiert unddamit die ideale Basis für die Durchfüh-rung entsprechender Projekte liefert, istvom Autor Dipl.-Inform. Detlef Weiden-hammer in sämtlichen Themenbereichenüberarbeitet, aktualisiert und um einigeneue Kapitel bereichert worden.

Der Report basiert auf einer Reihe von er-folgreichen Sicherheitsprojekten, für die derAutor vom Konzept bis zur Realisierungverantwortlich war. Man findet in diesemReport neben Gefahrenbeschreibungen,Konzeptdarstellungen und Produkbersichtenviele nützliche und erfolgsrelevante Tippsaus der Praxis.

Security-Experte aus Berlin:Dipl.-Inform. Detlef Weidenhammer

Der Leser erfährt, wo die Sicherheit im Netz-werk-Betrieb gefährdet ist und wie eine Si-cherheits-Planung erarbeitet wird, welchesdie erfolgsversprechensten Sicherheits-massnahmen sind und wie Zugriffsschutz,Prüfung der Authentität und Vertraulichkeitsensibler Daten im Netzwerk umgesetzt wer-den können.

Die 2. Auflage bietet zum einen eine Anpas-sung und Aktualisierung der technischenEmpfehlungen in allen Bereichen mit Erwei-terungen um Updates und neue Produkte,insbesondere in den Bereichen Firewall,Remote Access und Scanner.

Zudem ist der Report um mehrere Kapitelerweitert worden:

Secure eMail• Sicherstellen der Vertraulichkeit• Problem im heterogenen Umfeld• Organistaion und Key-Management• eMail im Geschäftsumfeld

Secure Remote Access• Konzept zur Vereinheitlichung von Schnitt-

stellen• Anforderungen an Netzzugänge und Nut-

zer• Organisatorische Einbindung

Scanner und IDS• Schwachstellenanalyse mti Security Scan-

nern• Network- versus System-Scanner• Produktbersicht• Security-Monitoring mit Intrusion Detection

Systemen• Produktübersicht• Network- versus System-based IDS

VPN• Unterschiedliche Möglichkeiten der Rea-

lisierung• Interoperabilität mit IPSEC

Mit seiner breiten Produktübersicht ist dieserReport die ideale Basis für die Auswahl desgeeigneten Produkts.

Zu beziehen ist dieser 200-seitige Reportzum Preis von DM 698,-- (EUR 356,88) überden Verlag.

ComConsultTechnologie Information GmbHeMail: [email protected]

Report "Netzwerk-Sicherheit"

Netzwerk-Sicherheits-Reportaktualisiert und erweitert!


Ausbildung zum ComConsult Certified Network Engineer

Fortsetzung von Seite 1

• Das Seminar Neue Ethernet Technologienwird um den Bereich Messtechnik undProtokoll-Analyse für die verschiedenenEthernet-Varianten ergänzt, der Themen-bereich Gigabit-Ethernet und die Produkt-und Marktsituation wird erweitert. Durchneue Referenten aus den Senior Beraternder ComConsult Beratung und Planungkonnte zudem die Anzahl der Termine er-höht.

• Das Trainingscenter der ComConsult Aka-demie in Aachen wird sich vergrößern.Unter anderem wird CISCO Works 2000weiter ausgebaut und als neues Tool für

die NT-Server-Überwachung neben denbereits vorhandenen Lösungen HP Ma-nageX installiert.

* Das Seminar Lokale Netze für Einsteigerwird mindestens einmal pro Monat ange-boten, so dass die Einsteiger in den Netz-werk-Bereich die Termine besser an ihrerindividuellen Zeitsituation orientieren kön-nen.

Der Ausbildungsplan zum ComConsult Cer-tified Network Engineer setzt damit Stan-dards in diesem Markt. Auch die bisherigenTeilnehmer an der Ausbildung bestätigen:die Ausbildung zum ComConsult CertifiedNetwork Engineer ist die ideale Basis:

• für eine fundierte und anerkannte Weiter-bildung und den damit verbundenen be-ruflichen Erfolg,

• für eine Absicherung des dringend benö-tigten Fachpersonals in den Unternehmen,

• für einen abgesicherten, optimalen underfolgreichen Einsatz von Netzwerk-Technologien.

Für Fragen zu dieser Ausbildung steht Ihnendie ComConsult Akademie gerne zur Verfü-gung.

(auch per Mail: [email protected]).

Anzeige

Die Seminare der Ausbildungzum

ComConsultCertified Network Engineer

Lokale Netzevermittelt die grundsätzlicheFunktionsweise, das Leistungs-spektrum, aber auch dieDefizitbereiche Lokaler Netze.Es bietet ein solides Fundamentfür den erfolgreichen Einstiegin den Netzwerk-Alltag.

Internetworkingvermittelt die technischen undmethodischen Kenntnisse zurerfolgreichen Strukturierungvon Netzwerken mit Switchingund Routing. Grundlagen-Kenntnisse Lokaler Netzwerk-Technologien sind erforderlich.

NeueEthernetTechnologienbefasst sich mit dem Ausbaubzw. Umbau dieser Netze inRichtung Fast Ethernet undFrame Switching für alleBetreiber traditionellerEthernet-Netzwerke.

TCP/IP und SNMPvermittelt einen detailliertenEinblick in TCP/IP, das sichmit herstellerübergreifendenNetzen hoher Funktionalität alsKommunikationsstandard durch-setzt und SNMP, als Standard füroffenes NetzwerkManagement.

Networking ist besser als Notworking – Historie des Netzwerk- und Systemmanagement


Die Autorin

Dipl. Inform. Petra Borowka,Studium Universität Dortmund.Langjährige Projekterfahrung mitverschiedensten Industrie- undDienstleistungsunternehmen imBereich Beratungsprojekte,standardbasierte Netzwerk-Planungen, Schulungen,Veröffentlichungen.Unternehmensberatung NetzwerkeUBN

[email protected]

Fortsetzung von Seite 1

1986-87

Die Ausgangssituation:Alles WC oder:

Dein Netz, das unbekannte Wesen

Nachdem nicht nur produktive Universitä-ten, sondern auch produktive Unterneh-men aus Industrie und Wirtschaft mehrereJahre von wachsenden Netzen überzo-gen worden waren, gerieten die Netzelangsam in einen zunehmend unüber-sichtlichen Zustand, oft mit "historisch ge-wachsen" umschrieben. Rückblickendkönnte hierfür auch die Bezeichnung WC-Netze (Wired Chaos) geltend gemachtwerden, die in einigen Fällen auch heutenoch anwendbar ist. Drei wesentlicheChaos-Faktoren kamen/kommen hierbeizum Tragen:

Das Netze-Knäuel

Zusätzlich zu einer Reihe internationalernebeneinander herlebender Normen (CS-MA/CD, Token Ring, Token Bus, späterFDDI) bestand die Netzlandschaft zusätz-lich aus einer Reihe weiterer zwar doku-mentierter, jedoch nicht standardisierterNetzwerke wie SNA-KOAX/SDLC, Apple-Talk (Zweidraht) oder Arcnet.

Das Protokoll-Wirrwarr

OSI-Datenkommu-nikation war zwarschon in Referenzmodellen und einer Rei-he von Standards spezifiziert, leider gabes noch keine verfügbaren Produkte. Da-her setzten sich heimlich und leise rechtsan OSI vorbei die sogenannten Schon-mal-vorab-Protokolle durch und haben bisheute die normative Kraft des Faktischenerfolgreich bewiesen. Hierzu gehören Ap-pleTalk/EtherTalk, DECnet, IPX, LAT, Net-BIOS, SNA mit oder ohne APPN, TCP/IP,UDP/IP, VINES/TCP um nur sehr bekanntezu nennen.

Der Betriebssystem-Dschungel

Um noch die dritte Dimension von RubiksZauberwürfel hinzuzubekommen, wardauch in der Arbeitsplatz-Systemwelt derWeg der Vielfalt beschritten: Da standDOS neben ersten Windows-Versuchen,naserümpfend beäugt von UNIX; OS/2wartete noch auf seine zweite Hälfte, diejedoch bald nachkam und die System-welt um ein weiteres Mitglied bereicherte.In den späten achziger Jahren wurde

das Spektrum um PC-Netzwerk-Be-triebssysteme bereichert (NOS: Noch einOperating System). Heute stehen uns desweiteren Windows NT, Chicago, OS/2.2mit Windows-Emulation und Solaris insHaus.

Erstaunlicherweise zeigte dieses Durch-einander im Groben und Ganzen bis aufdie durchschnittlich zwei monatlichenDrit tel- bis Totalausfäl le das Käfer-Syndrom: Es lief und lief und lief, nachMurphys erstem Axiom "Networking istbesser als Notworking". Die Ausgangs-Situation von Netzwerkmanagement wardaher die, daß es keins gab. Was es gab,waren im "Nicht-Laufen-Fall" Dissonanzenzwischen den Benutzern und dem Netz-werk-Betreuer nach dem Motto "Würg ihnnett ist besser als würg ihn not" (Deut-scher Adaptation Layer des ersten Mur-phy'schen Axioms). Was also tun? In denverschiedenen Lagern begannen unab-hängig voneinander kluge Köpfe darübernachzudenken, wie die existierenden WC-Netze oder besser gesagt die Viertel-,Drittel- und Ganz-Ausfälle besser in denGriff zu bekommen wären. Die ersten In-tuitionen erinnerten dabei stark an die Da-me mit dem Flickenkleid und der Glasku-gel.

Akt 1: Kastenwesen für Netzwerkfreaks,

PC-Gurus, Host-Operateure

Da Sicherheit immer ein Argument fürHostbetrieb war, entstanden hier Produkteder ersten Stunde. Hostmanagement-Protokolle und Applikationen (IBM's Net-View, SNI's Transdata Management) ver-suchten sich nicht ohne Erfolg am logi-schen und physikalischen Managementvon Datenkommunikations-Sessions. Al-

lerdings war der Einflussbereich dieserManagement-Applikationen völlig auf dieherstellereigene Protokoll- und Produkt-welt eingeschränkt. Schnittstellen zu LAN-Management-Werkzeugen gab es nicht.

In sehr viel eingeschränkterem Umfangentstanden PC-Netzwerk Management-Anwendungen, die sich anfangs auf reineKonfigurations-Umgebungen für Benut-zer-Profile und Systemauslastungs-Datendes Servers beschränkten. Später kamendann noch Monitordaten über das amServer angeschlossene Netzsegment hin-zu. Schnittstellen zum Hostmanagementoder zu anderen LAN-Management-Toolsgab es nicht.

Spezielle Analyse-, Diagnose-, Test- undFehlersuche-Funktionen für Netzwerk-Freaks (wenn das PC-Netzwerk-Manage-ment versagte) wurden von Spezial-werkzeugen wie por table Protokol l-Analysatoren (LAN und WAN) und Testge-räte für Kupfer- und LWL-Kabel etc. ange-boten. Nach dem Motto "mit dem Analysa-tor in der Hand kommen wir den My-sterien unseres Netzes auf die Spur"konnten dann die Netzwerker Protokoll-analyse betreiben, die Ethernet-Codie-rung im Hexcode bewundern, aber auchKollisionen oder Hardware-Fehler im Netzerkennen. Gelegentlich wurden zwar beiversuchsweiser Netzlastgenerierung (ins-besondere von Broadcasts, um die Be-lastbarkeit des Netzes auszutesten) Pro-duktiv-Hosts abgeschossen, aber auchhierüber wuchs immer wieder das Grasdes Vergessens. Hersteller der frühenAnalysator-Technik waren Rhode &Schwartz, Excelan (LANalyzer), Spider(SpiderMon), Network General (Sniffer),deren Begeisterung für Bits und Bytessich aus den Produktnamen heute nochentnehmen lässt.



SNMPv1 ProtokollstrukturBild 1

Objekt

Management

SNMP

Nachrichten

ManagementApplikation

ResponsesRequests

SNMP Manager

Link

IP

UDP

ManagedResources

SNMPManaged Objects

ResponsesRequests

SNMP Agent

Link

IP

UDP

Kommunikations-Netz

SNMP Management Station SNMP Managed Node

Trap

1988

Akt 2:Das Inter-nett prescht vor:

vom SGMP zum SNMP

"Im Internet läufts immer nett..." war vonverschiedenen Nutzern dieses weltwei-tenPionier-Netzwerks zu hören. Der drin-gende Bedarf nach einer wie auch immergearteten praktikablen Überwachung waralso gegeben. Und so hatte es begonnen:Bei einem elitären Abendessen in Mon-terey, Kalifornien, beschloss eine kleineGruppe von Netzwerk-Gurus, dass etwasgetan werden musste. Den ersten Ver-such startete ein Team von vier Ingenieu-ren: J. Davin, J. Case, M. Fedor, M.Schoffstall. Innerhalb von 2 Monaten hat-ten sie das SGMP definiert (Simple Gate-way Monitoring Protocol). Es ist unter RFC1028 (November 1987, 38 S.) im Internetnachzulesen. Wer weiß, daß Gateway in

jenen Jahren der gängige Begriff fürTCP/IP-Router war, erkennt den Focusdes Management-Interesses. In dennächsten Monaten wurde SGMP auf eini-gen Plattformen implementiert (im Gegen-satz zu ISO-OSI muß im Internet stets derpraktische Nachweis der Funktionsfähig-keit erbracht werden). Ab August wurdedas Protokoll langsam auch außerhalbdes Entwicklungsnetzes genutzt.

Ein konkurrierender Ansatz, HEMS (High-level Entity Management System) erwiessich nicht als praktikabel und kam nie-mals über die Entwicklungs-Umgebunghinaus.

Im April 1988 gab es IAB-Empfehlungen(Internet Activities Board) für Internet Ma-nagement Standards (RFC 1052, 14 S.).Schließlich wurde in den RFCs 1065, 1066und 1067 das SNMP, Simple Network Ma-nagement Protocol definiert. Auf der

Interop im September 1988 wurde SNMPder Öffentlichkeit präsentiert. Im April1989 erhielt SNMP den Status "recom-mended". In typischer Internet-Manierwurde die KIS-Philosophie verfolgt (KeepIt Simple). Die Idee war offensichtlich sobestechend, dass sie den vormals einge-fleischten OSI-Verfechter Marshall T. Rosezur Gegenseite überlaufen l ieß. AlsSNMP-Axiom wurde festgelegt: "Der Auf-wand, den die zusätzliche Management-Funktionalität in einem 'Managed Node'erfordert, muss minimal sein; er soll den'größten gemeinsamen Nenner' wiederge-ben" (Marshall T. Rose, The Simple Book,S. xvii).

Zusätzlich zu der anfangs sehr geringenFunktionalität konnten Hersteller über Pri-vate MIBs die Funktionalität erweitern:Wird der MIB-Baum auf Hersteller-IDs un-tersucht, so fällt auf, dass einige sichzwar die ersten Plätze reservierten (man



kann ja nie wissen), jedoch sehr lange mitSNMP-Produkten auf sich warten ließen.Hier läßt sich mit Proteon(1), IBM(1),CMU(3), ACC(5), Cisco(9), HP(10), Xylo-gics(15), Wellfleet (18), Excelan(23), Hug-hes LAN Systems(26), SCO(32), DEC(36),Sun Microsystems(42), 3COM(43), Synop-tics(45), Chipcom(49), ODS(50), Cable-tron Systems(52), Retix(72), AT&T(74),Ungermann-Bass(75), Netlabs(78), Lan-net(81), SNMP Research(99) unter den er-sten Hundert Firmen mit privater MIB-IDdas Who's Who der Netzwerk-Szenenachvollziehen. Heute läßt sich natürlichtrefflich mit der niedrigen ID werben.

Die ersten SNMP-Produkte tauchten Ende1988 von Cisco, ACC und Proteon auf. Eswaren proprietäre Management-Systemeder eigenen Produktwelt, die SNMP alsProtokoll benutzten.

Akt 3:Definition tut Not:

Was ist Netzwerkmanagement?

Während die Internet-Leute sich ans prak-tische Implementieren rudimentärer Netz-werkmanagement-Funktionalität machten,gingen andere Parteien prinzipieller zuWerk: Willst Du etwas ausprobieren,musst Du's erst mal definieren!

Hinsichtlich Netzwerkmanagement gabund gibt es mindestens zwei Definitions-Ansätze: Den der Hersteller: Netzwerkma-nagement ist das, was wir zur Zeit kön-nen, und wir können es am besten. Undden der Anwender: Netzwerkmanage-ment ist der selbsterweiternde, fehlertole-rante, vollredundante Betrieb und die voll-a u t o m a t i s c h e Ü b e r w a c h u n g d e sNetzwerks, die so vollautomatisch funktio-niert, dass das Netz zu 99,7% selbstkonfi-gurierend läuft, aber nicht so vollautoma-tisch, dass wir uns nach einer anderenTätigkeit umsehen müssen... Nachdembeide Seiten unvereinbar gegenüberstan-den, wird an dieser Stelle ein neutralerDritter hinzugezogen:

Definition (übersetzt nach Kornel Terplan,datapro Network Management, 1988):Netzwerkmanagement bedeutet - bezo-gen auf die eingesetzte Hardware undSoftware - die Fähigkeit, Netzwerk-Zu-verlässigkeit, Konfiguration, Sicherheit,Dienstgüte und Kosten festzustellen, zuüberwachen und zu kontrollieren; bezo-gen auf den/die Netzwerkmanager/in be-deutet es den Prozess der Planung, Koor-dination, Organisation und Steuerung allerRessourcen eines Netzes sowie der be-nutzergerechten Kostenfeststellung (Ac-

counting) unter betriebswirtschaftlichenGesichtspunkten.

Wie sich herausstellte, sind bei der tat-sächlichen Realisierung eines Manage-ment-Ansatzes einige Faktoren zu berück-sichtigen:

• Netzwerkmanagement-Architektur,d.h. Untergliederung in Management-Subsysteme innerhalb eines funktiona-len Gesamtrahmens, sowohl was dieHardware als auch was die Software be-trifft

• Netzwerkmanagement-Funktionen,d.h. die spezifischen Funktionen, die dieeinzelnen Subsysteme innerhalb desGesamtrahmens realisieren

• Netzwerkmanagement-Instrumente,d.h. die eingesetzten Tools für Daten-sammlung, Analyse und Leistungsbe-wertung

• Organisations-Komponenten,d.h. strukturelle Organisation der Mana-gement-Module, die zur Realisierungdes Netzwerkmanagements eingesetztwerden

• Organisations-Ansatz,d.h. Einsatz und Abschätzung vorhan-dener Erfahrung des Management-Personals sowie strategische Ausbil-dungs-Planung; diese Faktoren sind füreine langfristige Qualitätssicherung derKommunikationsleistungen nicht zu un-terschätzen.

Nachdem der Akt des Def in i t ions-Versuches erst einmal vollzogen wordenwar, wurde klar: ein Standard muss her.Wär doch gelacht, wenn dabei nichtsbesseres herauskäme als der hemdsär-melige Internet-Ansatz. Zur Implementie-rung der gewünschten Funktionalität aufeiner passenden Architektur gingen An-wender und Hersteller den langen Wegdurch die Institutionen.

Akt 4:O - SI mal:

C-MIP, -MOT, MOL(l)

Gesagt, getan, ISO OSI wurde aktiv. Alserstes wurde ein Protokollstack namensCMIP definiert (Common Management In-formation Protocol), der natürlich die OSIKommunikationsprotokolle zum Aus-tausch von Management-Informationenbenutzte. Da sich diese auch 1990 nochnicht auf breiter Ebene zur allgemeinenDatenkommunikation durchgesetzt hatten,

musste OSI-NM von Anfang an mit demHemmschuh leben, dass ein völlig sepa-rater Stack nur für Management geladenwird.

Im zweiten Schritt wurden die klassischenFunktionsbereiche für Netzwerkmanage-ment festgelegt: Fehlermanagement, Kon-figurationsmanagement, Performance Ma-nagement (Leistungs-Überwachung,Tuning), Accounting (welcher Dienst,wann, für wen und entsprechende Ko-sten-Verrechnung), Sicherheitsmanage-ment (wenn schon Netze, dann bitte so si-cher, dass keiner mehr draufkommt). Dieswar den Herstellern jedoch nicht genug,und außerdem brauchten sie etwas, umsich value added von OSI abzuheben,und so fügten sie noch Planung, RZ-Automatisierung, Integrierte Kontrolle (vir-tuelles Gesamtbild des Netzes) und Sy-stemmanagement hinzu.

Im dritten Schritt kam das, was bei OSIimmer unvermeidlich ist: Es wurden Mo-delle gebildet. (Der Mangel an Frauen imNetzwerkstandardisierungsbereich wirddurch den Einsatz von Models ausgegli-chen). Da gab es das Informations-Model(Datenmodell, Definit ion der Daten-strukturen als MIB und MIT: ManagementInformation Base, die im ManagementInformation Tree abgelegt ist), das Or-ganisations-Model (Match mit der Orga-nisations-Struktur) und das Funktions-Model (ohne Funktionalität geht sowiesonichts). Letzteres definierte die heuteklassisch gewordenen Bereiche Fehler,Konfiguration, Performance, Accounting,Sicherheit.

Nachdem CMIP einmal geboren war, gin-gen die Migrierer und Abspecker ansWerk: Bis sich OSI-Datenkommunikationdenn wirklich durchgesetzt hätte, solle aufden unteren Ebenen TCP/IP genutzt wer-den: CMOT (CMIP over TCP/IP) wurdegeboren. Allerdings blieb das Ding immerein ziemlich totgeborenes Kind.

Zur Beschleunigung der tatsächlichenProduktentwicklung und Definition vonKonformitäts-Merkmalen wurde 1988 dasNM-Forum ins Leben gerufen, ein über-greifender Interessen-Zusammenschluss,vor allem mit Herstellern besetzt. Zu denstimmberechtigten Mitgliedern aus derGründungszeit gehörten Amdahl, AT&T,BT, DCA, Digital, GEC, Hewlett-Packard,MCI, Northern Telecom, Unisys, Novell,Retix, Siemens, SNI, Synoptics und eineReihe anderer Netzwerk-Hersteller warenAssociate Members. IBM gehörte nichtdazu (Stand Juli 1989).



DME FrameworkBild 2

ANSI-CTivoli

C++IBM

CM-APIBull

ManagmentRequest Brokers

HP Postmaster Tivoli Objekt Dispatcher

Directory

Security

Event Services

CMIPHP

Other NetworksCommunication

ProtocolsOSITCP/IP

SMNPHP/IBM

RPCOSF

1989-1990

Akt 5:die hohe Zeit

des OSI-NM Forums

Schon bald kamen die Commitments der-großen Hersteller (IBM, Digital, Siemens,e.a.): Wir machen OSI-NM (böse Zungenbehaupten, die Entscheidung fiel schnell,weil die Entwicklung erkennbar komplexwar und kein Mensch von einem Herstel-ler ernsthaft erwarten konnte, innerhalb ei-nes Jahres ein OSI-Produkt zu haben).

Inzwischen hatte das OSI-NM Forum über100 Organisationen als Mitglieder. IBMwar als stimmberechtigtes Mitglied einge-treten. Die Release 1.0-Spezifikationenwurden herausgegeben und bis 1993 ein-gefroren.

Da die Entwicklung von CMIP in vollerSchönheit absehbar lange dauern würde(und dauert heute noch...) wurden Ab-speckversionen definiert: CMOL (CMIPover Logical Link) versuchte den Weg fürCMIP zu ebnen. Die IEEE versuchte sichin der 802.1B Arbeitsgruppe mit LAN-Management, insbesondere für Repeaterund Brücken. Da diese Geräte nur Intelli-genz bis zur Ebene 2 des ISO-OSI-Referenz-modells besitzen, wurden Mana-gement-Funktionen auf der Basis vonCMOL definiert. Das einzige Produkt, wassich in dieser Richtung ansatzmäßigdurchgesetzt hat, ist der IBM LAN Netz-werk Manager und planungsmäßig LANNetView. (mit kleinen Abstrichen fastCMOL). Nachdem jedoch LAN NetView indiesem September unter neuer Bezeich-nung NetView OS/2 nach SNMP migriertist, ist es nur noch eine Frage der Zeit, bisauch die letzte CMOL-Bastion SNMP zumOpfer fällt.

Parallel zu namhaften Commitments nah-men auch die OSI-NM-Standardisierer Sy-stemmanagement offiziell als Funktions-gebiet in die Standardisierungsarbeit auf.

Akt 6:Vor der Tat

kommt die Planung:Management-Architekturen

Nachdem die OSI-Modelle von den ein-zelnen Herstellern in SAO-Modelle (SellAs OSI) abgewandelt worden waren(nach dem Gesetz der zweiten Mur-phy'schen Ableitung: Nehme das Ur-sprungsmodell; vollziehe eine Drehungum 90 Grad, extrudiere in die dritteDimension, um die herstellereigenen

Zusatzfunktionen und Abweichungenplausibel als Add-On zu verkaufen), ver-breiteten sich verschiedene Architektur-Visionen im Markt: Da gab es EMA, Digi-tals Enterprise Networks Architecture; WoEmma kommt, darf Oma nicht fehlen:3COMs CMOL-Adaption war OMA OpenManagement Architecture, heute durchden futuristischeren Ansatz Transcend(wir machen alles auf allen etabliertenPlatt-Formen) abgelöst; UNMA als Um-brella System (der Schirm, der heute nochim Regen steht) mit der ersten CMIP-Implementierung: AT&T's Unified NetworkManagement Architecture; OV: HP'sschon damals weitsichtig benannte Open-View.

Wo alle Welt Architekturen baut, darf OSFnicht fehlen: Es erfolgte ein RFT (Requestfor Technology) für DME: Distributed Ma-nagement Environment, das als erster An-

satz die Belange von Systemmanagementin PC-Netzwerkumgebungen mitberück-sichtigte. Natürlich unter der Annahme,daß DCE eingesetzt wird (DistributedComputing Environment).

Für das existierende IBM-ManagementNetView gab es zu diesem Zeitpunktschon längst eine Architektur. Was IBMdamals unter Management offener Syste-me verstand, hörte sich so an: "Unter demNamen 'Open Network Management' hatIBM im Jahre 1986 eine architekturierteStruktur festgelegt, die es erlaubt unterdem Mantel des SNA-Netzmanagementsauch Nicht-SNA Kommunikationssystemezu unterstützen. Die Öffnung des Netzma-nagements wird erreicht durch

• Veröffentlichung der Netzmanagement-Architektur



inactive

AACHEN BONN

WARNING. . . . . . . .. . . . . . . .

ALARM. . . . . . . .. . . . . . . .

NetWare

DECnet

TCP/IPLOGFILE. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .

X.11

OSF/MOTIF

PM

UNIX, OS/2, VMS

SNMP, CMIP, NetView

TOOLS: EDITIEREN, ERWEITERN

SUN, HP, RS/6000

Token Ring Ethernet FDDI

Bild 3 Plattformsystem der dritten Generation

SQL

LIBRARIES

PROXYs

• Definition von Programmierschnittstellen,die Anwendern die Benutzung von Netz-management-Daten und -Befehlen er-möglichen.

• Die Unterstützung dieser offenen Schnitt-stellen in Netzmanagement-Produkten,mittels derer sowohl SNA- als auch nicht-SNA-Elemente des Netzes überwachtwerden können.

Die Grundstruktur dieser offenen Netzma-nagement-Architektur wird definiert durchdie drei Begriffe 'Focal Point', 'Entry Point'

und 'Service Point'." (K. Roehr, IBMDeutschland GmbH; Datacom Congress1989)

Alles klar? So blieb hier nur übrig, Schnitt-stellen und Migrationswege zu OSI insModell zu packen. Was schnellstens nach-geholt wurde. Danach wurde die NetView-Strategie zur SystemView-Strategie erwei-tert, die auch das Systemmanagement miteinschloss. Um dies vom IBM- zum gene-rellen Trend zu machen, sollten jedochnoch viele Diskussionsabende und zweiJahre ins Land gehen.

Akt 7:Aller Anfang ist schwer:

SNMP-Platt-Formen,erste und zweite Generation

Die erste Generation von SNMP-Systemenwurde etwa 1989 verfügbar. Es waren imwesentlichen DOS-basierte Konsolen mitMenü-Interface und einer flat file Daten-bank für Alarmmeldungen. Die Anwen-dungen waren sehr stark auf TCP/IP fi-xiert. First-Generation-Systeme waren z.B.Synoptics Lattisnet Manager, ProteonsOverView, Cabletrons Remote LAN-



VIEW/Windows. Lediglich Hughes NetDi-rector benutzte schon eine relationale Da-tenbank.

Die zweite System-Generation hatte sichvergrößert. Inzwischen war klar gewor-den, dass die Kapazität von DOS/Win-dows-Systemen für komplexere Netzwer-ke längst nicht ausreicht. Der neue Trend-setter waren UNIX-Systeme, meistensSuns. Die gelieferte Grundfunktionalitätbeschränkte sich auf grafische Oberflä-che, Netzkarte (für Ethernet), Autotopolo-gie für TCP/IP, Trouble Tickets und Stati-stik-Daten. Langsam wurden relationaleDatenbanken eingesetzt. Hier nutzte Sundie Gunst der ersten Stunde aus. Sie er-fand den SunNet Manager als Basis-Plattform, um darauf beliebige Anwen-dungen aufzusetzen. Niedriger Preis undeine unkompl iz ie r te Anwendungs-Schnittstelle ließen die meisten Internet-working-Hersteller auf diesen Zug sprin-gen. Dass dabei SNMP nur über Proxy-Agenten eingebunden wurde, weil Sun in-tern ihr proprietäres Protokoll benutzte(ONC, Open Network Computing) störtedabei außer puristischen Consultants nie-manden besonders. Weitere Systeme derzweiten Generation waren HPs OpenViewNode Manager, Ciscos NetCentral, Cable-trons Remote LANView/SunNet Manageroder Hughes Network Management Cen-ter. Die Integration von Dritthersteller-Produkten hatte sich außer HP und Sunjedoch noch keiner so recht auf die Fahnegeschrieben.

1991

Akt 8 (erstes Byte):Kampf der Giganten:

Hatten wir das nicht schon?

Gab es 1989 nur einige wenige SNMP-Produkte, so war im ersten Halbjahr 1990die Zahl der Ankündigungen schon aufca. 40 gestiegen. 1991 kam für SNMP derDurchbruch. Ende 1991 hatten alle nam-haften Hersteller der LAN-Branche ihrCommitment zu SNMP als vorübergehen-der Migrations-Strategie abgegeben.

Aber SNMP war nicht der einzige Schrift-zug auf der Fahne. Viele Hersteller zeig-ten in dieser Phase der Entwicklungs-Unsicherheit auch Interesse für OSI-NM.

Nach wie vor wurden heiße Diskussionengeführt: SNMP sei zu einfach, zu unflexi-bel, zu sehr auf das TCP-Protokoll fixiert,sei eigentlich nur auf Monitoring ausge-legt, wie der erste Name ja offen bekennt.Unvorstellbar, mit diesem Schnellschuss-

Protokoll komplexe Multivendor-Netze ver-walten zu wollen. Es gebe keine Möglich-keit, neue unternehmensspezifische Ob-jekte in SNMP zu definieren, die Welt seiauf Workstations, Terminalserver, Drucker,Router, Brücken, Hubs und Multiplexerbeschränkt. Vor allem das Polling! Dafürsei ja schon fast ein Extranetz erforder-lich. Und erst die Sicherheit! Überhauptnicht vorhanden in SNMP. Das alles undnoch mehr beinhaltete OSI-NM dagegen -auf dem Papier.

Völlig analog zum Kampf der Protokolle inder Datenkommunikation diskutierte OSIsich in den Vordergrund, während SNMP(genau wie TCP/IP, FTP, Telnet fünf Jahrezuvor) langsam aber stetig das Rennenmachte. Und heute sitzt diese einstigeFrühgeburt so fest im Sattel, dass sie fürdie nächsten 10 Jahre nicht mehr wegzu-denken ist. Auf der anderen Seite ent-schied sich die ITU-TS mit ihrem TNM(Telecommunications Network Manage-ment) jedoch einhellig für OSI-NM, da dieSNMP-Funktionalität nicht als ausreichenderachtet wurde.

Und so kämpfen sie heute noch. Oderglauben zumindest daran.

Akt 9:Management aus

der Client-Server-Ecke:OSF Rationale zu DME RFT

Was lange währt, wird vielleicht mal gut:Nach zweieinhalb Jahren Meetings unddem definitiven DME RFT-Aufruf am 31.Juli 1990 wurde im September 1991 eineEntscheidung über die 42 erhaltenen RFT-Rückläufe gefällt. Am 17. September 1991wurde sie der Öffentlichkeit in Pressekon-ferenzen in Boston, Paris und Tokyo be-kanntgegeben. Um die Entscheidung füroder gegen OSI bzw. SNMP hatte sich dieOSF elegant herumgedrückt: beide Proto-kolle wurden zugelassen. Ausgewähltwurden Produkte von HP (Postmaster,Software Distribution, Lizenz-Manage-ment), Tivoli/IBM (API, Object Dispatcher,Host-Management), Wang (Event Mana-gement) und Banyan/Gradient Technolo-gies (PC-Integration). Alle Eingaben vonDigital wurden abgelehnt. Unterm Strichgingen HP im Verbund mit IBM als Siegerund Digital als Looser aus dieser Rundenach Hause. Geniales Marketing von HPfür OpenView als DME-konformes Tool be-einflusste die Marktsituation zusätzlich,während in Wirklichkeit der HP Node Ma-nager als einzige nennenswerte OV-Anwendung mit DME sehr wenig zu tunhatte.

Akt 10:Synthese oder fauler Kompromiss?

SNMP Platt-Formen,dritte Generation

Nicht zuletzt im Kielwasser der DME-Bewegung wurde immer klarer: Integrati-on ist gefragt. So platt die Platt-Formen inihrer Funktionalität auch (noch) waren, siewaren dennoch die einzigen Systeme, dieein integratives Management ansatzweiseermöglichten. Nach wie vor war die besteFunktionalität, um eine bestimmte Netz-komponente wie Hub, Brücke, Router, Ter-minal-Server zu verwalten, in der Regelüber ein Spezial-Tool des Herstellersgegeben. Allerdings hatten die Plattform-Hersteller inzwischen gelernt: Die Syste-me wurden modularer, Benutzeroberflä-che, Komponenten-Applikationen, Kern-anwendung, Datenbank und Protokollewurden über Schnittstellen voneinandergetrennt, die Schnittstellen wurden doku-mentiert, und zum Teil in offengelegteSchnittstellen überführt (XMP X/Open Ma-nagement Protocol). Gleichzeitig stieg derDruck auf Komponenten-Hersteller, ihreManagement-Anwendungen in ein sol-ches Plattformsystem zu integrieren. Sy-steme, die sich Integratives Managementauf die Fahne geschrieben hatten, warenSPECTRUM, DECmcc, HP OpenView/IBMNetView 6000, NMC Vision, SunNet Mana-ger.

Für eine genauere Fehleranalyse, fallsdas rote Blinken einer ausgefallenenKomponente in der grafischen Netzkartenicht ausreichte, stand noch immer nichtwesentlich mehr als ein Analysator zurVerfügung, inzwischen erweitert um dasProbe-Konzept: Der Analysator stand zen-tral, der Netzbetreuer konnte sich von dortaus in entfernte Probes einloggen und diegewünschten Werte abfragen. Analysato-ren und Probes benutzten herstellerspezi-fische Anwendungen.

1992

Akt 11:Aus dem Entlein wird ein Schwan:

RMON und SNMPv2

Der Bedarf für RMON (Remote MONitoring)entstand aus zwei Wünschen.Erstens solltenschon lange verfügbare proprietäre Analy-sator-Funktionen (Sniffer von Data General,Network Advisor von HP, LANalyzer von No-vell, K1102 von Siemens, Spidermon vonSpider Systems, jetzt TTC e.a.) als Standard-Funktionalität in SNMP verfügbar werden.Zwei tens ärger ten s ich die SNMP-Netzwerker über die ständige Mäkelei sei-


Management Application N

Management Application 2

Management Application 1

ContextResolver’s

SNMP Protocollengine(s)

Transport Stacks (z.B. UDP/IP)

Network(s)

Local PartyDatabase

Management API

Bild 4 SNMPv2 Manager Modell

Benutzer Interface


tens OSI-NM, dass alles, was SNMP bis datoauf die Beine gestellt habe, nur mit giganti-schem Polling-Overhead einzukaufen sei.

RMON sollte die Polling-Last, die insbe-sondere bei remote Standor ten einschweres Handicap für SNMP-Einsatz

war, drastisch reduzieren.

RMON Working Group der IETF. Ihr gehö-ren Mitglieder der CMU sowie führendeHersteller aus dem LAN-Analyse-Umfeldan (Lexcel, Novell, Hewlett Packard, Fron-tier Software, Spider Systems e.a.).

RMON wurde zuerst für Ethernet (wensonst) im RFC 1271 definiert (November1991), für Token Ring im RFC 1513 erwei-tert (September 1993). Seit 1992 entstan-den eine Reihe RMON-Produkte und An-wendungen für Management-Plattformen,um RMON-Probes zu integrieren.

Während OSI weiter spezifizierte, bastelteIETF fleißig an der Erweiterung von SNMP.Über 50 RFCs und MIBs für unterschied-lichste Bereiche (X.25, Frame Relay, ATM,DECnet IV, AppleTalk, IPX, FDDI, Brüc-ken, Repeater, Drucker, RS-232, ...) ent-standen. Die IETF vergrößerte ihren Fo-cus offiziell über den TCP/IP-Bereichhinaus.

Unter dem OSI-Kreuzfeuer berechtigterKritik hatte sich die Gang of Four (Rose,McCloghrie, Waldbusser, Case) seit 1992um die Verbesserung der Welt bemüht.Diesesmal wollten sie es ganz richtig ma-chen. Der SecureSNMP-Vorschlag wurdeüberarbeitet (Juli 1992: SMP-Vorschlag)und überarbeitet (April 1993: verbesserteSMP-Version) und überarbeitet, bis end-lich im September 1993 das SNMPv2 alsSammlung von ca. 10 RFC's herauskam.Kommentar eines zeitgenössischen Bera-ters: "Endlich ist SNMP so kompliziert wieOSI geworden." Was auch der Grund ist,dass bis heute noch keine Manager-Applikationen mit entsprechenden Agen-ten-Gegenstückchen für Komponentenverfügbar sind. Aber im Prinzip hatSNMPv2 wesentliche OSI-Funktionen um-gesetzt: Sicherheit, Manager-Manager-Kommunikation, Domänenbildung, dyna-mische Objekt-Generierung, variable Pro-tokolle bis Ebene 4 des SNMP-Stacks.Sogar OSI TP4 ist erlaubt.

Akt 12:DME, Euphorie tut weh

und: OSI wehrt sich

Da sich die Verfügbarkeit der angekün-digten Produkte gemäß OSF RFT weiterund weiter hinauszögerte, begann dasVertrauen in DME zu sinken. Die Ausliefe-rung der Basis-Produkte für DCE (die Dis-tributed Services Elements) sollte erst imDezember 1993 wahr werden. Und soteilte OSF die Aktivitäten in einen DCE-Teilund einen DME-Teil (Network Manage-ment Option). Inzwischen galt die Regel:Wie hältst Du einen Kunden hin? Du bie-test ihm ein Interim! Migrationsprodukteund Implementierungen auf Draft-Basisversuchten sich am Markt. Die endgültigeAuslieferung der Network ManagementOption steht aktuell noch immer aus(Schedule: Ende 1994).

Token Ring (10)

Events (9)

Filters (7)

Matrix (6)

Host Top N (5)

Hosts (4)

Capture (8)

Alarms (3)

History (2)Statistics (1)

MIB I

MIB II

ISO (1)

Organisations (3)

DoD (6)

Internet (1)

Mgmt (2)

MIB I & IIRMON

Bild 5 RMONv1 MIB Struktur



1993-1994

Um OSI-NM mehr praktischen Boden un-ter die Füße zu schieben, hatte das NM-Forum beschlossen, System- und Netz-werkmanagent zu Service Managementauszuweiten. OMNIPoint spezifiziert eine

"Offene Management Infrastruktur" mit fol-genden Elementen: Management-Dienste;externe Kommunikations-Dienste undSchnittstellen, die für Manager-Manager-Kommunikation erforderlich sind; verwal-tete Objekte; Applikations-Schnittstellen.Bestimmte Datenbanken oder Manage-

ment-Protokolle sind nicht mehr vorge-schrieben. Empfohlen wird CMIP oderSNMP oder DME (!).

Außerdem gibt OMNIPoint den Manage-ment-Implementierern für ITU Implemen-tierungshilfen für ihr gehegtes TMN.

Cisco WorksOptivity

Transcent

LotusNotes View

OracleServer

Manager

NodeManager

Process Center: Common Services, "Platform" (NNM)

Performanceund RecourceManagement

(PerfView,NetMetrix,...)

Config/ChangeManagement

(IT/Admin)

ProblemManagement

(IT/Operations)

Integrationsdienste

OperatorConsole(n)

Discovery Netzkarte EventBehandlung

Daten Handling

Netzkomponenten Endgeräte Server Applications Datenbanken

Vertikale Applikationen

Ho

rizo

nta

le D

ien

ste

Bild 6 Integriertes System- und Netzwerkmanagement



Akt 13:Nach der Trennung die Neue Einheit:System- und Netzwerkmanagement

Nachdem in Unternehmen, wissenschaftli-chen Arbeitskreisen und Herstellerforenabendfüllende Diskussionen, wo denn dasNetz endet und das System anfängt, im

NICHTS geendet hatten, kam schließlichheraus: Alles ist ein gesamtvernetztes Sy-stem... Da für die Alltagsarbeit und insbe-sondere in diffizilen Fehlerfällen sowiesoKnow How über Netz und System gebrauchtwird, erkannten die führenden NM-Hersteller,was IBM schon seit 1991 in die Architekturmiteingebracht hatte: Es funktioniert das

eine ohne das andere nicht. HP kündigtesein Operations-Center an, Novell zeigteBestrebungen, sein User-Management (Net-Ware Management System) in Plattformenzu integrieren. Zunehmend rückten HelpDesk und Dokumentations-Tools ins öffent-liche Interesse. Der neue Trend wurde SNU(Systems- Network-, User Management).

MIB I

MIB II

ISO (1)

Organisations (3)

DoD (6)

Internet (1)

Mgmt (2)

MIB I & IIRMON

Bild 7 RMONv2 MIB Struktur

Applikation Layer Matrix (17)

User History (18)

Probe Configuration (19)

Conformance (20)

Network Layer Matrix (15)

Network Layer Host (14)

Address Map (13)

Protocol Distribution (13)

Protocol Directory (11)

Token Ring (10))

Events (9)

Applikation Layer Host (16)

RMONVersion 1

. . . .



Akt 14:Familienleben ist alles:

Ehen, Scheidungen, Sterbefälle

Nachdem die NM-Aufbruchsphase nunendgültig in produktives Business über-ging, konnten Marktbereinigungen nichtausbleiben. Im August 1993 wird EMA

endgültig begraben, DECmcc - so die An-kündigung - wird nach NetView/6000 por-tiert werden. Die Firma Network Managers(NMC Vision) reduziert ihre Aktivitäten inEuropa mangels Markterfolg erheblich.Der SunNet Manager gerät in Schwierig-keiten (hier rächt sich, daß das Tool im In-neren nie aus SNMP bestand und nicht

modular war). Als Rettungsring wird eineZusammenarbeit mit Netlabs installiert(in der Not frisst der Teufel Fliegen). IBMreicht die Scheidung von OpenView einund geht in Richtung ObjektorientiertesManagement in die Ehe mit Tivoli.

Einige Beispiele

SNMP über IPX und SNAP

16. 0.0.0.3. 0.0.129.55. 0.0.0.144.15 3.0.0.0

snap ipx 0x900F 0x8137 [RFC 1420]

SNMP über UDP/IP und SNAP

16. 0.0.0.3. 0.0.8.0. 0.0.0.17. 0.0.0.161. 4.0.0.0.0

snap ip ndp snmp Port-ID

HTTP; IP-Fragmente oberhalb korrekt zählen

16. 0.0.0.1. 0.0.8.0. 0.0.0.6. 0.0.0.8.0. 4.0.1.0.0

ether ip tcp http

Bild 8 Protokolldefinition unter RMONv2



Akt 15:Letztendlich alles fragwürdige Objekte:

Objektorientiertes Management

1995-1996

Da Management sich letztendlich immerum verwaltete Objekte dreht, war die logi-sche Konsequenz die Entwicklung vonObjektorientiertem Management. Tivoli,die seit DME im Aufwind lebt und wech-selnd von HP und IBM umworben wurde,erfand TME (Tivoli Management Environ-ment) für eine standardisierte Verwaltungverteilter UNIX-Systeme: Was tun wir,wenn uns nichts gefällt? Ein Interface wirdhergestellt. Zwischen die Anwendung unddas mehr oder weniger komplizierte her-stellereigene UNIX-System wird ein Inter-face geschoben, das die hässlichen Sy-stemeigenschaften verbirgt. Das Ganzeist unter dem Tivoli Object Oriented Fra-mework nachzulesen. Es wurde nicht nurvon OSF als DME-Basis akzeptiert. DieWeiterentwicklung der Framework Ideegipfelte in dem CORBA Standard (Com-mon Object Request Broker) als allgemei-nes Zugriffs-Interface für Management-Objekte.

Was geschah inzwischen in der SNMPFraktion? Aus der Gang of Four wird derBang of Four: Die SNMPv2 Arbeitsgruppezerfleischt sich in Streitigkeiten um Ob-jektzugriffe und Verschlüsselung (da sichdie USA immer noch hartnäckig weiger-ten, DES mit der in SNMPv2 vorgeschrie-benen Schlüssellänge von der Exportver-botliste zu streichen - hoch lebe derCIA ...!), bis der Chairman erbittert dieGruppe auflöst und alle für ein Jahr nachHause schickt - AUS für SNMPv2 undNachdenken im stillen Kämmerlein ist an-gesagt. Sehr zum Ärger von HP, die über-eifrig mit viel Arbeitsaufwand SNMPv2Funktionen in OpenView hineinimplemen-tiert hatten. Auf der Basis von SNMPv1hat sich in aller Stille RMON als Analyse-und Überwachungsstandard etabliert, dieRMON-Erweiterung auf Netzwerk-und alleetablierten höheren Protokolle ist in Vorbe-reitung.

Unterdessen bastelten die Praktiker weiteran der Integration von Netzwerk- und Sy-stemmanagement. In den Mittelpunkt desInteresses rückte die Verwaltung von Ser-vern und remote Verwaltung von PC-Systemen. Vernünftige SQL Datenbankenetablierten sich bei den High End Platt-formsystemen von Cabletron, HP, IBM.SNI taucht nach dem Erwerb des NerveCenter mit TransView als neuer Stern amHimmel der Plattformhersteller auf. Sununternimmt einen letzten verzweifelten

Versuch, mit der Umbenennung auf Sol-stice Domain Manager (SNMP) und Sol-stice Enterprise Manager (CMIP!) imNetzwerkmanagement-Markt mitzumi-schen. Für das Management von PC-Netzen treten Intel (Landesk Manager),Microsoft (SMS) und Novell (ManageWi-se) ins Scheinwerferlicht, die Desktop Ma-nagement Task Force sieht sich im Auf-wind. DMI so schön wie nie: Als DMTFStandard für PC-Management wird imMärz 1996 DMIv2.0 verabschiedet. Er ent-hält eine Architektur für PC-Managementund darüberhinaus als erster Standardnicht nur ein Funktions- sondern auch einDatenmodell.

Akt 16(zweites Byte):

Aus der Einheit zur Vielfalt:Frameworks und Point Solutions,

SNMP und HTTP,Webmanagement und Objektorientierung,Trouble Ticketing und User Help Desk

1997-1998

Da ein Request Broker allein noch keineAnwendung macht, sollten auch die Ob-jekte der Begierde, die Managed Objects,standardisiert werden. HP und IBM kon-kurrierten in einem Heiligen Krieg der Ent-wicklung von Metafiles und Metaebenenzu den Metafiles und Metaebenen zu den

Metaebenen. Dennoch erwies sich derCORBA/Metafile-Ansatz als zu komplexund scheiterte als Integrator für Manage-ment-Applikationen. DMI und CORBA hat-ten jedoch Netzwerker und Systemhers-teller inspiriert und zusammen mit dersteigenden Bedeutung von Webtechnolo-gien entstand eine neue Welle: Webbingist in! Also wird wwwebbasiertes Manage-ment die Integrationskraft der Stunde. DieWBEM Initiative (Web Based EnterpriseManagement) war im Juni 1996 mit insge-samt 60 Mitgliedern unter Führung vonBMC, Cisco, Compaq, Intel und Microsoftgegründet worden. Ziel war die Schaffungeines einheitlichen Datenmodells und dieNutzung von Webtechniken (Browser-oberflächen und HTTP) für System- und ingleicher Weise Netzmanagement. Nurwirklich boshafte Zungen behaupten, dasGanze sei ein Gegenschlag von Billy theGates gegen HP und IBM... Erste Arbeits-ergebnisse zeigten sich im April 1997 mitCIMv1 (Common Information Model). Al-lerdings erwiesen sich hier die Lückenentscheidender als die Substanz, da Im-plementierungen ausblieben. So folgtebei gleichzeitiger Integration der umfang-reichen DMI-Spezifikationen im März 1998CIMv2 und eine Reihe von Ankündigun-gen, v2-kompatible Produkte herauszu-bringen (CA, Cisco, HP, IBM, Intel, Micro-soft,...). Im August 1998 wanderte WBEMunter das Dach der DMTF.

!

100

Mb

it L

WL

Etagen-Switch

98 %

% U

TI

Gebäude-Switch

1 Gbit LWL

10 %

% UTI ?

Traffic= 98 %

CAD-Pool

ALERT!

1 Gbit LWL

15 %

% UTI ?15 %

20 %

weitere Server

weitere Gebäude

niedrigere Prio oder "disable"

% UTI ?

!

Übergreifendes Management mit WBEMBild 9

3 % 2 %

NetworkOperator

ALERT!!! Timeoutder Applikation

“Lohnbuchhaltung”



Das Aus für Plattformsysteme? Mitnichten.Sie entwickelten sich weiterhin als Mam-mutsysteme der integrativen Art hin zu so-genannten Frameworks: PC-, Server-, Netz-werkkomponenten-Managagement untereinem Dach, mit entsprechend hohen Ko-sten und Entwicklungsaufwand. Ganze Fir-men beschäftigen sich mit der Umsetzungvon Management-Projekten in Millionenhö-he. Parallel werden die Plattformlösungenin abgespecktem Umfang auf NT angebo-ten. Während die Zahl der käuflichen Mo-dule für OpenView und TME ständigwächst, ist Ende 1998 zunehmender Unwil-le insbesondere bei den führenden Inter-networking-Herstellern zu spüren, jedeneue Komponente und Software-Versionwieder und wieder in komplexe Frame-works zu integrieren. Zunehmend werdenaufgebohrte standalone Element Managerauf Basis NT vermarktet (Cisco Works, Op-tivity, Transcend Enterprise Manager etc.).

Auch die SNMP-Bewegung wacht ausdem Dornröschenschlaf auf und bringtsich mit SNMPv3 als abgemagerter Kom-promiss der Version 2 wieder in Erinne-

rung. Nach den bitteren Erfahrungen mitmit Version 2 ist allerdings nur wenig Eu-phorie und Implementierungs-Wille bei denHerstellern erkennbar. Anders mit derSNMP-Schwester RMON: 1997 wird dieVersion 2 verabschiedet, die Protokollver-tei lung und Stat ist iken für viele IP-Applikationen (FTP, HTTP, NFS, SMTP, Tel-net, ... Appletalk, DECnet, IPX, SPX, NCP,SAP und die Konfigurierung der Probeselbst standardisiert. Ende 1998 gibt eseine Reihe von RMONv2Probes, RMONv1gehört zur Standardsoftware aller etablier-ten middle und upper c lass Hub-,Layer2-, und Layer3-Switchprodukte.

Nach wie vor gibt es jedoch nicht den gro-ßen Integrations-Durchbruch. Zur Automa-tisierung werden die gelösten und beson-ders die ungelösten Probleme in Ticketsgepackt, und wenn den Benutzern schonnicht wirksam geholfen werden kann, sol-len sie sich wenigstens DV-gestützt am Tre-sen ausweinen: Trouble Ticket Systemeund User Help Desk Lösungen zurUnterstützung von In- und Outsourcing Or-ganisationen sind neue Sterne am Mana-

gement-Himmel. Natürlich immer mit einerSchnittstelle zu den Frameworksystemenund deren Datenbanken - wenn auch in ei-nigen Fällen nur als Feigenblatt und untererheblichem Programmieraufwand zur An-passung beider Bereiche aneinander.

Odyssee 2005:Quo vadis Management?

Da der Anwender eigentlich überhauptnichts und der Netz-Betreuer zunehmendweniger von Netzwerkmanagement-Detailswissen will (stellt Euch vor, es ist Netz undkeiner muß hingehen ..!) könnte sich biszum Jahr 2005 GOLEM durchsetzen (Glo-bal Outsourced Licensed Electable Mana-gement). Es gibt dann Global-Netzwerk-management-Anbieter unter den Out-sourcern, die nach Anzahl der zu betreu-enden Benutzer lizensiertes, in Funktions-modulen auswählbares Management alsDienst anbieten. Ob die dann SNMP undPolicy mit DEN und LDAP oder CIM mitHTTP und Policy mit SUSI machen, kanndem Anwender Wurscht sein.

ObjectProvider

ObjectProvider

ObjectProvider CIM

Repository

CIM Objekt Manager

ODBCActiveXControls ADSI

DatenbankApplikation Web Browser Directory

ApplikationManagementApplikation

WBEM ArchitekturBild 10



Literatur

– Case J., Davin J., Fedor M., SchoffstallM.: Introduction to the Simple GatewayMonitoring Protocol; IEEE Network, Vo.2 No. 2, March 1988

– Datapro Network Management: SNMPProduct Guide Part 1; McGraw Hill Oc-tober 1990

– Datapro Information Services: OpenSoftware Fundation Distributed Mana-gement; McGraw Hill Juni 1994

– IEEE: Draft Standard 802.1B LAN/MANManagement; 8. März 1990

– Network Management Forum: Discover-ing OMNIPoint; Prentice Hall, 1993

– OSF: Distributed Management Environ-ment, Rationale, September 1991

– Roehr, K.: Management offener Syste-me; Datacom Congress 1990

–Rose, M.T.: The Simple Book

Global Outsourced Licensed Electable Management

Internet, Ein Transatlantisches Fantom

Immer So Old-fashioned

Noch ein Operating System

Oh, Sicher, Irgendwann...

Systems-, Netzwerk-, User-Management

SuperVision of User-Systems-Integration

Wired Chaos

GOLEM

IETF

ISO

NOS

OSI

SNU

SUSI

WC

G

I

N

O

Abkürzungen

S

W

CIMOM - API

Quelle: Microsoft/UBN


Anzeige

Ausbildung zum ComConsultCertified Network Engineer

Termine 2000

Lokale Netze für Einsteiger

Einzelpreis: DM 3.500,-- (EUR 1.789,52) zzgl. MwSt.

24.01. - 28.01.00 in Aachen 14.02. - 18.02.00 in Aachen 13.03. - 17.03.00 in Aachen 10.04. - 14.04.00 in Aachen 15.05. - 19.05.00 in Aachen 05.06. - 09.06.00 in Aachen 26.06. - 30.06.00 in Aachen 04.09. - 08.09.00 in Aachen 16.10. - 20.10.00 in Aachen 13.11. - 17.11.00 in Aachen 11.12. - 15.12.00 in Aachen

Internetworking


14.02. - 18.02.00 in Aachen 27.03. - 31.03.00 in Aachen 05.06. - 09.06.00 in Aachen 18.09. - 22.09.00 in Aachen 04.12. - 08.12.00 in Aachen

Neue Ethernet Technologien


27.03. - 31.03.00 in Aachen 22.05. - 26.05.00 in Aachen 23.10. - 27.10.00 in Aachen 04.12. - 08.12.00 in Aachen

TCP/IP und SNMP


07.02. - 11.02.00 in Bonn 10.04. - 14.04.00 in Berlin 05.06. - 09.06.00 in Hamburg 04.09. - 07.09.00 in Bonn 23.10. - 27.10.00 in München 11.12. - 15.12.00 in Hamburg

! Mit !Palm IIIx

Nutzen Sie unserePaketpreise!Buchen Sie drei beliebige Seminare unserer Ausbildungzum ComConsult Certified Network Engineer und Siezahlen statt mindestens DM 10.770,-- nur den Paketpreisvon DM 9.800,-- oder EUR 5.010,66 zzgl. MwSt.

Sonderaktion 1999:Komplett-Paketmit Palm IIIxBuchen Sie die komplette Ausbildung zumComConsult Certified Network Engineermit den Seminaren "Lokale Netze", "Internetworking","Neue Ethernet-Technologien" und "TCP/IP und SNMP"zum Paketpreis von DM 12.800,-- oderEUR 6.544,54 statt DM 14.560,-- zzgl. MwSt.,erhalten Sie bei der Buchung bis zum 31.12.99als Bestandteil des Seminarpaketeszur Planung Ihrer Akademie-Termineeinen 3Com "Palm IIIx"

Date post:	20-Mar-2022
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Der Netzwerk Insider - November 1999

Documents