Netzwerk-Monitoring und -Analyse
Für gutes "Netzwetter" sorgen
Die Probleme des Netzwerkalltags sind bekanntlich vielfältig: Sporadische Verbindungsabbrüche, Überlastungssituati-onen oder schlechte Performance können unterschiedlichste Ursachen haben und sind nie ganz auszuschließen. Die kontinuierliche Überwachung des Gesamtnetzes ist daher ebenso wichtig wie der rasche Detailblick auf kritische Punkte. Der Beitrag gibt einen aktuellen Überblick über Technik und Einsatz von Netzwerk-Monitoring und -Analyse.
Im praktischen Einsatz verwischen sich oft die Grenzen zwischen Netzwerk-Monitoring, -Analyse
und -Management. Die Begriffe werden oft nicht sehr klar differenziert und missverständlich
genutzt. Dabei unterscheiden sich die drei genannten Disziplinen doch recht deutlich.
Netzwerk-Monitoring: Es definiert die (passive) Beobachtung von Datenströmen über längere
Zeiträume. Dabei läuft auf einem Netzwerksystem ein aktiver Prozess, der durch Datensammlung
vielfältige Parameter wie Netzwerklast, Protokollaufkommen oder Antwortzeitverhalten aufzeichnet.
Der Schwerpunkt von Monitoring zielt weitgehend auf die Generierung von Statistikdetails ab. Die
Daten werden in der Regel durch eine zentrale Plattform ausgewertet und mit einer
Reporting-Applikation in die "lesbare Form" eines Berichts verwandelt.
Daten- oder Paketanalyse: Sie zielt auf tiefer in den OSI-Schichten (siehe Glossar) des
Kommunikationsgeschehens liegende Informationen ab. Hier lassen sich bis in kleinste Details Fehler
im Datenrahmen oder im Verhalten von Stationen und Protokollen aufzeichnen und dekodieren.
Datenanalyse kommt traditionell als "Reaktionsdisziplin" zum Einsatz – meist in Ausnahmesituationen
und in Fehlerfällen. Die Bedeutung der klassischen Netzwerkanalyse ist in den letzten Jahren
gegenüber der des Monitorings beziehungsweise Managements etwas zurückgegangen. Meist lässt sie
sich nur in der "Distributed"-Form sinnvoll nutzen.
Netzwerkmanagement: Es unterscheidet sich von den bereits genannten Disziplinen vor allem durch
seine "aktive Beschaffung" von Datenwerten, besonders durch das SNMP-Protokoll. Hierbei werden
zyklisch entweder standardmäßige Statistikdetails (zum Beispiel der MIB II, IETF/RFC1213) oder
spezifische Informationen (private MIBs) gepollt, oder durch zuvor gesetzte Schwellenwerte
Alarmnachrichten (Traps) versendet und verarbeitet. SNMP-Polling fragt regelmäßig die
Statistik-Counter (Zählregister) der Endgeräte und Netzwerksysteme ab und liest sie in dedizierte
Datenbanken ein. Zusätzlich zur Beschaffung von Daten eröffnen die SNMP-Set-Kommandos die Option,
Geräte zu konfigurieren.
Flowbased-Monitoring und -Analyse
Obwohl bereits seit einigen Jahren "etabliert", entwickelt sich die Disziplin des so genannten
Flow-Monitorings zu einem wichtigen Trend. Im Gegensatz zur massenhaften Aufzeichnung und
Speicherung beziehungsweise Verarbeitung von Paketen bei der klassischen Analyse erfasst die
Flow-Analyse Datenbeziehungen (Flows) zwischen Stationen oder IP-Adressen. Eine Flow-Tabelle
registriert die Datenpakete entweder im "Sample Mode" (zum Beispiel jedes zehnte Paket) oder Paket
für Paket. Durch das deutlich geringere Datenaufkommen im Vergleich mit der Analyse lässt sich
Flow-Monitoring auch in Routern oder Switches per CPU oder ASIC realisieren.
Um das Datenvolumen insbesondere bei Core-Switches oder Routern nicht ausufern zu lassen, werden
statt der Datenpakete lediglich eine Statistikinformation mit allen Details als Update an einen
zuvor konfigurierten Empfänger (Flow-Kollektor) gesendet und die Information aus dem Speicher
gelöscht. Die dominierenden Flow-basierenden Analyse-Verfahren sind Netflow (Cisco-gestützt)
beziehungsweise S-Flow (Foundry-gestützt). Flow-Monitoring/-Analyse stellt einen Kompromiss
zwischen der sehr genauen Paketanalyse und der Statistikstrategie von SNMP-Polling dar. Neue
Flow-Technologien wie zum Beispiel das von Q1labs entwickelte Qflow basieren auf einem ähnlichen
Grundmodell, konzentrieren sich jedoch auf besondere Überwachungsaspekte wie hier die
Anomalieerkennung und Sicherheitsanalyse.
Viele Methoden der Analysetechnik versuchen, technische Messwerte und Zustände für Benutzer zu
interpretieren und Rückschlüsse über die Ursache von Ausfällen, Performance-Einbrüchen oder
Ähnlichem zu ermitteln. Dies wird oft als Root-Cause-Analyse bezeichnet. Problematisch ist hierbei
oft die Bewertung von Einzelfehlern im größeren Zusammenhang: Netzwerk-, server- und
applikationsspezifische Besonderheiten lassen sich nicht ohne weiteres klar visualisieren. Oft
erschwert die Komplexität der IT-Infrastuktur die Analyse, und manchmal unterschätzt der Anwender
den Einfluss scheinbar vernachlässigbarer Messwerte. Gelegentlich fehlen zur richtigen Beurteilung
auch entscheidende Zusatzinformationen, da sie sich beispielsweise nicht über SNMP-Polling
beschaffen lassen.
Hier setzen aktive Testverfahren an, die ebenfalls zunehmend an Bedeutung gewinnen. Sie nutzen
die reale IT-Umgebung, um von verschiedenen Netzwerkzugangspunkten und damit von unterschiedlichen
Blickwinkeln aus Netzwerksysteme, -dienste oder -applikationen standardisiert zu testen und
periodisch deren Qualität (Verfügbarkeit und Performance) zu überprüfen. Die einzelnen Testpunkte
verhalten sich dabei wie gewöhnliche Nutzer. Durch die Zusammenführung der "Teilansichten" entsteht
ein sehr plastisches Qualitätsbild der aktuell verwendeten Geschäftsprozesse. Die Flexibilität
dieses Verfahrens erlaubt je nach Art der Lösung sogar die Simulation von Benutzeranmeldungen sowie
Applikationstests innerhalb von Terminal-Server-Umgebungen. Allerdings ist die Qualitätsmessung
nicht kontinuierlich, da die Tests periodisch ablaufen und somit Messlücken entstehen.
Problem der Mikrosegmentierung
Alle beschriebenen Verfahren haben in realen Netzen ihre Daseinsberechtigung. Letztlich
unterstützen sie das Streben nach möglichst geringer IT-Downtime, höchstmöglicher Verfügbarkeit und
einer guten Performance. Zur Differenzierung und als Entscheidungshilfe für den praktischen Einsatz
empfehlen sich aber noch ein paar weitere Betrachtungen.
Historischer Analyseansatz: Klassische LAN-Topologien wie Thick/Thin-Ethernet, Token Ring
beziehungsweise FDDI sind stets Shared-LAN-Architekturen, bei denen sich eine Anzahl von Geräten
das gemeinsame LAN-Medium teilt. Ein Fehler innerhalb des Netzes wirkt sich für alle Teilnehmer
einschließlich des Analysators gleichermaßen sichtbar aus. In diesem traditionellen Szenario reicht
ein einziger Analysator – zum Beispiel pro Broadcast-Domäne – aus.
Switching und die Konsequenzen in der Messtechnik: Die rasante Verbreitung der Switching-Technik
führt aufgrund der Mikrosegmentierung nahezu zur Undurchführbarkeit einer flächendeckenden Analyse.
Während ein 24-Port-Hub noch über ein gemeinsames LAN verfügt, besitzt jeder 24-Port-Duplex-Switch
bereits 48 Segmente (24 Ports mal zwei Duplexsegmente): Die Daten zwischen einzelnen Teilnehmern im
LAN entziehen sich damit dem Analyzer beziehungsweise der "Probe". Es bedarf also neuer Verfahren,
die Kommunikation zwischen den Stationen sicht- und damit analysierbar zu machen.
Tricks und Kniffe in der Datenanalyse
Ohne trickreiche Hilfestellungen, seien sie selbst beschafft oder durch die aktiven
Netzwerkkomponenten bereitgestellt, ist eine erfolgreiche "Brandbekämpfung" innerhalb von modernen
Infrastrukturen kaum möglich. Grundsätzlich gilt: Es lassen sich nur Daten analysieren und
beurteilen, die zuvor von einem Prozess, einem Agenten oder einem Probe-System bereitgestellt
wurden. Nachfolgend eine Reihe von Techniken, die sowohl für Monitoring als auch für Analyse
nutzbar sind:
Mess-Hub: Die zu messende Verbindung wird aufgetrennt und über einen
herkömmlichen Hub geführt. Alle Datenpakete lassen sich dann auf dem "Shared-Half-Duplex"-LAN von
einem Analysator messen und auswerten. Die Lösung ist zwar preiswert, aber auch verfälschend (zum
Beispiel durch den zwingenden Wechsel auf Half-Duplex).
Mirror-Ports: "Intelligente" Switches bieten oft Spiegel-Ports ("Mirror"- oder
auch "Span"-Ports). Dabei lassen sich einzelne LAN-Ports oder VLAN-Segmente auf den Spiegel-Port
zur Analyse kopieren. Obwohl diese Lösung komfortabel und ohne Unterbrechung konfigurierbar ist,
weist sie auch Schwächen auf. So lassen sich manche Fehler im Original (zum Beispiel CRC-Fehler)
nicht über die ASICs transportieren, und die Messdaten sind damit nicht authentisch. Die Anzahl der
Mirror-Ports ist zudem meist begrenzt, und Lastspitzen können die Kapazität von Span-Ports
überfordern. Aber auch eine Überlastung der Switch-CPU kann die Mirror-Funktionen beeinträchtigen.
Auf jeden Fall lässt sich eine authentische Analyse nicht garantieren.
Analyse-Taps: Die Datenverbindung (Kupfer oder Glas) wird in einem Adapter
unter möglichst geringem (Dämpfungs-)Verlust abgegriffen. Eine Kopie der Nutzdaten steht an einem
für Analyse/Monitoring nutzbaren Port (TAP) in Originalform zur Verfügung – das heißt
einschließlich aller Bit- und Datenfehler. Taps sind in einer Fülle von Spezialausführungen
erhältlich: zum Beispiel Konverter-Taps, Mehrgeräteabgriffe, schalt- und managebare Taps oder
Intrusion-Prevention-Taps. Neu sind so genannte Aggregations-Taps, die die Datenanalyse auch mit
Standardnetzwerkkarten erlauben, da sie beide Duplexdatenkanäle per Buffer "summieren" und an eine
einzelne gemeinsame Analyseempfangsleitung weiterleiten.
Distribuierte Analyse- und Monitoring-Systeme
Eine traditionelle Methode der Analyse stellt die Verwendung einer Messplattform in Verbindung
mit dedizierten Hardware-Probes dar. Diese fungieren als Datensammler und sind meist an kritischen
beziehungsweise neuralgischen Knotenpunkten im Netzwerk platziert. Der Zugriff vor Ort kann über
die bereits beschriebenen Verfahren erfolgen. Unterscheiden lässt sich zwischen Hardware- und
Softwarelösungen: Während Hardwareprodukte meist leistungsstärker, aber auch kostspieliger sind,
überraschen Softwarelösungen durch ihre Flexibilität. Auch eine Platzierung von Agenten direkt in
Endgeräten ist dank immer leistungsstärkerer Prozessoren möglich.
SNMP/RMON
Das bereits seit den 80er-Jahren genutzte Protokoll SNMP zählt bis heute zu den klassischen
Hilfsmitteln, wenn es um das Management und die Diagnostik in Netzwerken geht. Der unbestreitbare
Nutzen als "Transportmittel" für Status-, Statistik- und Analysedaten machen SNMP und seine Ableger
bis heute zu einem der wichtigsten Werkzeuge im Kampf gegen Fehler. Allerdings wird SNMP leider oft
bezüglich seiner Möglichkeiten zur Fehlererkennung und -behandlung überschätzt. Zugleich
unterschätzen die Anwender die mit einem umfassenden Monitoring etwa aller Netzwerk-Ports
entstehenden Volumendaten. Die Analyseerweiterung von SNMP, RMON (I und II), kommt trotz ihres
hohen Bekanntheitsgrads bis heute in der Praxis selten zum Einsatz – unter anderem deshalb, weil
sie erheblichen Management-Overhead produziert. So ist ein flächendeckender Einsatz von
RMON-Systemen heute eher die Ausnahme denn die Regel. Auch der Versuch, mit zentralen
RMON-Sammlungen innerhalb von Switching-Backplanes (bekannt als SMON) eine breite Masse von
Anwendern zu erreichen, schlug aufgrund proprietärer Ansätze sowie aus Kostenaspekten weitgehend
fehl.
Hardware- oder softwarebasierende Lösungen
Ob zur Analyse dedizierte Hardwaresysteme erforderlich sind oder Softwarelösungen auf normalen
Rechnersystemen ebenfalls geeignet sind, ist eine altbekannte Streitfrage. Grundsätzlich gilt, dass
ein dediziertes System sich auf seine Hauptaufgabe konzentrieren und diese daher effektiver
verrichten kann als ein "nebenbei" laufender Prozess auf einem Server oder Switch. Eine Reihe von
Überlegungen hilft bei der Suche nach der individuell richtigen Antwort:
An welchen Punkten soll gemessen werden, welche Spitzenwerte sind an diesen
Punkten zu erwarten? Beispiele: Der LAN-Port einer Internetverbindung von 2 MBit/s dürfte zwar
überschaubare Netzwerklasten generieren, aber durch die Fülle von Sessions (TCP-Connects) die
Arbeitslast der Probe erhöhen. Serverports tendieren zu "Peak-Lasten", und bei Gigabit Ethernet
sind "100 Prozent Capture-Rate" mit Software-Probes nur schwer erreichbar.
Sind eher statistische Betrachtungen der gemessenen Verbindungen von Interesse
oder sollen massive Datenströme "Bit für Bit" kontrolliert werden? Beispiele: Ermittlung
langfristiger Netzwerktrends im Gegensatz zu einer "Accounting-Abrechnung" nach Volumennutzung der
Netzwerke.
Welche Budgets sind für die Anschaffung von Werkzeugen vorgesehen oder
möglich? Es geht auch kostenlos, jedoch sind kommerzielle Produkte zumeist in Funktionalität und
Leistungsstärke den Freeware-Kollegen überlegen. Auch Garantieansprüche, das Angebot eines
geeigneten Trainings sowie eventuelle "Corporate Rules", die die Nutzung freier Software in diesem
Bereich verbieten, können für die Auswahl entscheidend sein.
Soll die vorgesehene Lösung mobil einsetzbar oder ortsfest installiert
sein?
Wie viele Messpunkte müssen – eventuell gleichzeitig – in die Überwachung
einbezogen werden?
Fazit
Ein klassisches Managementsystem allein kann den Bedarf an einem Analyse- beziehungsweise
Expertensystem nicht abdecken. Netzwerkanalyse ist meist eine Aufgabe für Experten, die ein
tief(er) gehendes Verständnis der OSI-Schichten, der Datenquellen und der verwendeten Protokolle
voraussetzt. Als Empfehlung kann heute gelten, traditionelle Verfahren nicht zwingend in Frage zu
stellen, jedoch einen für die individuelle Situation geschärften Blick zu entwickeln und auf die
Kombination von Produkten zurückzugreifen, die in der Summe einen optimalen Effekt, nämlich hohe
Verfügbarkeit und gute Performance, gewährleisten. Ferner gilt, dass gute Lösungen nicht zwingend
unerschwinglich sein müssen, andererseits kann "umsonst" letztlich auch sehr kostspielig werden.
Wichtig ist mehr denn je die Administrierbarkeit der Werkzeuge und die Erkenntnis, im Zweifelsfall
besser einen Analyseexperten zu Rate zu ziehen, als sich mit Werkzeugen auszurüsten, für deren
probate Anwendung unter Umständen die personelle Kapazität fehlt.
Lesen Sie mehr zum Thema
