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.

Weitere Links