PRTG Bandbreite

Netzwerke zu überwachen ist durchaus eine anspruchsvolle Aufgabe. Viele Firmen nutzen einfach SNMP um passiv z.B. einen Port zu überwachen und übersehen dabei, dass diese Momentaufnahmen in 5-Minuten Abständen nur eingeschränkt über die Auslastung und Qualität eine Aussage erlauben. So wird weder die maximal vorhandene Bandbreite noch die kurzfristige Auslastung überwacht.

Achtung
Setzen Sie diesen Sensor mit Bedacht ein. Er eignet sich nur für unkritische Leitungen, die zum Messzeitpunkt unbelastet sind oder deren vorhandene Last durch die Messung nicht gestört wird und die Messung nicht zu stark verfälscht, also z.B. der klassische Anschluss "zuhause". Auf aktiven Verbindungen sollten Sie nur mit Einsatz von QoS eine Volllast anlegen, bei denen ihre Demodaten die niedrigste QoS-Klasse haben und dann den aktuellen Durchsatz vom Router erfragen.

PRTG - Bandwidth Monitoring with SNMP and WMI
http://www.paessler.com/support/videos/prtg-basics/bandwidth-monitoring-basic 
Bandbreiten-Monitoring via Flows und Packet Sniffing
http://www.paessler.com/support/videos/prtg-advanced/bandwidth-monitoring-advanced

Bandbreite und Latenz

Wenn man aber nicht nur passiv die aktuelle Auslastung überwachen will, muss man selbst Last generieren. PRTG hast dazu gleich mehrere Sensoren. Neben dem PRTG:QoS Sensor, der nur wenige Pakete sendet aber deren Laufzeit genauer aufzeichnet, gibt es auch eine Möglichkeit, die verfügbare Bandbreite zumindest für HTTP zu ermitteln. Die Funktion verbirgt sich hinter dem "HTTP Advanced" Sensor.

Die Konfiguration erfolgt dann auf der zweiten Seite. Maßgeblich ist hier die HTTP-URL, von der PRTG eine Testdatei herunterladen kann.

