QoS funktioniert nicht korrekt bei WAN-Ethernetanschluss

[GrandDixence]

Ich habe heute QoS getestet und bin zur Ansicht gekommen, dass QoS mit LCOS v9.04.0184 (RU4) auf einem WAN-Ethernetanschluss nicht funktioniert, wie es gemäss Beschreibung im LCOS-Referenzhandbuch funktionieren sollte. Vielleicht kann da jemand weiterhelfen?

Ausgangslage: Internetanschluss über EuroDOCSIS-Kabelmodem mit 50 MBit/s Downstream und 5 MBit/s Upstream. Am Kabelmodem ist ein LANCOM 1781EF+ als Firewall für das Heimnetzwerk über Glasfaser-Gigabit-Ethernet angeschlossen. Das Heimnetzwerk ist mit Kupfer-Gigabit-Ethernet verdrahtet.

Der Kabelmodemanschluss ist als DSL-1 konfiguriert. Bei DSL-1 wurde die Übertragungsrate in Upstream-Richtung mit verschiedenen Werten gedämpft (Upstream 2000 KBit/s bis 5200 KBit/s), ohne jedoch einen Unterschied festzustellen. Die bevorzugte Behandlung von TCP-Steuerpaketen (SYN/ACK-Speedup) wurde für die Tests deaktiviert.

Die Tests wurden mit einem parallel-laufenden, bandbreite-füllenden HTTPS-Upload durchgeführt. Mit Ping und einer ICMP-QoS-Firewall-Regel wurde die Funktionstüchtigkeit von QoS im LANCOM 1781EF+ getestet, leider mit unbefriedigenden Resultaten.

1. Test: (QoS "Nicht erzwingt")
-------------------------------------
ICMP-QoS-Firewallregel: %qgds32

Wie aus dem Screenshot "Nicht_Erzwingt.png" und "Nicht_Erzwingt2.png" ersichtlich, werden die Ping-Pakete über die Sende-Warteschlange Urgent-Queue (Tx-Urgent) transportiert. Die HTTPS-Pakete werden über die Sende-Warteschlange Standard (Tx-Normal) transportiert. Dies entspricht dem im LCOS-Referenzhandbuch Kapitel 9.3.1 beschriebenen Verhalten, womit ich davon ausgehen kann, dass kein Konfigurationsfehler vorliegt.

Nicht_Erzwingt.png

Die Ping-Antwortezeiten sind aber katastrophal und Wireshark-Aufzeichnungen zeigen auf, dass die Ping-Pakete in Senderichtung im LANCOM 1781EF+ für über 40 Millisekunden aufgehalten werden, also gar nicht priorisiert behandelt werden.

Nicht_Erzwingt2.png

Gemäss Kapitel 9.3.1 des LCOS-Referenzbuch erwarte ich, dass zuerst die in der Sende-Warteschlange Urgent Queue 1 (Tx-Urgent) stehenden Datenpakete (Ping-Pakete) versendet werden und erst wenn die Warteschlange Urgent Queue 1 leer ist, werden die Datenpakete (HTTPS-Pakete) aus der Standard-Warteschlange (Tx-Normal) versendet. Meine Tests zeigen, dass dies nicht so ist.

2. Test: (QoS "Erzwingt")
-------------------------------------
ICMP-QoS-Firewallregel: %qfgds32

Wie aus dem Screenshot "Erzwingt.png" und "Erzwingt2.png" ersichtlich, werden die Ping-Pakete über die Sende-Warteschlange Urgent-Queue (Tx-Urgent) transportiert. Erst nach mehreren Sekunden wirkt QoS voll und die Ping-Pakete werden praktisch unverzögert übertragen (Ping-Antwortezeiten < 20 Millisekunden). Parallel läuft ein HTTPS-Upload, welcher die ganze nicht-reservierte Upstream-Bandbreite des Internetanschlusses weg frisst. Die HTTPS-Pakete werden wie erwartet über die Sende-Warteschlange Standard (Tx-Normal) transportiert.

Erzwingt.png

Je grösser die per Firewall-reservierte Upload-Bandbreite ist (z.B. %qfgds256 statt %qfgds32) desto schneller wirkt QoS voll und die Ping-Pakete werden nach kürzerer Zeit praktisch unverzögert übertragen.

