VoIP mit MRTG/Nagios/PRTG

Kann man mit MRTG, Nagios, Cacti und anderen Tools, die die Bandbreite von Interfaces auslesen überhaupt Netzwerk hinsichtlich VoIP sinnvoll überwachten?. Meiner Ansicht nach geht es nur bedingt. Wenn schon die schönen Grafiken dieser Überwachungswerkzeuge eine deutlich überlastet Leitung zeigen, dann wird man mit VoIP vermutlich Probleme bekommen aber nur weil die Bilder eine geringe Auslastung zeigen, reicht mir das nicht für einen VoIP-Readyness Test.

Hinweis: Diese Seite erklärt nicht, wie es gemacht wird, sondern beschreibt, warum die Art des Monitoring per SNMP gerade nicht dazu geeignet ist, die VoIP-Tauglichkeit eines Link bei der Planung und im Betrieb zu überprüfen.

Netzwerklast ohne VoIP

Fangen wir bei dem klassischen Ethernet an, wie es in den meisten Firmen installiert ist. Es besteht heute in der Regel aus einer mehr oder weniger verbreitete Ethernet-Struktur mit Switches, die eventuell am gleichen Standort noch kaskadiert sind. teilweise wird es VLANs geben, die über Router oder Firewalls gefiltert sind. Da hier meist Gigabit oder zumindest 100 Megabit im Einsatz ist und Bandbreite selten ein Thema ist, sind hier Fehler selten aber auch möglich. Ein Sonderfall sind die ebenfalls vorhandenen WiFi-Netzwerke, auf die ich hier nicht explizit weiter eingehe.

Interessante sind hier Niederlassungen, die per VPN, MPLS oder andere Techniken angebunden sind. Hier ist verfügbare Bandbreite ebenso ein Thema wie die Laufzeit bei weit entfernten Standorten. Abe das wäre alles noch handhabbar, wenn VoIP alleine diese Leitungen nutzen dürfte. Aber in der Regel ist Lync eher der Nachzügler. Interessant ist nun erst mal, wie so Verbindungen genutzt werden. Das klassische PC-Netzwerk und WAN-Netzwerk überträgt Daten eher "Stoßweise", z.B.:

  • Arbeiten mit Dokumenten (Dateiserver, Sharepoint)
    Der klassische Office-Mitarbeiter nutzt Word, Excel, Powerpoint um Dokumente zu erstellen und zu ändern. Er startet das Programm ohne Netzwerkbelastung lokal und überträgt dann in kürzester Zeit die große Datei. Danach ist wieder "Ruhe". Ein Sonderfall stellen Replikationen von Inhalten dar, z.B. Branch-Cache, Windows "Aktenkoffer" etc., die über Minuten eine höhere Last erzeugen.
  • Webseiten
    Ein ähnliches Verhalten stellt das "Surfen" im Internet dar. Die meisten Anwender laden eine Seite und während der Inhalt gelesen wird, werden keine Daten mehr übertragen. Das stimmt so aber nicht ganz, da viele Seiten dynamisch Inhalte nachladen Auf der anderen Seite gibt es Proxy-Server mit Caches, die das Netzwerk entlasten können. Inhalte werden meist nur gelesen. Darunter fallen z.B.: auch Updates von Antivirenpattern.
  • Softwareverteilung
    Werden Programme auf den Client installiert, dann sind dies oft größere Datenpakete. Sie können aber z.B.: Nachts auf einen lokalen Verteilpunkt übertragen werden, so dass diese Datenmenge außerhalb der Arbeitszeit übertragen wird.
  • Ausdruck
    Und am Ende steht sehr oft der "Druck" auf Papier. Auch dies sind in der Regel kurze große Datenmengen. Allerdings drucken Anwender natürlich "lokal", so dass dies für eine WAN-Verbindung kaum Auswirkungen hat. Eine Ausnahme sind natürlich RDP-Verbindungen und Hostdruck.

Die Benutzung sieht also eher aus wie eine Durchgangsstraße bei Nachts, beidem ab und an ein paar langsame LKWs und Transporter die Straße "belegen".

Natürlich gibt es auch aber heute schon die ein oder andere regelmäßige Übertragen von Datenmengen, z.B.

  • RIP/OSPF-Updates
    Die Router melden untereinander Veränderungen von Leitwegen. Diese Pakete sind wichtig aber im LAN eher selten. Viele Firmen arbeiten sogar komplett mit statischen Routen, was Speziell in Hub/Spoke-Topologien einfach nutzbar ist.
  • AD-Replikation/DNS Replikation
    Jede Änderung an AD-Objekten, und da passiert schon regelmäßig, muss auf alle anderen DCs übertragen werden. Mit AD-integrierten DNS-Zonen werden es noch etwas mehr Daten, die übertragen werden
  • SNMP-Abfragen
    Auch die Anfrage von Verkehrsdaten verursacht natürlich Pakete.
  • YouTube, Internet Radio und andere Medienangebote
    Diese Datenmengen dürften, sofern sie "erlaubt" sind, auch mehr Volumen mit sich bringen.

