Lancom 1611 gibt Bandbreite nicht frei(QOS-MTU-Reduzierung)

Anmeldungsdatum: 06.03.2005 Beiträge: 61

Hallo,

ich habe beim LANCOM 1611 folgende QOS-Einstellungen gemacht:

Name,Prot.,Quelle,Ziel,Aktion,verknuepft,Prio,Aktiv,VPN-Regel,Stateful,Rtg-Tag

SIP_ABGEHEND,UDP,SIP_ABGEHEND0, ANYHOST,%Lcds0 %A %Fpt512 %Qctds80,ja,4,ja,nein,ja,0
SIP_EINGEHEND,UDP,ANYHOST,SIP_EINGEHEND0,%Lcrds0 %A %Fpr512 %Qcrds80,ja,3,ja,nein,ja,0

Objekttabelle:
SIP_ABGEHEND0 %A192.168.81.93 %A192.168.81.96 %A192.168.81.92
SIP_EINGEHEND0 %A192.168.81.93 %A192.168.81.96 %A192.168.81.92

Nach dieser Konfig sollte die Bandbreite eigentlich dynamisch vergeben werden, sprich nach dem VOIP-Telefonat sollte die Bandbreite des DSL-6000 zumindest annähernd wieder zur Verfügung stehen. In der Praxis sieht das bei mir aber anders aus: N
Nach Reboot des Routers habe ich lt. Speedmeter.de 415-460 kb Down und 50kb UP. Nach dem einem VOIP Telefonat (aufgelegt) sinkt die Rate auf 125 kb Down und 45 Up und erhöht sich auch nicht mehr. Wenn von noch einem anderen VOIP-Telefon auch noch telerfoniert wird, dann sinkt die der Download auf ca. 60 kb und der Upload auf ca. 30 kb. Es wurde immer nach dem Telefonat gemessen. Erst wenn ich den Router wieder neu boote, erhalte ich die normalen Werte.

Was mache ich falsch?

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi cyberpeter,

du kannst unter /Status/IP-Router/QoS nachschauen, wieviel momentan reserviert ist.

Die QoS-Bandbreiten werden nicht sofort nach dem Telefonat freigegeben, sondern erst nach Ablauf eines Timeouts. Dieser Timeout ist der gleiche, wie im Masquerading. Dort sind als Default 20 Sekunden für UDP-Verbindungen eingetragen. Wenn du diesen Wert erhöht hast, dann dauert es auch entsprechend länger, bis die Bandbreite wieder freigegeben wird.

Gruß
Backslash

Anmeldungsdatum: 06.03.2005 Beiträge: 61

Danke für die Antwort. Laut der Auskunft unter /Status/IP-Router/QoS ist nichts
reserviert.

Lösche ich jedoch die MTUReduzierung, dann tritt ist auch nach einem VOIP Telefonat die volle Bandbreite wieder da.

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi cyberpeter,

Zitat:

Laut der Auskunft unter /Status/IP-Router/QoS ist nichts
reserviert.

dann ist auch nichts reserviert. Dann muß das Verhalten am Meßaufbau liegen.

Zitat:

Lösche ich jedoch die MTUReduzierung, dann tritt ist auch nach einem VOIP Telefonat die volle Bandbreite wieder da.

wie machst du deine Messung? Läßt du ein NetIO laufen während das Telefonat läuft und legst dann auf? In diesem Fall ist es gut möglich, daß sich erstmal nicht ändert, da di ePMTU-Reduzierung die Server dazu zwingt kleine Pakete zu schicken, wodurch der Protokoll-Overhead steigt. Der Server wird auch für die Verbindung auf der die PMTU-Reduzierung erzwungen wurde so schnell nicht mehr auf höhere Paketegrößen wechseln.

D.h. um eine aussagekräftige Messung machen zu können mußt du (nachdem die Reservierung zurückgenommen wurde) den Durchsatz mit einem anderen Server messen, der nichts von der PMTU-Reduzierung weiß...

Gruß
Backslash

Anmeldungsdatum: 06.03.2005 Beiträge: 61

Hallo,

die ich habe mich etwas missverständlich ausgedrückt. Die Reservierung während dem Gespräch funktioniert ohne Probleme. Nach dem Gespräch ist nach ca. 10 Sekunden die Reservierung wieder weg.