[GrandDixence]

Erzwingt2.png

Ich habe den Eindruck, dass QoS erst aktiviert wird, wenn der Zähler "Tx-Bloecke-wartend" den Wert 985 oder höher erreicht.

[backslash]

Hi GrandDixence,

Die Ping-Antwortezeiten sind aber katastrophal und Wireshark-Aufzeichnungen zeigen auf, dass die Ping-Pakete in Senderichtung im LANCOM 1781EF+ für über 40 Millisekunden aufgehalten werden, also gar nicht priorisiert behandelt werden.

das kannst du daraus gar nicht ableiten... Erst wenn du dir die Pingzeiten ohne Priorisierung dazu im Vergleich anschaust, kannst du irgendwas interpretieren...

Gemäss Kapitel 9.3.1 des LCOS-Referenzbuch erwarte ich, dass zuerst die in der Sende-Warteschlange Urgent Queue 1 (Tx-Urgent) stehenden Datenpakete (Ping-Pakete) versendet werden und erst wenn die Warteschlange Urgent Queue 1 leer ist, werden die Datenpakete (HTTPS-Pakete) aus der Standard-Warteschlange (Tx-Normal) versendet.

das ist auch genau das, was passiert

Meine Tests zeigen, dass dies nicht so ist.

das tun sie eben nicht...

Der Punkt ist, daß es nach der Auswahl noch eine weitere Queue mit maximal 16 Paketen Länge gibt, in die die Pakete vor dem tatsächlichen Versenden gestellt werden. In dieser Queue reihen sich dann die 92 Byte großen Pings hinter die 1500 Byte großen HTTP-Pakete ein, woduch sich bei 5200 kBit/s Upstream die zusätzliche Verzögerung von ergibt... Diese Queue ist leider aus Performancegründen in Hochlastsitiationen notwendig...

BTW: Es ist nicht so, daß bei einer einfachen Bandbreitenreservierung die Bendbreite in Senderichtung wirklich freigeschaufelt wird. Es werden nur alle Pakete die unterhalb der Schwelle liegen, bevorzugt übertragen.

Anders bei der zur "erzwungenen" Bandbreitenreservierung... Dieses unterscheidet sich von der einfachen Bandbreitenreservierung in einem signifikanten Punkt ... Nämlich dem, daß es dabei gar nicht mehr zu der Konkurrenzsituation in der unteren 16 Blöcke-Queue kommt, weil das TCP schon vorher ausgebremst wird:

Im Ersten Fall hast du pro Sekunde 92 Bytes verschickt, d.h. nur 0,736kBit/s. Da bei einfacher "Bandbreitenreservierung" der Rest vom HTTPS mitgenutzt wird, hast du einen HTTPS-Upstream von 5199,264 kBit/s und du hast die "langen" Delays

Im Zweiten Fall (erzwungen) wird der TCP-Upstream um die angeforderten 32 kBit/s ausgebremst, d.h. er hat nur noch 5168 kBit/s. und für die 0.736 Kbit/s stehen nun 32 Kbit/s bereit - wodurch dies quasi ohne jede Verzögerung durch das Gerät laufen (die untere 16 Blöcke Queue ist immer leer)...

Was lernen wir daraus: QoS-Tests niemals mit einfachen Pings machen, denn deren Aussagekraft ist doch begrenzt. Hättest du das z.B. mit einem Telefonie-Simulator (oder einem anderen Tool, daß kleine UDP-Pakete in festen Raten verschicken und deren Empfang auswerten kann) gemacht, dann hättest du gemerkt, daß in beiden Tests ungefähr das gleiche Delay und der gleiche Jitter heraus kommen - zumindets solange man die reservierten Bandbreite auch wirklich ausnutzt...

Gruß
Backslash

[GrandDixence]

Vielen Dank für die ausführliche Antwort.

Ja, ohne Priorisierung im LANCOM-Gerät bewegen sich die Ping-Zeiten im Bereich von 100 bis 150 Millisekunden bei vollausgelasteten Upstream:

Ping_ohne_QoS.png

[opticum]

hallo und 'tschuldigung das ich den alten Thread nochmal ausgrabe ..