Mal abgesehen von "Video schauen" sind die Datenmengen aber ziemlich klein. Bezogen auf das Bild einer Straße sind das dann vielleicht ein paar kleinere Autos und Krafträder, die zwischen den wenigen LKWs sich durchmogeln. Aber alles noch nicht kritisch.

MRTG-Prinzip

MRTG und viele andere Programme müssen und visualisieren die Netzwerkauslastung, indem Sie regelmäßig (z.B. alle 5 Min) per SNMP den Router abfragen. Sie erfragen die Anzahl der übertragenen Bytes. Router zählen diesen Wert in der Regel einfach hoch (seit Einschaltzeitpunkt) und die Software merkt sich einfach den vorherigen Stand und und die Differenz. Um langfristige Trends zu sehen, werden ältere Daten zusammen gefasst MRTG speichert per Default folgende Intervalle mit ab um darauf dann auch vier Grafiken zu erstellen.

Grafiktyp Intervall Messwerte

Tag

5 Min

288

Woche

30 Min

336

Monat

2 Stunden

360

Jahr

1 Day

365

Um die Funktion zu erklären, nutze ich als Beispiel den Meeresspiegel mit Ebbe und Flut, der ja auch eine numerische Größe darstellt. Übrigens hat wirklich mal jemand an einem Peer per Sensor den Wasserstand gemessen und per MRTG visualisiert (http://www.willy.com/Scripps/data/Tide/tide.html (Seite ist leider mittlerweile offline auf auf http://web.archive.org/web/*/http://www.willy.com/Scripps/data/Tide/tide.html noch zu sehen). Das Beispiel ist aber dennoch sehr gut, da die Diagramme folgendes visualisierten:

  • Tagesdiagramm
    Sie sehen hier schön, dass es jeden Tag zweimal Ebbe und zweimal Flut gibt. vielleicht sieht man auch mal einen "Spike". Es kann ja sein, dass im Moment der Messung vielleicht ein Hindernis (Möve, Treibholz) die Aufnahme verfälscht hat. Das passiert, wenn absolute Werte gemessen werden. Bei der Messung von Netzwerken werden aber meist Differenzen errechnet, d.h. der Router liefert die "Summe" und die Software muss diese vom vorherigen Wert abziehen. Dann gibt es keine Spikes.

    Quelle: http://web.archive.org/web/20010224083352/http://www.willy.com/Scripps/data/Tide/tide.html
  • Wochendiagramm
    Die Anzeige von 14 mal Flut und Ebbe hat erst mal keinen besonderen Zusatznutzen, außer vielleicht Messfehler wie ein "hängender Schwimmer" zu erkennen

    Quelle: http://web.archive.org/web/20010224083352/http://www.willy.com/Scripps/data/Tide/tide.html
  • Monatsdiagramm
    Es ist offensichtlich, dass nun 30x2 Amplituden sichtbar werden. Aber wenn Sie sich die Hüllkurve anschauen, dann können sie den Einfluss des Mond sehen, d.h. Springflut und Nippflut.

    Quelle: http://web.archive.org/web/20010224083352/http://www.willy.com/Scripps/data/Tide/tide.html
    Ein gutes Beispiel, wie auch ein mittelfristiges Monitoring nützliche Informationen liefert. Viel wichtiger für die spätere VoIP-Betrachtung ist aber, dass der Spike durch die Mittelwertbildung ausgebügelt wurde.
  • Jahresübersicht
    Hier ist dann aufgrund der Auflösung und der Mittelwertbildung nur noch "Rauschen".

    Quelle: http://web.archive.org/web/20010224083352/http://www.willy.com/Scripps/data/Tide/tide.html
    Vielleicht könnte man bei einer Jahrhundert-Aufzeichnung den Anstieg der Meeresspiegel sehen, aber das hilft uns nicht weiter. Beim Netzwerkmonitoring ist diese Grafik natürlich interessant

Soweit ist das MRTG-Prinzip sehr gut verständlich.

Eine typische WAN-Leitung

SNMP-Auswertungen sind sehr dazu geeignet die durchschnittliche Belastung von Leitungen anzuzeigen aber es ist die Aufgabe eines QoS-Konzepts, eventuell störende Spitzen so durch Beschränkungen glatt zu bügeln, dass ausreichend während eines Gesprächs kontinuierlich ausreichend Luft für VoIP bleibt.

Die Überprüfung von Netzwerken bezüglich der VoIP Leistung ist nicht wirklich einfach, auch wenn ihnen verschiedene Netzwerkanalysetools das immer wieder versprechen. Das Skript End2EndVOIP sollten Sie aber auch nicht als ultimative Lösung aller Diagnoseprobleme verstehen, sondern auch nur als einen weiteren Baustein in der Werkzeugkisten zur Fehlersuche und Problemeinkreisung.

Lösen Sie sich von der Vorstellung, dass eine Überwachung einer WAN-Leitung per SNMP mit Programmen wie Nagios, MRTG, PRTG, o.ä. erfolgen kann. Diese Programme lesen alle die übertragene Datenmenge oder Anzahl der Paket aus und bauen darauf schöne Bilder. Meist ist die Auflösung aber minimal 5 Minuten. Sie sehen also immer nur einen Mittelwert über 5 Minuten. Das sagt nichts über Engpässe im Sekundenbereich und damit über die VoIP-Tauglichkeit aus.

Sie glauben mir nicht? Hier sehen Sie eine IST-Aufnahme einer WAN-Verbindung im 5 Sekunden Raster. Sie sehen, dass die Bandbreite immer wieder "Plateaus" hoher Auslastung hat. (Bei der Leitung handelt es sich um einen 12 Megabit Link). Ich habe mal einen waagrechten Stich bei 12 Megabit manuell eingezogen.

Stellen Sie sich nun mal vor, eine handelsübliche Software nimmt nun alle 5 Minuten einen Prüfpunkt auf. Dann wird Sie die Zahlen "mitteln" und wie folgt darstellen.

Das Bild sieht erst mal ähnlich aus, aber vergleichen Sie sich den Maßstab links. Es hat den Anschein, dass hier gerade mal 5 Megabit übertragen werden und damit "ganz viel Platz" auf der Leitung für VoIP ist. Eine Abschätzung vor dem Rollout wäre hier also nicht korrekt gelaufen.

Oft stellt sich die Frage nach der Überwachung und Analyse erst, wenn es die ersten Probleme gibt, z.B.: dass die Sprachqualität nicht das erwartete Niveau erreicht. Besonders perfide ist dies, wenn das Problem nur manchmal sporadisch auftritt. Auch ist nicht immer klar auszumachen, ob es nun am Client, am Netzwerkkabel, den Switches, Routern, WAN-Verbindungen o.ä. liegt. Sie können sich der Thematik durch "Messen" nähern, aber dies kann nur bis zu einer bestimmten Tiefe erfolgen.

Für VoIP hingegen müssen wir nun die Tagesansicht mit der "Realtime"-Ansicht vergleichen. Erinnern Sie sich noch an den Spike in der Tagesansicht? Wenn im Realtime-Diagramm ein Spike eine Vollauslastung anzeigt, dann wird das bei der 5-Minuten Anzeige auch "ausgebügelt". So ein Diagramm wäre bedingt hilfreich aber es macht kein Sinn die Daten per SNMP alle 20ms abzufragen.

Genau das ist aber das Problem der klassischen Netzwerküberwachung. Sie glauben die Verbindung wäre nicht ausgelastet und es wäre noch genug "Platz" aber sie können gar nicht sehen, wie oft die kritische Grenze überschritten wird. Hinzu kommt, dass mit zunehmender Last auch die Pakete länger warten müssen, was sich direkt auf die Latenzzeit und Jitter auswirkt.

Was wir wirklich müssen sollten

Nun haben wir genug über das einfache SNMP-Monitoring gelästert. Es war aber wichtig für das Verständnis der Thematik. für die Qualitätssicherung von VoIP sind also andere Faktoren und Messwerte relevant als die reine "Auslastung" einer Leitung. Wenn Sie nun überlegen, wie MRTG und andere Programme die Schnittstellen überwachen, dann können Sie ermessen, dass sie gar nicht geeignet sein können.

Viele Programme und Administratoren orientieren sich dabei an einem MOS-Wert zwischen 0 und 5, der die Qualität der Sprache wiedergeben soll. Wobei es schon suspekt ist, wenn Analysetools diesen Wert mit mehr als einer Nachkommastelle angeben. Der normale Durchschnittsbürger wird schon Probleme haben, eine Abstufung zwischen einem MOS von 3 bis 4 zu unterscheiden, wenn er keinen direkten Vergleich hat. Zumal die Qualität auch schwanken kann. Daher ziehen die meisten Programme zwei andere Kriterien heran.

  • Jitter (<30ms)
    Dieser Wert bezeichnet die Abweichung des Zeitpunkts. Wenn per RTP z.B. alle 20ms ein Paket gesendet wird und beim Empfänger ankommen soll, dann ist es eher normal, dass die Laufzeit der Pakete nicht gleich ist und daher beim Empfänger die Pakete mal früher und mal später ankommen. Daher puffern die meisten VoIP Clients auch etwas die Pakete, d.h. die Töne werden auch erst verzögert wieder gegeben, damit der Buffer nicht leer läuft. Bleiben Pakete aber zu lange aus, dann gibt es eben doch einen "Aussetzer". Tückisch sind solche Dinge auch, wenn ein Paket unterschiedliche Wege nimmt oder ein Switch die Pakete puffert (überlast) und dann bei freier Leitung als Pulk wieder los sendet. Dann folgen Pakete schnell aufeinander.
    Lync hat einen kleinen "Puffer" um die eingehenden Pakete etwas aufzuhalten und damit unterschiedliche Laufzeiten von Paketen auszugleichen. Damit die Verzögerung in der Sprache nicht zu lange wird, versuchen alle Produkte den Jitter-Buffer klein zu halten. Lync passt ihn sogar den aktuellen Gegebenheiten an.
  • Loss (<10%) und Burst
    Das zweite Paradebeispiel ist der Paketverlust, der auch in voll geswitchten Netzwerken passieren kann, z.B. durch Überlastung von Switches, der dann Pakete verwirft. Der Verlust von Paketen führt bei VoIP natürlich zu fehlenden Audiostücken. Zum Glück ist der Mensch hier tolerant und "überhört" einzelne fehlende Stücke. zudem machen die Codecs einige wett, indem sie z.B. FEC einsetzen um Pakete wieder herzustellen. Da Audio aber idealerweise "Realtime" über UDP ist, werden die Daten natürlich nicht mehr erneut angefordert. Störend sind aber "Gruppen" von Verlusten, also ein Burst
  • Laufzeit/Delay - Latency (100ms OneWay, 200ms Roundtrip)
    Relevant ist natürlich auch, wie lange die Pakete vom Absender zum Ziel unterwegs sind. Wenn ein Paket länger als 100ms (OneWay) oder 200ms (Roundtrip) unterwegs ist, dann wird das Telefonieren schon unangenehm. Wenn Teilnehmer 1 aufhört zu sprechen, dann erwartet er auch eine zeitnahe Antwort. Je länger diese Laufzeit ist, desto eher kommt es zu "Gegensprechen". Sowas war früher bei Telefonaten in die USA über Satellit noch üblich aber auch beim Internet sind Laufzeiten kritisch, da jeder Router das Paket erst komplett empfangen, den nächsten Hop ermitteln und dann über die Sendewarteschlange einreihen muss. Das können Sie hier schön sehen, wie die WAN-Verbindungen über den Teich die 100ms addieren:


Quelle: http://www.whichvoip.com/voip/speed_test/ppspeed.html

  • Bandbreite
    Die Brutto-Bandbreite ist in der Regel nicht interessant. Natürlich hat eine höhere Bandbreite nicht nur mehr Reserven sondern überträgt die Daten vor allem schneller. Der Begriff "Breite" ist hier falsch, da die Schrittgeschwindigkeit höher ist und damit mehr Bits/Sekunde übertragen werden können. Die "Datenstraße" erlaubt also höhere Geschwindigkeiten und nicht etwas mehr parallele Fahrspuren. Es muss eben "genug" Bandbreite für VoIP übrig sein, was auch mit Priorisierung und QoS zu tun hat. Zuwenig Bandbreite zeigt sich aber schon allein m Jitter, Paketloss und Laufzeit.

Dass Pakets auch mal "Out of Sequence" oder gestaucht ankommen können, wird dabei meist übersehen. Auch wenn diese beiden Parameter wichtig sind, so sind sie nicht ausschließlich für ein Monitoring hinreichend. Das scheitert schon daran, dass die Überwachung dieser Parameter nicht einfach ist. Der Lync Communicator sammelt solche Wert und übermittelt diese am Ende der Verbindung über den Frontend an den Monitoring-Server, so dass hier eine Auswertung möglich ist. Aber dennoch bleiben die ein oder anderen Dinge unentdeckt und in einer Vorermittlung haben Sie diese Daten ja noch nicht.

Sinnvolle Messung

Um die drei genannten Werte zu ermitteln gibt es verschiedene Möglichkeiten und Szenarien.

  • Passives Packet-Monitoring
    Wenn sie schon bereits VoIP etabliert haben und die VoIP Lösung keine geeigneten Daten berichtet, dann bleibt nur, dass Sie die RTP-Pakete möglichst automatisch mitschneiden und auswerten. Natürlich müssen Sie dann auch Werkzeuge haben, um die ganzen CAP-Dateien zu analysieren und sie müssen warten, bis der Fehler wirklich auch auftritt.
  • Client-Reporting
    Wenn VoIP schon genutzt wird, dann sehen natürlich die Endpunkte einer Audio/Video-Verbindung sehr genau die eingehenden Daten und können alle drei Faktoren (Latenz, Jitter, Loss) ermitteln. Lync Client senden am Ende eines Gesprächs umfangreiche statistische Daten an den Lync Monitoring Server und erlauben dem Administrator zumindest anschließend eine Auswertung eines individuellen Gesprächs oder der Umgebung. Aber selbst hier sind die Daten natürlich zusammengefasst. Nicht jeder einzelne Burst wird verzeichnet, sondern nur der längste Burst und wie viele Burst erkannt wurden. Auch beim Jitter gibt es nur einen zusammenfassenden Wert.
  • Aktive Proben
    Wenn es noch keine VoIP Umgebung gibt oder sie eigene Prüfungen machen wollen, dann müssen Sie idealerweise synthetische RTP-Daten generieren. Ersatzweise könnte man versucht sein, einfach UDP-Pakete zu senden und mit einem Empfänger einzusammeln. Eine solche Kombination aus Sender und Empfänger kann dann natürlich auch Last generieren und damit eine Leitung mit der später erwarteten Last belegen. So könnten sogar die Netzwerker ihr QoS-Einstellungen überprüfen und anpassen. Und bei einem Fehler ist dieser Last schnell wieder weg. Später können Sie den Mitarbeitern schwerlich das Telefonieren verbieten.

Aber auch hier gilt immer wieder, dass ihr Messgerät nur nackte Daten ausspuckt. Die Einstellungen und Interpretation der Daten obliegt ihnen oder dem qualifizierten Dienstleiste.

Wireshark/Netmon

Über Netzwerkmitschnitte können Sie relative gut die RTP-Datenströme überwachen und anschauen. Aber kaum jemand wird nun einen Mitschnitt über viele Stunden oder gar Tage mit diesen Programmen auswerten. Schon das Ermitteln der unterschiedlichen Eintreffabstände von Paketen am Ziel ist eine Herkulesaufgabe, die ohne Assistenten nicht mehr sinnvoll durchführbar ist. Eine Verknüpfung mit anderen Mitschnitten an anderen Stellen ist noch kniffliger. Aber genau das ist z.B.: beim Suchen nach Ursachen erforderlich. Netmon und Wireshark helfen aber natürlich bei der Analyse, warum eine bestimmte Verbindung nicht zustande kommt. Aber das sind auch die einfacheren Probleme. Die Analyse von Netzwerkproblemen kann also eine ganz andere Ebene erreichen, die mit Bordmitteln oder gängigen Werkzeugen nicht mehr zu bewältigen ist. Das Problem der gängigen Werkzeuge ist einfach, dass Sie zu wenig detailliert müssen. für HTTP, FTP, SMB und selbst LDAP sind Paketverluste und Jitter oder auch ein Aussetzer von wenigen Sekunden kein Problem, da TCP auch Retransmitts durchführt. Bei VoIP hören Sie schon, wenn die Daten nur einen Teil einer Sekunden Ausbleiben. Das können Sie aber üblicherweise nicht über "Volumen"-Counter" müssen. Je nach Schwere kann es also erforderlich werden, Spezialisten mit passiven Probes, Lastgeneratoren und viel Erfahrung mit ins Boot zu holen.

Ergebnis

Allein durch das passive Ablesen von SNMP-Countern auf Netzwerkschnittstellen, das zählen der Pakete und die Differenzrechnung der Übertragenen Byte liefert einen ersten Blick auf die Netzwerklast einer Teilstrecke. Durch die grobe Auflösung von 5 Minuten sind solche Messungen für VoIP Aber nicht geeignet. Hier müssen andere "aktive" Tests ergänzen, die entweder eine definierte und aktiv gemessene Grundlast auf die Leitung bringen oder die Router selbst "wissen" um die Besonderheiten von VoIP und erfassen zusätzlich solche Informationen.

Bis dahin muss ich all den Administratoren leider sagen, dass ich auf Basis von einfachen MRTG-Style Diagrammen keine Aussage zur VoIP auf ihrem LAN oder WAN machen kann.

Weitere Links