Test VPN-Systeme: Gemeinsam durch den Tunnel (Fortsetzung)
- Test VPN-Systeme: Gemeinsam durch den Tunnel
- Die Testreihen
- Test VPN-Systeme: Gemeinsam durch den Tunnel (Fortsetzung)
- Multidirektionale Imix-Performance
- Test VPN-Systeme: Gemeinsam durch den Tunnel (Fortsetzung)
- Bandbreitenlimitierung
- Test VPN-Systeme: Gemeinsam durch den Tunnel (Fortsetzung)
- Fazit
- Prof. Dr. Bernhard G. Stütz

Bandbreitenmanagement im Upstream
Unsere dritte Testreihe setzt sich aus drei Messungen zusammen. Im ersten Test haben wir die Limitierung der Bandbreite untersucht. Hier bauten wir ein VPN zwischen unserer Zentrale und dem Office 1 auf.
Die Datenströme sollten unidirektional von Office 1 an die Zentrale gesendet werden. Dabei sollte die Bandbreite auf 4 MBit/s begrenzt sein, da mehr Daten über unsere WAN-Verbindung nicht gesendet werden können.
Mit Ausnahme der Teststellung von Underground8 war diese Limitierung bei allen Teststellungen darstellbar. Allerdings waren die Ergebnisse bei allen Teststellungen abhängig von den verwendeten Frame-Formaten und zum Teil auch von den Eingangslasten.
Je nach willkürlich gewählter Konstellation sah die eine oder andere Teststellung besser oder schlechter aus, so dass hier keine klare Rangreihenfolge dargestellt werden kann.
Im zweiten Test unserer dritten Testreihe haben wir Strict-Priority gefordert. Es galt, vier Prioritäten unter DSCP 0x20/0x60/0xA0/0xE0 beziehungsweise optional UDP 10/20/30/40 einzurichten und grundsätzlich die Daten der niedrigen zu Gunsten der Daten der höheren Prioritäten zu verwerfen.
Die Datenströme haben wir unidirektional von Office 1 an die Zentrale gesendet. In vier Lastschritten haben wir dann mit 4, 5,33, 8 und 16 MBit/s gesendet und so eine maximal vierfache Überlast generiert, da das Office-System maximal 4 MBit/s an die große Appliance schicken konnte. Die Bandbreitenlimitierung war dabei noch eingeschaltet, sie diente als Grundlage dafür, dass die Geräte eine Priorisierung vornehmen mussten.
Genau deshalb ist eine genaue Limitierung wichtig. Die notwendigen Datenverluste sollten dann zu Lasten der jeweils niedrigsten Priorität gehen. Das bedeutet bei 25 Prozent Frame-Loss Totalverlust der niedrigsten Priorität, bei 50 Prozent Frame-Loss Verlust der beiden niedrigen Prioritäten und bei 75 Prozent Frame-Loss Verlust aller Prioritäten bis auf die höchste.