Ich hatte mich damals für einen 1781EF+ entschieden für einen 100/20 FTTH Anschluss und irgendwann festgestellt das (besonders bei Upload) die Ping Zeiten schnell um 100ms nach oben gehen. Ich weiss das man bei dem Lancom den Luxus hat alles und jede Kleinigkeit selbst einstellen zu können und es sich um Geräte handelt, die nicht aus der billig Consumer-Schiene kommen. Daher bitte ich meine folgenden Feststellung nicht als Bashing zu betrachten sondern als ernstgemeinte Frage "wieso";

Upload voll bei Lancom 1781EF+ -> Pingzeiten gehen ca. 100ms nach oben
Upload voll bei Fritzbox 7490 -> Pingzeiten gehen für 1 Sekunde nach oben und bleiben dann stabil
Upload voll bei Sophos UTM -> Pingzeiten bewegen sich überhaupt nicht, egal ob download/upload voll ausgereizt sind

Bevor jetzt jemand schreit das hier ICMP Pakete mit oberster Priorität behandelt werden; Das Antwortverzögerungsverhalten lässt sich auch prima in einer aktiven SSH Sitzung beobachten, nämlich indem die Tasteneingabe und folgende Ausgabe eine gewissere Verzögerung erfährt, dies allerdings nur bei dem Lancom.

Den Support von Lancom habe ich mit dem Thema schonmal "belästigt", die Konfiguration eingereicht und den Hinweis bekommen das alles OK ist. Wieso eine Fritzbox oder die Sophos UTM hier - mutmaßlich - viel besser arbeitet konnte man sich nicht erklären.

Daher hier die Frage in die Runde; macht die Fritzbox / Sophos verstecktes QoS und ist per Default einfach perfekt eingestellt? Macht der Lancom Router da was anders oder kann ich diesen so einstellen das er sich genau so optimal verhält wie die anderen Router?

Die ganze Thematik hat mich schon einige Stunden und Tage herumtesten gekostet, besonders weil ich auf einen Konfigurationsfehler getippt hatte. Würde mich sehr über Feedback freuen. Vielen Dank!

[MariusP]

Hi,
Kannst du die Pakete aufzeichnen? Dann könntest du mögliche QoS Flags erkennen.
Gruß

[Dr.Einstein]

Würde einfach sagen, dass LCOS hat einen anderen Queuing Algorithmus, als andere Hersteller. Und der wirkt sich für kleine Pakete zwischendurch nicht gut aus. Dafür haben vermutlich die Fritten und Sophos in anderen Up- / Downloadszenarien mehr Probleme wo Lancom weniger hat?

Gruß Dr.Einstein

[opticum]

zumindest bei der Sophos konnte ich kein verstecktes QoS feststellen.

Interessant war allerdings das wenn der Lancom als 1. Router und die Sophos als 2. Router in der Kette war, dasselbe Ping Antwortverhalten an den Tag kam. Ursächlich scheint hier wieder der Lancom gewesen zu sein, setze ich ein anderes Gerät dazwischen (zwischen WAN und Sophos) ist alles wieder ohne Latenzerhöhung bei Up/Download.

Bitte meinen Disclamer im Hinterkopf behalten das ich kein Bashing betreiben will, sondern eine Lösung suche mit der ich das mit dem Lancom auch so schön hin bekommen; aber ein Profi Router wie der Lancom sollte es doch hinbekommen wenn eine Fritte, Sophos, OpenWRT Kiste (mit 50 euro Hardware) die Leitung optimal zu nutzen. Leider bin ich wohl nicht Profi genug dem ganzen auf den Grund zu gehen, daher meine Frage in die Runde

[GrandDixence]

Interessant war allerdings das wenn der Lancom als 1. Router und die Sophos als 2. Router in der Kette war, dasselbe Ping Antwortverhalten an den Tag kam. Ursächlich scheint hier wieder der Lancom gewesen zu sein, setze ich ein anderes Gerät dazwischen (zwischen WAN und Sophos) ist alles wieder ohne Latenzerhöhung bei Up/Download.

QoS bzw. der Queuing Algorithmus wirkt nur, wenn sich die Datenpakete in einer Warteschlange stauen.