Gemessen habe ich das ganze über www.Speedmeter.de . Zugegeben nicht die aussagekräftigste Messart, aber fürs Grobe reichts trotzdem und das nicht nur auf speedmeter.de die MTU-Reduzierung zuschlägt merkt man bei Downloads von anderen Seiten.

Das Problem scheint, das die MTU-Reduzierung nach dem Telefonat nicht wieder wegfällt. Ich vermute, dass mein Problem der Hacken bei "Regel hält Verbindungszustände nach (empfohlen)" ist.

Dies muss ich noch testen.

edit:

Genau dieser Hacken war das Problem. Macht man ihn Weg, ist die MTU-Reduzierung auch nach 10 Sekunden weg. Very Happy

Danke nochmal backslash, ohne deine Anleitung hätte ich nie in die Statusanzeig von QOS reingeschaut.

Anmeldungsdatum: 06.03.2005 Beiträge: 61

Die Freude war leider nur von sehr kurzer Dauer. Das Wegfallen der MTU-Reduzierung wenn keine VOIP-Gespräche geführt werden funktioniert nicht zuverlässig. Ist die MTU-Reduzierung Aktiv, gehen einige wichtige Seiten nicht bzw. nicht zuverlässig.

Selbst wenn der Router neu gestartet wird, ist beim Neustart auch ohne VOIP Gespräche die MTU-Reduzierung aktiv. Erst nachdem die Regel gelöscht ist und dann wieder neu eingegeben wird funktioniert der Wegfall der MTU-Reduzierung nach Beendigung des Gesprächs wieder ein paar Mal bis sie dann wieder fest ist.

Kann mir hier vielleicht jemand weiterhelfen, das ohne MTU-Reduzierung die Gespräche weitaus öfters ein Echo haben als mit.

Anmeldungsdatum: 09.12.2004 Beiträge: 148 Wohnort: Bonn

Hallo,

ich "arbeite" auch an einer sinnvollen QOS-Regel für das VOIP...

@cyberpeter:
Vielleicht liegt es daran: Die QOS-Regel gilt bei allen Packeten, die zu bzw. von den IP-Telefonen kommen. Bei den meisten SIP-Providern werden die Telefone regelmäßig alle 5-15 Sekunden "angepingt", um die Einträge in der NAT-Tabelle aktiv zu halten. Die PMTU-Reduzierung sollte aber nur bei den RTP-Packeten (Sprachdaten) greifen. Vielleicht wird die PMTU-Reduzierung deshalb nicht zurückgenommen...

Und hier komme ich nicht weiter: Ich möchte die RTP-Packete anhand ihres DSCP/TOS-Feldes priorisieren. Leider werden sie irgendwie nicht zuverlässig erkannt. Im IP-Router-trace haben sie DSCP/TOS: 0x18.
Was muß ich im LanConfig genau unter
Filterregel->Aktionen->Trigger und unter
Filterregel->Qos->Aktionen eintragen?
Der Haken bei DiffServ-Feld bei den IP-Router-Einstellunge hat welchen
Einfluß auf die Qos-Einstellungen?

Gruß,
SEBastian

Anmeldungsdatum: 06.03.2005 Beiträge: 61

Tja wenn ich nicht das Handbuch lese .... S.254

@SunSeb

Wenn ich das lt. Handbuch richtig verstanden habe, lösen Daten, die eine "gewisse Kennung" haben die Firewall-Regel mit QOS aus. Voraussetzung ist, dass das VOIP Gerät diese Kennung mit überträgt. Macht VOIP-Telefon das nicht bzw. nicht richtig, greift auch die Regel nicht.

Anmeldungsdatum: 01.03.2005 Beiträge: 41

Also müssten wir jetzt wissen, ob unsere FBF das auch richtig weitergibt, oder?

Moderator Anmeldungsdatum: 08.11.2004 Beiträge: 4571 Wohnort: Aachen

Hi SunSeb

Zitat:

Und hier komme ich nicht weiter: Ich möchte die RTP-Packete anhand ihres DSCP/TOS-Feldes priorisieren. Leider werden sie irgendwie nicht zuverlässig erkannt. Im IP-Router-trace haben sie DSCP/TOS: 0x18.
Was muß ich im LanConfig genau unter
Filterregel->Aktionen->Trigger und unter
Filterregel->Qos->Aktionen eintragen?
Der Haken bei DiffServ-Feld bei den IP-Router-Einstellunge hat welchen
Einfluß auf die Qos-Einstellungen?

