Von: Stefan Köhler
Für viele Netzwerker gilt Software zur Performance-Messung in IP-Netzen als alter Hut und wenig innovativ. Die Meinung, dass sich die wichtigsten Daten über SNMP (Simple Network Management Protocol) erfassen lassen und alternative Messverfahren viel zu kompliziert seien, ist weit verbreitet. Tatsache ist jedoch, dass sich auf diesem Gebiet in letzter Zeit eine ganze Menge getan hat.
Neben SNMP gibt es eine breite Palette an Tools und Verfahren, die sich in passive und aktive Messmethoden einteilen lassen. Bei der passiven Messung "belauscht" die jeweilige Netzkomponente die übertragenen Pakete. Dabei wird kein zusätzlicher Traffic erzeugt.
Ein großer Vorteil von passiven Messungen ist die störungsfreie Erfassung wichtiger Performance-Parameter. Bei aktiven Messungen dagegen kann der erzeugte Messverkehr die Nutzdaten erheblich beeinträchtigen. Zu beachten ist, dass auch beim passiven Monitoring oft riesige Datenmengen anfallen, sobald die Messdaten für die statistische Aufbereitung zu einer Netzwerk-Managementstation (NMS) übermittelt werden.
SNMP und RMON
Als Veteran unter den passiven Messmethoden gilt SNMP, das bereits seit Anfang der Achtzigerjahre auf dem Markt ist. Es ermöglicht das Lesen und Setzen von Variablen, die als Objekte einer Management Information Base (MIB) adressiert werden. Der große Vorteil von SNMP liegt in der breiten Unterstützung durch die Hersteller.
In normalen SNMP-Systemen werden die Daten der Agenten ständig über das Netz abgefragt. Dies hat häufig eine große Netzbelastung zur Folge. Deshalb lag es nahe, als Erweiterung die so genannten Remote Network Monitoring MIBs (RMON/RMON II) zu standardisieren. Eine richtig konfigurierte RMON-Lösung reduziert die Netzbelastung deutlich, da die Monitore statistische Daten zwischenspeichern und in Intervallen oder auf Abruf weiterleiten. (zu den Grundlagen von SNMP und RMON siehe erweiterte Online-Berichterstattung). Eine wichtige Aufgabe von RMON-Probes besteht in der vorbeugenden Diagnose. Leider lässt die Flexibilität und Handhabung in Einzelfällen noch stark zu wünschen übrig, sodass sich eine alternative Lösung namens Netflow anbietet.
Flussmessungen mit Netflow und Sflow
Flussmessungen dienen zur Ermittlung von Ende-zu-Ende-Statistiken auf Basis der Verkehrsströme. Das heißt, dass nicht jedes einzelne Paket erfasst wird, sondern lediglich der Gesamtfluss. Für die Implementierung von Quality-of-Service-Mechanismen (QoS) sind diese Informationen nahezu unerlässlich.
Das ursprünglich von Cisco Systems entwickelte Verfahren "Netflow" ermöglicht eine Verfeinerung der IP-Volumenstatistiken durch die Zuordnung zu Protokollarten sowie die Ermittlung weiterer Parameter. Das Konzept beruht darauf, dass Pakete anhand von Protokollparametern eindeutig einem Verkehrsfluss zugeordnet werden können. Zudem gibt Netflow für jeden Verkehrsstrom den Zeitpunkt von Beginn und Ende der Übertragung an.
Das erste Paket eines Verkehrsflusses wird der normalen Verarbeitung innerhalb eines Routers unterworfen. Er wertet die anzuwendenden Regeln aus und behandelt das Paket entsprechend. Die daraus gewonnene Klassifikation und die Regeln zur Weiterleitung speichert der Router in einen Cache. Alle nachfolgenden Pakete des gleichen Flusses leitet er dann direkt zum Ziel-Port und erfasst gleichzeitig die Statistikdaten (siehe Grafik rechts oben).
Der Router lässt sich so konfigurieren, dass er diese Daten per UDP an einen definierten Zielrechner oder Agenten schickt. Da keine Aggregation der Verkehrsflüsse stattfindet, können bei hoher Verkehrslast und hohen Bandbreiten große Datenmengen anfallen. Des Weiteren bietet das hierfür eingesetzte UDP-Protokoll keine Sicherheit bei der Übertragung. Im Vergleich zu RMON ist NetFlow flexibler.
Als Argument gegen Netflow-Messungen führen Netzwerkbetreuer oft den hohen Messverkehr an. Zudem wird kritisiert, dass Netflow bei hohen Link-Geschwindigkeiten von 1 GBit/s oder mehr nicht einsetzbar sei, da die Router-CPU dadurch zu stark belastet werde. Der erste Einwand kann nur bedingt gelten, da Systeme wie "Stablenet PME" von Infosim die Netflow-Daten schon an der Stelle ihres Entstehens zusammenfassen und komprimiert über das Netz schicken. Der zweite Punkt ist schwieriger zu entkräften. Dem Autor sind bislang in einem produktiven Umfeld nur Netflow-Messungen im Bereich bis 1 GBit/s bekannt. Auch Cisco hat dieses Problem erkannt und versucht es in der neuen Netflow-Version mit so genannten statistischen Messungen anzugehen.
Alternativ dazu haben mehrere Hersteller, darunter Foundry Networks und Hewlett-Packard, den Standard "Sflow" ins Leben gerufen und in RFC 3176 spezifiziert. Sflow definiert einen "Sampling"-Mechanismus, der nicht jedes Paket misst und dem jeweiligen Fluss zuordnet, sondern Stichproben nimmt, mit denen sich ähnliche Aussagen treffen lassen.
Hierfür wird zunächst ein Intervall festgelegt, zum Beispiel dass jedes tausendste Paket eine Messrate für die Messung darstellt. Dann erzeugt Sflow zufällig Zahlen um dieses Intervall herum, die als Intervallgröße dienen. Über die SNMP-Zähler lässt sich diese Interface-Statistik auslesen. Aus den Sflow-Daten kann man ähnlich wie bei der Wahlforschung gewisse Prognosen ableiten. Jedoch schleicht sich auch hier ein statistischer Fehler ein. Deshalb ist Sflow für Accounting und Abrechnungsverfahren nur bedingt geeignet.
Aktive Ping- und Applikationsmessungen
Wie bereits erwähnt, bringen aktive Messungen zusätzlichen Verkehr ins Netz. Allerdings kann der Netzverwalter bestimmen, wann die Messungen stattfinden und wie viele Daten dabei generiert werden. Um die gewünschten Messwerte zu erfassen, bietet sich oft eine Kombination aus aktiven und passiven Messungen an.
Die klassische aktive Messung ist der "Ping". Er schickt ein ICMP-Paket (Internet Control Message Protocol) an eine Zieladresse, die mit einem ICMP-Echo-Paket antwortet. Aus der Ankunftszeit des Echo-Paketes und der Zeit des versendeten Ping-Paketes lässt sich die Laufzeit abschätzen. Mit dieser Methode kommt zusätzlich der Faktor Zeit ins Spiel. Alle bisher vorgestellten Messverfahren liefern nur Zähler- oder Volumenaussagen über ein Intervall. Nachteil der Ping-Messung ist der feste Ausgangspunkt, der nur ein sternförmiges Erfassen des Netzes ermöglicht.
Um das gesamte Netz zu erfassen, sind mehrere Messstationen (Probes) nötig. Eine andere Möglichkeit ist die Remote-Ping-Messung (RPing). Hierfür konfiguriert der Netzverwalter per SNMP die Netzwerkgeräte und nutzt sie als Messstationen innerhalb des Netzes. Derzeit gibt es hierfür noch keinen fes-ten Standard, jeder Hersteller bietet spezifische Mechanismen an. Entsprechende Standards und Erweiterungen, um die TOS-Bits (Type of Service) im IP-Header zu messen und zu setzen, sind jedoch in Arbeit und erste Richtlinien bereits verabschiedet (RFC 2925).
Das Prinzip der Ping-Messung lässt sich auf Applikationsebene fortsetzen. So gibt es viele Mess-Tools, die anstelle des Ping-Paketes Applikationsanfragen abschicken und die Laufzeit beziehungsweise Abarbeitungszeit der Abfragen protokollieren.
Service Assurance Agent (SSA)
Auch bei den Applikationsmessungen gibt es den Trend, Router als Messterminal einzusetzen. Bei Cisco läuft diese Bestrebung unter dem Begriff "Service Assurance Agent" (SAA). Manchen ist der SAA vielleicht besser als "Response Time Reporter" (RTR) bekannt, aus dem der SAA hervorging. Um den Agenten nutzen zu können, sollte eine geeignete Cisco-IOS-Version (12.1 oder höher) auf dem Router installiert sein.
SAA erlaubt es dem Router, Laufzeitmessungen auf Applikationsebene durchzuführen. Werden spezifizierte Laufzeiten überschritten, kann der Router SNMP-Traps senden und die durchgeführten Messungen zwischenspeichern. Die Daten lassen sich dann per SNMP über die RTTMon MIB auslesen.
Worin liegt der Vorteil von SAA? Zum einen bietet SAA Laufzeitmessungen und bindet die meist bereits vorhandenen Messmethoden SNMP und RMON mit ein. Gegenüber alternativen Messansätzen wie der Installation von zusätzlichen Serivceüberwachungs-Prozessen auf den Servern, dedizierten Monitoring-Servern oder dem Einsatz von RMON-II-Probes ist SSA kostengünstiger sowie einfacher zu skalieren und zu verwalten. Der SAA wird mit fast jedem Cisco-Router mitgeliefert und ist damit quasi automatisch an jeder wichtigen Stelle des Netzes vorhanden. Zusätzlich nötig ist lediglich eine Software für die Auswertung.
SAA-Messungen können sowohl auf Webabfragen, DHCP- und DNS-Requests oder anderen servergestützten Applikationsabfragen basieren. Erweitern lässt sich das Ganze über TCL-Scripte auf den Routern, so- dass sich im Prinzip die Möglichkeit bietet, beliebigen Applikationsverkehr zu simulieren. Bei diesem Messverfahren kommen zumeist zwei Router zum Einsatz. Der eine Router sendet die Abfrage, der andere Router antwortet entsprechend. Die Messdaten bearbeitet und verwaltet der abfragende Router. Vereinfacht kann man sich das Ganze als Ping-Messung auf Applikationsebene vorstellen. Als weiterer Vorteil besteht die Möglichkeit, Applikationen und deren TCP- oder UDP-Verkehr mit verschiedenen IP-Klassen und Paketgrößen zu simulieren, womit sich zum Beispiel VoIP-Ströme einfach nachbilden lassen. Die für diese Messungen aussagekräftigen Größen wie Varianz oder Jitter berechnet dann der Router. SAA unterstützt eine Vielzahl von Schwellwerttypen in Form von SNMP-Traps und protokolliert auch "normale" Verbindungs- und Paketfehler bei TCP und UDP. Die SAA-History-Funktion kann n Datenpunkte erfassen, wobei sich n frei konfigurieren lässt. Aufgrund der Leistungsfähigkeit dürften SAA-Messungen künftig im Rahmen von Service Level Agreements (SLA) eine große Bedeutung erlangen.
Generell ist bei Performance-Messungen in IP-Netzen zu beachten, dass sich die besten Ergebnisse meist durch eine geschickte Kombination von passiven und aktiven Messverfahren erzielen lassen. (cl)
Zur Person
Stefan Köhler
ist Mitgründer und Vorstandsmitglied der Infosim Networking Solutions AG. Er studierte Physik und Informatik an der Uni Würzburg. Seine Spezialgebiete sind Routingver-fahren, Netzwerkoptimierung und QoS in IP-Netzen.