Solch ein Warteschlange-Stau entsteht üblicherweise nur, wenn der Router die Datenpakete über eine schnellere Leitung (z.B. Gigabit-Ethernet) erhält und über eine langsamere Leitung (z.B. ADSL, VDSL, Mobilfunk, Fernsehkabel) weiterleiten muss. Da die meisten Router für LAN und WAN über Gigabit-Ethernet-Anschlüsse verfügen, können die Router die Datenpakete gleich schnell senden und empfangen und es entsteht kein Warteschlange-Stau im Router und somit wirkt das QoS bzw. der Queuing Alorithmus im Router nicht. Wird der Internetanschluss (WAN) über einen Ethernet-Anschluss/Port realisiert, muss die WAN-Schnittstelle "künstlich" verlangsamt werden, damit das im Router konfigurierte QoS bei Hochlastsituationen wirkt. Zu einem Warteschlange-Stau kann es nur in Upstream/Upload-Richtung kommen, da in der Regel das Heimnetzwerk (LAN) schneller als der Internetanschluss (WAN) ist.

Bei LANCOM-Router erfolgt diese künstliche WAN-Schnittstellen-Drosselung über die LCOS-Einstellung:

Code: Alles auswählen

/Setup/Schnittstellen/DSL/Upstream-Rate

Siehe dazu auch die entsprechende Hinweise im LCOS-Referenzhandbuch:

https://www.lancom-systems.de/docs/LCOS ... rames.html

https://www.lancom-systems.de/docs/LCOS ... 47643.html

Drosselt der Router die WAN-Schnittstelle nicht künstlich, bildet sich der Warteschlangestau im Medienkonverter (z.B. ADSL-/VDSL-Modem, EuroDOCSIS-Kabelmodem, Glasfaser-Konverter) und der QoS-Mechanismus im Medienkonverter wirkt bei Hochlastsituationen. Im genannten Beispiel von zwei hintereinander geschalteten Router muss der erste Router auf eine höhere Datenübertragungsgeschwindigkeit drosseln (z.B. 70 MBit/s) und der zweite Router muss auf eine niedrigere Datenübertragungsrate drosseln (z.B. 45 MBit/s). Dabei muss die niedrigere Datenübertragungsrate leicht unter der maximalen Datenübertragungsrate des Internetanschlusses (z.B. 50 MBit/s) liegen, damit das QoS in beiden Routern wirkt und nicht das QoS im Medienkonverter (hier Glasfaser-Konverter auf Seite Heimnetzwerk oder Internetprovider) eingreift.

[GrandDixence]

Gemäss:

http://www.lancom-forum.de/feedback-lco ... 15384.html

wird LCOS v9.20 RU1 einen verbesserten QoS-Mechanismus bringen. Vielleicht lohnt sich ein Test der Beta-Version...

[opticum]

Danke für den Tip. Mal anschauen...

[opticum]

Wäre jemand so nett und könnte mir seine QoS Einstellungen zeigen? Ich habe bei einem Ping Test ohne last 20ms zum Google DNS, sobald ich einen Speedtest Starte und der Upload getestet wird steigt die Ping auf bis zu 400ms. So blöd sich das anhört, bei der Fritzbox passiert das nicht. Ich habe schon alles möglich ausprobiert und nichts hilft.

Das Argument das ein Lancom ein professionelles Produkt ist und man daher alles was QoS angeht daher manuell einrichten muss lasse ich gelten, wenn man dazu irgendwo Informationen findet wie das zu machen ist. Die Fritzbox wird hier doch auch kein Voodoo anwenden...

[Dr.Einstein]

Persönliche Meinung: Lancom hat das Thema QoS ziemlich vernachlässigt im Vergleich zu anderen Marktbegleitern. Dein beschriebener Fall ist eine Ausprägung davon.

Gruß Dr.Einstein

[opticum]

schade, dann geht mein Geld halt demnächst woanders hin. Danke für die Antwort!

[Jirka]

Hi,

Wäre jemand so nett und könnte mir seine QoS Einstellungen zeigen?

hast Du in diesem Thread hier schon irgendwo Deine gezeigt? (Ich habe den Thread nur überflogen.)

Ich würde mir Dein Problem und Deine Konfig gerne anschauen, aber im Augenblick passt nichts mehr. Kannst Dich gerne in 3 Wochen melden.

Viele Grüße,
Jirka