Sie sollten sich dazu eine Datei oder einen Server in der "Nähe" der zu testenden Strecke suchen, wenn Sie den ersten Teil der Verbindung testen wollen. Idealerweise also eine Datei auf einem Webserver ihres Zugangsproviders. Vielleicht stellt er ja eine größere Datei (z.B. Firmware, Tools o.ä.) bereit. So habe ich bei der Telekom direkt auf der Homepage www.t-online.de einen Link auf deren Speedtest (http://speedtest.t-online.de) gefunden. Der ist nun natürlich "browserbasiert" und mit Fiddler kann man zwar den Reuest sehen aber keine weiteren Daten. Aber WireShark zeigt, dass er wohl vier parallele Verbindungen öffnet und per HTTP dann Dateien herunter lädt.

Schaut man sich einen Stream genauer an, dann ist dies ein HTTP-GET, der eine Datei mit 254MB laden würde. Auch die Messung der "Ping"-Zeit ist in Wirklichkeit ein HTTP-GET mit 0 Byte

Allerdings lädt diese Datei nicht der Browser direkt, sondern das Skript und misst die Performance. Diese "Datei" können Sie aber auch manuell herunter laden. Im Feb 2015 war der Link:

Die ist eine knapp 2,3GB große Datei, die aber anscheinend nicht im eigenen Netz der Telekom steht, sondern über Level3 angebunden ist.

Interessant in dem Zuge: Der Speedtest sendet auch per POST am Ende das Ergebnis zurück.

Und all das per HTTP unverschlüsselt. Was die Telekom wohl mit diesen Daten anstellt ?

Die richtige Gegenstelle

Sie müssen aber nicht die "Test-Dateien" der Telekom nutzen, wenn Sie einen DSL-Anschluss der Telekom haben. Der Download einer schnellen "nahen" Seite hilft ihnen zwar die Leistung ihres Anschlusses zu ermitteln, aber das hilft ihnen dennoch nicht weiter, wenn die von ihnen gewünschte Ziele dann doch nicht schnell zu erreichen sind, weil woanders ein Engpass ist.

Für die Messung der mit einer bestimmten Gegenstelle sollten die Gegenstelle "Reserven" haben und die Daten zumindest schnell genug senden. Erst wenn die Gegenstelle als "Engpass" auszuschließen ist, können die Daten ihre eigene Verbindung halbwegs passend wieder geben. Sie werden mit solchen Tests in der Regel keine Peering-Punkte müssen können. Dazu gibt es zu viele Variablen, von denen Sie nichts wissen. Also beschränken wir uns doch besser auf ein System, dass schnell genug und nahe genug an ihrem Prüfsystem steht.

Fragen Sie einfach ihren Zugangsprovider nach einer schnellen Adressen.

DSL 16000 mit 9-11 Megabit (Hövelhof)

Ich selbst wohne in Hövelhof und leider ist LTE hier keine echte Option (Stand Feb 2015) und auch wenn es im Ortskern Internet über Kabel gibt, so wurde das Neubaugebiet nicht "verkabelt". So kommt es also heute immer noch vor, das in einem Neubaugebiet mit ca. 100 Familien gerade mal DSL 16.000 möglich ist, von denen aufgrund der Entfernung bei mir um die 10 Megabit ankommen.

Hier habe ich dann einige Zeit einen Sensor laufen lassen, der alle 15 Minuten eine kleine 10 Megabyte-Datei von Cachefly (einem Content Delivery Network) herunter geladen hat. Man kann bei dieser Ansicht über 2 Tage gut erkennen, dass immer um die Abendzeit herum die Leistung einbricht.

aus den knapp 10 Megabit werden dann teilweise sogar weniger also 4 Megabit. Das reicht für VoIP in der Regel immer noch aus, wenn es sich um den Downstream handelt. Leider habe ich aktuell keine Messung für einen "Upstream". Dazu müsste ich ebenfalls eine vergleichbare Datei auf einen Server hochladen.

Interessant werden die Zahlen über einen längeren Zeitraum. Hier sieht man gut meine Probleme nach dem Update meiner Fritz!Box von 6.20 auf 6.23. Die Stabilität des DSL-Anschlusses war nicht mehr gegeben und ich habe mit den DSL-Stabilitätseinstellungen gespielt und die Fehlerraten betrachtet. Erst nachdem ich die Firmware 6.23 auf "max. Stabilität" gestellt habe, hat sich DSL bei nur noch 7,5 MBit eingestellt aber war stabil. Am 24.2 habe ich dann die Checkbox aktiviert, dass die Fritz!box die vorherige DSL-Firmware nutzen soll. Und dann war wieder mit knapp 10 MBit eine stabile Verbindung möglich

Das sind aber nun eher die Probleme an einem Privatanschluss. Aber sie zeigen gut die Vorteiler eine aktiven Bandbreitenüberwachung. Beim Firmenanschluss sollten Sie es sich aber verkneifen, einige Sekunden die komplette Bandbreite aufzubrauchen. Hier ist es sicher besser, die ungenutzte Bandbreite mit einem Prozess zu belegen, der per QoS niedrig priorisiert ist und dann parallel die aktuell belegte Bandbreite z.B. per SNMP zu lesen.

Unity Media in Elsen

Ein Arbeitskollege hat deutlich bessere Voraussetzungen an seinem Wohnort in Elsen. Hier kann er über 100MBit per Kabel (Unity Media) verfügen. Die Messwerte sind aber auch hier interessant.


Quelle: Net at Work, Mitarbeiteranschluss mit simulierter Last und anzeige der real erhaltenen Bandbreite.
https://prtg.geneberg.net/public/mapshow.htm?id=4980&mapid=886A5866-C106-41BC-AAEA-12C1BCF90149

Die 100MBit werden verdammt oft erreicht aber auch hier ist am Abend ein ganz anderes Bild zu sehen. Anscheinend nutzen am Abend viele Personen intensiv das Internet und vermutlich auch zum Streaming (NetFlix, YouTube u.a.) so dass hier wohl im Backend ein Engpass die erreichbare Leistung deutlich reduziert. Auch hier ist dies nur der "Downstream". Aussagen zum Upstream habe ich nicht.

Für Firmen und kommerziell genutzte Anschlüsse zeigt sich einmal mehr, welches Risiko der Einsatz von VPNs zur Firma oder von Cloud-Diensten darstellen kann, wenn die Bandbreiten nicht wie erwartet zur Verfügung stehen. Noch wichtiger ist aber, dass Sie solche Daten überhaupt erst mal erheben, um bei Problemen entsprechende Daten zum Vergleich zu haben.

Das Landgericht Fürth hat am 7.5.2009 (Az.: 340 C 3088/08) wohl geurteilt, dass man einen Anschluss fristlos kündigen kann, wenn er weniger als 50% der versprochenen Leistung liefert. Das hilft aber nicht wirklich weiter, wenn es keinen Wettbewerber gibt, der eine alternative Anbindung bieten kann. Solange die Gegenstellen in den gleichen Vermittlungen und Kästen stehen, was Sie aufgrund der Kupferkabel auch müssen, oder die Wettbewerber nur Reseller der Telekom sind, wird sich hier nichts ändern.

Daran wird sich wohl nur dann was ändern, wenn man die Rechnungshöhe an die real gelieferte Bandbreite anpassen würde., dann wäre es vielleicht auch für die Kupferkabel-Inhaber wieder lohnend auch DSL16000-Gebiete auf DSL50000 anzuheben.

DSL100 Hövelhof

Seit 2016 habe ich auch DSL100 in Hövelhof und auch die Fritz!Box ist ziemlich optimistisch, das die Bandbreite auf dem Kabel verspricht:

Nun muss man aber wissen, das natürlich nur der erste Link ist und nichts über das Backend des Carriers aussagen. Da bietet sich natürlich PRTG an, eine entsprechende Gegenstelle zu proben.

Natürlich muss man wissen, dass die Gegenseite selbst als auch das Peering einen Einfluss auf solche Messungen hat und die Werte daher mit Vorsicht zu bewerten sind. Nicht immer ist der Carrier schuld.

Mit dem PRTG-HTTP Advanced Sensor habe ich eine 10 MB Datei von CacheFly alle Minute geladen. Das sind also 432GB/Monat. Das wollte ich nicht dauerhaft machen aber schon einige Tagen bringen interessante Werte:

Auf den Ersten Blick habe ich über sehr lange Zeiten 90 Megabit/Sek und mehr aber in den Abendstunden sackt der Durchsatz auf unter 20 Megabit/Sek ab. Das wiederholt sich jeden Abend mehr oder weniger stark. Sogar der stärkere Einbruch am Samstagen ist zu sehen.

 

Die richtige Gegenstelle

Die Werte sind aber mit Vorsicht zu behandeln, denn es muss nicht mein Provider sein. In dem Fall könnte ja auch der Weg und das Peering zu CacheFly irgendwo eng sein oder die Gegenstelle einfach viel zu tun haben. Hier sehen Sie z.B.: den gleichen Server, der zwei unterschiedliche Gegenstellen im Internet abfragt. Sie sehen den krassen Unterschied:

Während bei "tele2" dauerhaft das Internet ca. 90 Megabit liefert ist der Durchsatz bei Cachefly deutlich verändert. Wobei ich hier nun nicht erkennen kann, ob der Weg dorthin schlecht oder der Server selbst überlastet ist. Es könnte sogar passieren, dass die beiden Tests gleichzeitig laufen und dann jeder nur ca. 50 Megabit anzeigen würde.

Die beiden Messbilder zeigen sehr gut die Grenzen einer einfachen Bandbreiten-Messung. Die funktioniert gut, wenn Sie z.B. eine einzelne Verbindung messen wollen aber sie taugt nur bedingt für längere Strecken. Also ist es an der Zeit, einen eigenen Sensor End2End-NetPath zu planen. 

Die reine Download-Performance einer Leitung ist gar nicht das wichtigste Kriterium. Viel wichtiger finde ich die Latenz im Netzwerk zu einem Ziel, da diese für den Durchsatz maßgeblich ist. Wenn die Leitung "überlastet" oder "zu langsam" ist, dann sieht man das auch in der höheren Latenzzeit ohne gleich die Leitung selbst mit "Volllast" zu messen.

Abgeschwächt könnte es natürlich mal interessant sein, die Latenzzeit zu messen und dann eine Belastung aufzubauen. 

Weitere Links