Der Haken an beim DiffServ-Feld bewirkt dreierlei:

1. Das DSCP/TOS-Feld wird im IP-Routertrace als DSCP interpretiert (d.h. da steht dann "Klartext" statt des Hexwertes).

2. Pakete mit dem DSCP "EF" (Expedited Forwarding) werden bevorzugt übertragen wenn es keine Regel gibt, die ein anderes Verhalten erzwingt.

3. Pakete mit den DSCPs AFxx (Assured Forwarding) werden nicht verworfen.

Um herauszufinden was DSCP/TOS: 0x18 bedeutet, setzt du einfach mal den Haken. Wenn mich nicht alles täuscht, mußte der IP-Routertrace dann DSCP: CS3 anzeigen - und genau das mußt du als Bedingung in die Regel einsetzen...

Gruß
Backlsash

Anmeldungsdatum: 09.12.2004 Beiträge: 148 Wohnort: Bonn

Hi Backslash,

Zitat:

Um herauszufinden was DSCP/TOS: 0x18 bedeutet, setzt du einfach mal den Haken. Wenn mich nicht alles täuscht, mußte der IP-Routertrace dann DSCP: CS3 anzeigen - und genau das mußt du als Bedingung in die Regel einsetzen...

genauso habe ich das jetzt gemacht und das war es. Mit dem Haken im DiffServ-Feld werden die gewünschten Packete zuverlässig erkannt. Supi - Danke Smile

Jetzt werden nämlich genau nur die eigentlichen Sprachdaten priorisiert und nicht jeder Traffic des Telefons.

Gruß,
SEBastian

Anmeldungsdatum: 06.03.2005 Beiträge: 61

@ SunSeb

Hallo,

kannst Du mir bitte schreiben, was Du wo genau eingetragen hast?

Anmeldungsdatum: 09.12.2004 Beiträge: 148 Wohnort: Bonn

Hallo cyberpeter,

ich habe folgende Einstellungen vorgenommen:

Haken bei IP-Router->Allgemein->Diff-Serv-Feld beachten.

Das Telefon sendet die RTP-Sprachdaten mit DSCP: EF(46) und die Sprachdaten des SIP-Servers kommen mit DSCP: unknown (6).

Daher habe ich eine Firewall-Regel erstellt mit folgenden Daten:
Allgemein: Nur Haken bei Regel aktiv
Aktionen: kein Eintrag
Qos: zwei Aktionen mit
a) Haken nur bei DiffServ-CP: EF; Haken bei Aktion nur für gesendete Pakete; Reduzierung der PMTU einschalten: PMTU 256
b) Haken nur bei DiffServ-CP: Wert 6; Haken bei Aktion nur für empfangene Pakete; Mindestbandbreite reservieren (100 kBit/s)
Stationen: von: IP des Telefones an: alle Stationen
Dienste: Benutzerdefinierte Protokolle: Haken bei UDP

Damit wird die PMTU-Reduzierung und Reservierung der Empfangsbandbreite sauber zu Beginn des Gespäches aktiviert und danach (20s UDP-Aging) beides wieder zurückgenommen. Sicherlich fehlt hier noch die Reservierung der Sendebandbreite - ich habe aber bisher gute Sprachqualität, kaum Upload und die Pakete werden ja von sich aus schon priorisiert. Das alles ist aber lediglich recht speziell und vorläufig - aber vielleicht hilft es ja etwas...

Schönen Abend,
SEBastian

Anmeldungsdatum: 06.03.2005 Beiträge: 61

Hallo,

erst mal vielen Dank für die Antwort. Werd ich morgen vormittag mal im Büro testen. Wie hast Du herausgefunden, dass die Daten vom Telefon EF haben und die Daten des Sip-Servers unknows (6)?

Ebenso noch einen schönen Abend

Peter

Anmeldungsdatum: 09.12.2004 Beiträge: 148 Wohnort: Bonn

Moin,

im IP-Router-Trace kann man die Kennzeichnung (DSCF) der Pakete sehen. Das sind beim Telefonat natürlich dann extrem viele - aber aus der Doku des Telefons war das so nicht zu erkennen und zum SIP-Server (des Providers) hatte ich gar keine Angaben.
Zur Kontrolle dann noch "trace # Firewall"...

SEBastian