QoS-Konfiguration bei LCOS 10.90

[DirkK]

Hallo zusammen,

die QoS-Erweiterung in LCOS 10.90 scheint mir ja recht interessant zu sein.
Weiß jemand, wo man bereits Informationen bzgl. der Konfiguration nachlesen kann, bzw. kann das vielleicht mal kurz zusammenfassen, wie das z.B. für VoIP oder Videokonferencing zu konfigurieren ist. V.a. was hier in den Punkten "Paketstau-Aktion" und "Queues" einzutragen wäre (siehe auch Screenshot).

Danke und VG Dirk

[DirkK]

Was mir in dem Zuge noch aufgefallen ist: bei meinem LC-1784VA wird bei LCOS 10.90.0076-RC2 die Syncronisationsrate nicht mehr in die QoS-Informationen (z.B. beim LANMonitor) übernommen.

Habt ihr ähnliche Beobachtungen gemacht?

VG Dirk

[Frühstücksdirektor]

Hallo Dirk,

ich verstehe eine Sache nicht:

Manchmal ist das Feedback hier gut für LANCOM, wenn z.B. Bedarf an KB-Artikel oder Verbesserung der Doku ist.

Bei 10.90 und QoS gibt es dazu doch eine Menge an Infos, auch Beispiele im Addendum:
https://www.lancom-systems.de/produkte/ ... -candidate

Kennst Du das? Oder reicht das nicht?

[DirkK]

Bei 10.90 und QoS gibt es dazu doch eine Menge an Infos, auch Beispiele im Addendum:
https://www.lancom-systems.de/produkte/ ... -candidate

Kennst Du das? Oder reicht das nicht?

Ahhh Danke!! Ich habe genau das Addendum gesucht... allerdings auf dem FTP-Server und da war/ist es eben leider nicht zu finden, nur die Release Notes, deswegen mein Thread. Werde mir das mal anschauen.

VG Dirk

[Frühstücksdirektor]

Bzgl. dem LANmonitor. Bei mir geht es...

Wie ist das Setup? Welcher Provider? PPP? Dual Stack? internes Modem?
Ab der 10.90 wird der BNG-Name im LANmonitor auch angezeigt. Nicht, dass es da Probleme gibt.

[DirkK]

Wie ist das Setup? Welcher Provider? PPP? Dual Stack? internes Modem?

Recht einfach: Inexio als Provider, ja PPP, Dual Stack über internes Modem VDLS2 17a over-ISDN

Ab der 10.90 wird der BNG-Name im LANmonitor auch angezeigt. Nicht, dass es da Probleme gibt.

Meinst du mit BNG-Name den "Access-Concentrator-Name:"? Der ist bei mir leer

VG Dirk

[Frühstücksdirektor]

Hallo Dirk,

ja, genau. Jetzt sehe ich es bei einem anderen Gerät auch.

Viele Grüße,
Frühstücksdirektor

[DirkK]

Jetzt sehe ich es bei einem anderen Gerät auch.

Danke für die Bestätigung .... naja ist ja ein RC und damit kann sich da ja noch was tun.

VG Dirk

[DirkK]

Oder reicht das nicht?

Werde mir das mal anschauen.

OK, habe mir das mal angeschaut und auch mal eine Config dazu erstellt und ja, so ganz reicht das gerade nicht

Was ich noch nicht so ganz verstehe ist die Paketstau-Aktion. Wobei das Prinzip (Taildrop, RED) hier schon klar ist.
Nur verstehe ich den Metrik-Typ (insbesondere "Frames") da nicht so ganz. Ich habe den Queues Metrik-Typ auf "Prozent" gesetzt, weil ich bei beiden WAN-Leitungen (mit unterschiedlichen Kapazitäten) den gleichen Prozentwert für QoS verwenden will.
Was aber bedeutet dann "Frames" und in den Doku-Bsp. 50? Heißt das dann (um bei dem Doku-Bsp. zu bleiben) bei > 50 (Ethernet?-)Frames werden die Pakete gedropt? Aber woher weiß ich wie viele Frames die Queues aufnehmen können? 50, 80, 100, 500?

Auf jeden Fall zeigt die Statistik-Tabelle im 1784, dass die Config zieht, wobei ich noch nicht weiß, ob sie auch das gewünschte bewirkt.
Ich habe mal drei Queues (zum Test) eingerichtet:

1. VOIP: mit EF und Voice-Admit
2. VIDEOCONF: alles mit AFxx
3. HIGH: alles von CS1-CS7

Was ich da aber bemerkenswert finde ist, die hohe Anzahl an vorab klassifizierten urgent Paketen und die nicht unerhebliche Anzahl an "im Paketstau verworfenen".

Kann man irgendwie rausfinden, woher diese Pakete kommen?

VG Dirk

[backslash]

Hi DirkK

Was aber bedeutet dann "Frames" und in den Doku-Bsp. 50? Heißt das dann (um bei dem Doku-Bsp. zu bleiben) bei > 50 (Ethernet?-)Frames werden die Pakete gedropt?

genau, sobald 50 Pakete in der Queue stehen werden nachfolgende gedroppt

Aber woher weiß ich wie viele Frames die Queues aufnehmen können? 50, 80, 100, 500?

die Queues können beliebig viele aufnehmen... Hier geht es um Qualitätsanfoderungen...

• Ein Voice-Stream kann problemlos mal Pakete verlieren, aber ein Telefonat wird "unerträglich", wenn es ein Delay von mehr als 100ms gibt. Wenn du jetzt z.B. annimmst, daß alle 20ms ein Paket kommt, kannst du dir selbst ausrechnen ab wie vielen angestauten Paketen es unerträglich wird: 100ms/20ms = 5 Pakete Pro Telefonat
• Bei normalen Daten (Mail, Surfen etc.) ist das Delay hingegen relativ egal, aber Paketverlußte wiegen schwer, so daß dafür die Schwelle deutlich höher liegen kann/sollte

Die Paketstau-Aktion wirkt sich aber sowieso nur dann aus, wenn vom LAN mehr Pakete kommen, als auf das WAN weitergeleitet werden kann...

Gruß
Backslash

[DirkK]

die Queues können beliebig viele aufnehmen... Hier geht es um Qualitätsanfoderungen...

Hi Backslash,

ahhhh, so langsam wird es klarer... d.h. es macht vermutlich Sinn mit verschiedenen Paketstau-Aktionen zu arbeiten

Danke!!

VG Dirk

[backslash]

Hi DirkK,

d.h. es macht vermutlich Sinn mit verschiedenen Paketstau-Aktionen zu arbeiten

genau, deshalb kann ja jeder Queue eine eigene Paketstau-Aktion zugewiesen werden... (außer bei der internen "#urgent" Queue - die dropt niemals...)

Gruß
Backslash

[GrandDixence]

Wäre es nicht sinnvoller, im LCOS die Sendewarteschlange mit einer maximalen Aufenthaltszeitdauer zu konfigurieren?
Alle Datenpakete, die länger als die konfigurierte Zeitdauer in der Warteschlange stehen, werden weggeworfen (DROP). Zum Beispiel: 5 Millisekunden

Jetzt wird die maximale Länge der Sendewarteschlange mit der Einheit "Anzahl Datenpakete in der Warteschlange" konfiguriert, was wohl kaum den Bedürfnissen der Netzwerktechnikern entspricht.

Wenn ich das richtig verstehe, unterstützt die aktuelle RC-Version von LCOS 10.90 heute das Warteschlangen-Prinzip FIFO und RED:
https://help.mikrotik.com/docs/spaces/R ... eues-Kinds

QoS in LCOS 10.90 würde mit dem Konfigurationsparameter "Maximale Aufenthaltszeitdauer in der Sendewarteschlange" dem Verfahren CoDel entsprechen. Siehe Kapitel 2.1 von:
https://hal.science/hal-04127721/document

[backslash]

Hi GrandDixence

Alle Datenpakete, die länger als die konfigurierte Zeitdauer in der Warteschlange stehen, werden weggeworfen (DROP). Zum Beispiel: 5 Millisekunden

das kannst du (indirekt) über die Anzahl Bytes in der Warteschlange regeln... Bei gegebener Bandbreite B und geünschter Zeit t ergibt sich die Paketgröße zu s = B*t/8.
Beispiel: bei B = 100MBit/s, t = 5ms => s = 100*10^6 * 0,005 / 8 = 100 * 5 * 125 = 62500 Bytes...

Gruß
Backslash