OPT-QoS ist ein fli4l-Modul fürs Bandbreitenmanagement.

Links, die sich jeder Interessierte in dieser Reihenfolge anschauen sollte

Diese Links sollten einen das Verständnis über die zu Grunde liegende Funktionsweise geben. Englisch ist leider Pflicht ;-)

Grundlagen

Zu Grunde liegt das sogenannte HTB (Hierarchy Token Bucket). Ein Token Bucket ist ein mit Token gefüllter virtueller Korb mit der Größe von $burst/$chburst. Jedes Token repräsentiert ein Byte. Wenn ein Byte verschickt wird, wird es aus dem Korb genommen. Der Korb wird jede Sekunde mit der in $minrate festgelegten Anzahl an Kbits gefüllt. Hat eine Klasse keine Token mehr, braucht aber noch Bandbreite, fragt sie bei ihrer Elternklasse nach. Hat diese noch Token übrig, verteilt sie diese nach dem Verhältnis der $minrate der Kinder.

Zuallererst wird eine HTB-qdisc generiert. Sie ist der Pool, in den alles reinkommt. Nur mit ihr kommuniziert der Kernel. An diese qdisc werden dann wieder Klassen befestigt und an diese wiederum Klassen. Im Kernel ist eine maximale Baumtiefe von 8 vorgegeben. QOS für 2.0.x hat eine Beschränkung auf 3.

Grundsätzliches

Um erstmal eine Übersicht über die Baumstruktur zu bekommen, empfehle ich eine Beispieldatei mit dem Fli4lQosAdmin anzuschauen. Danach nimmt man sich die Textdatei vor und versucht das Graphische nachzuvollziehen. Die eigentliche QOS.txt kann man mit dem Fli4lQosAdmin erstellen. Dabei sollte man aber unten stehende Tipps beherzigen.

Spätestens jetzt sollte die Dokumentation gelesen werden. Die folgenden Tipps ergänzen sie nur.

IP-Netzmasken werden hier erklärt.

"Client" in einem Filter bedeutet, dass der bestimmte Port auf dem entfernten PC im Internet gemeint ist.
"Server" spezifiert den Port auf dem eigenen Rechner.

Portranges sind mit Fli4l 2.0.x nur im Upload und unter gleichzeitiger IP-Adressenangabe möglich. Schreibweise: Port:Port

Bei FLI4L 2.1.x sind Portranges und Portlisten generell möglich. Einzelheiten siehe Doku.

Die Filter werden standardmäßig für UDP und TCP erstellt. Man kann ein paar Filter in der Firwall sparen indem man die Option TCP bzw. UDP angibt. Z.b. brauchen die SSH/HTTP Klassen nur TCP und die DNS Klasse nur UDP.

FLI4L 2.0.x kommt nur mit Anschlüssen bis zu 2048 Mibit Downloadrate klar.

Standardklasse

Wichtig: Die Standardklassen, also: 

QOS_INTERNET_DEFAULT_DOWN=''
QOS_INTERNET_DEFAULT_UP=''

dürfen a) nicht auf Klassen zeigen, die eine Unterklasse haben und b) keine Filter angehängt haben. Sonst geht u.U. überhaupt keine Netzverkehr mehr. Der beste Weg ist es, direkt eine anzugeben. Nur Profis sollten eine beliebige nehmen. Auch die 0 darf nicht verwendet werden, solange es in die jeweilige Richtung (up oder down) unterhalb davon irgendeine Klasse gibt.

Filterreihenfolge

Beim Erstellen der Filter sind ein paar Regeln zu beachten:

Fli4l 2.1.x

Es gibt eine allgemeingültige Reihenfolge, persönliche Abweichungen können aber auftreten: (IP/PORT)+Dienst -> IP+Port -> Port -> IP

Wenn eine IP besonders behandelt werden soll (z.b. ein Server), dann muss u.U. dieser IP-Filter vor den Port. Bitte fragt nicht nach der Reihenfolge sondern überlegt euch lieber nochmal 30min, was eure Konfiguration gerade macht.

Für Profis:

Fli4l 2.0.x

(IP/PORT)+Dienst -> IP+Port -> Port -> IP

Welche Regeln sollte man einhalten beim Einstellen der jeweiligen Raten?

Eine gute Ressource sind die docum.org HTB Tests. Oder gleich das Fazit: HTB rules

Immer im Blick haben, dass minimal 12 Kbit/s sinnvoll sind. Erklärung siehe "Quantum" weiter unten.

Als nächstes sollte die Summe der $minrate aller Kinder die $minrate der Mutterklasse nicht überschreiten. Wenn alle Kinder mit ihrer zugewiesenen minimalen Rate senden, überschwemmen sie die Oberklasse. Damit ist nicht mehr die $minrate der Mutter zuständig für die $minrate des gesamten Teilbaums, sondern die Summe der $minrate der Kinder.

HTB beachtet übrigens die $maxrate der Mutter aus Performancegründen nicht immer. Dieser Wert wird überschritten, falls die Summe der $minrate der Kinder größer als $maxrate der Mutter ist. Dieser Wert wird nur herangezogen, falls es überschüssige Bandbreite unter den Kindern zu verteilen gibt. Dann wird der $maxrate Wert der Mutter eingehalten.

Die ACK-Klasse hat in meinen Versuchen, je nach offenen Downloadverbindungen, eine Rate von 12 bis 20kbit/s.

Statistik

Mit dem Befehl tc -s class show dev ???? wird der momentane Zustand der Klassen angezeigt. ???? steht für die beiden Netzwerkinterfaces des Routers (z.b. eth0/ppp).

tc -s -d class show dev ???? zeigt mehr Attribute.

Erklärung der einzelnen Ausdrücke:

Gut zu wissen

Serverdienste

Serverdienste auf dem Router, z.B. FTP, lassen sich nur im Upload begrenzen. Bei dynmamischen Ip-Adressen müsste die QOS-Config bei jeder Einwahl neu eingestellt werden. Das wäre mal was für Skriptauskenner! Ohne Ip-Anpassung kann man die Serverdienste im Upload nur über die Defaultklasse laufen lassen. Der Download durch Serverdienste auf dem Router ist nicht regulierbar, da die qdisc am Heim-Laninterface sitzt.

Update: Ein solcher Skriptauskenner hat ein solches Skript in die Version von OPT_QOS_04 (für FLI 2.0.x) eingebaut. Es kann von http://www.laserdesign-gmbh.de/lutz heruntergeladen werden.

Prioritäten

Prioriäten regeln die Verteilung von überschüssiger Bandbreite. Die Klassen mit der höchsten Prioriät bekommen alle freie Bandbreite. Außerdem soll die Latenz bei hoch priorisierten Klassen leicht verringert werden. Nie vergessen, dass kleinere Nummer = höhere Priorität bedeutet! Die höchste Prioriät ist also Null.
Prioritäten machen Sinn, um z.b. Emule so weit wie möglich in die Schranken zu verweisen.

  1. Bsp: Emule-Klasse mit 20kbit und Http-Klasse mit 50kbit wollen mehr senden als ihre $minrate hergibt. Da alle anderen Klassen nichts senden, bleiben bei DSL Upload 128 - 70 = ~60kbit übrig. Diese werden im Verhältnis 20:50 auf die Emule-Klasse und die Http-Klasse verteilt
  2. Bsp: Die Emule-Klasse bekommt jetzt Priorität 1, die Http-Klasse Priorität 0. Die überschüssige Bandbreite wird komplett an die Http-Klasse vergeben.

Bursts

Die in $burst festgelegte Anzahl an bytes darf eine Klasse mit $maxrate senden, ohne dass andere Klassen berücksichtigt werden. Ideal für http. Hier gibt es für mich allerdings noch etwas Klärungsbedarf. Auf docum.org ist ein sogenannter "hysteresis"-Switch erwähnt. Er sollte ausgeschaltet werden bei Bursts größer 100 Kbyte. Nur steht nirgends richtig beschrieben, ob es denn auch mit geht. Der $burst beeinflusst die Größe des Token Bucket Korbs. Ich habe 400 Kbyte für meine http Klasse angegeben und fahre damit ganz gut. Es ist kein Unterschied wie Tag und Nacht, aber doch spürbar.

Es ist möglich Klassen durch den Befehl tc class change ... zu ändern. Damit lässt sich geziehlt die Burst-Rate einer Klasse ändern. Hier ein Beispiel:

{{{tc class change dev eth0 parent 10:4 classid 10:9 htb \ rate 137Kbit ceil 740Kbit burst 1000Kbit prio 1 }}}

Bursts sollten nur der jeweiligen Klasse gegeben werden. Wenn man den Mutterklassen ebenfalls große $burst Werte gibt, dann verbraten sie diese durch den Verkehr ihrer anderen Unterklassen. $cbursts sind Bursts mit der maximalen Interfacegeschwindigkeit. Die minimale Größe ist abhängig von der Timerauflösung des PCs und sollte so nahe wie möglich der MTU sein. TC berechnet das zum Glück aber automatisch. Docum.org hat einige Tests gemacht. Zu beachten ist, dass Bsp. 4 fehlerhaft beschriftet ist. Hier sollte wohl nur $cburst in der Mutterklasse aktiviert sein.

Quantum

Das sogenannte $quantum spielt eine Rolle bei der Verteilung von überschüssiger Bandbreite. Jede Klasse kann pro Durchgang ein quantum an Bytes verschicken. Es sollte daher auf jeden Fall größer als die MTU = 1500 bytes (Ethernet) / 1492 bytes (PPPEO), aber so klein wie möglich sein. Berechnet wird es folgerndermaßen: $minrate in kbit * 1000 / ( $r2q * 8 ) . $r2q ist eine Konstante. Beispiel für den kleinstmöglichen Wert von $r2q = 1: 12 Kbit * 1000 / 8 = 1500 bytes. Kleiner als 12kbit sollte eine $minrate also nie sein, weil sonst das gegenseitige Abhängigkeitssystem durcheinander gerät.

Betrifft nur Fli4l 2.0.x: Die Autoren von OPT_QOS haben den Wert von $r2q unverändert auf dem Standard von 10 gelassen. Für DSL zu hoch. Um das Quantum separat einzustellen, muss man in der rc.qos an folgende zwei Zeilen "r2q" gefolgt von einer Zahl anhängen. Wobei Upload = Outbound und Download % 

## HTB für Inbound-Device aktivieren:

$TC qdisc add dev $QOS_LOCALNET_DEV root handle 10: htb default $QOS_INTERNET_DEFAULT_DOWN r2q 2

## HTB für Outbound-Device aktivieren:

$TC qdisc add dev $QOS_INTERNET_DEV root handle 20: htb default $QOS_INTERNET_DEFAULT_UP r2q 1

P2P

Es gibt mehrere Möglichkeiten mit Emule und Co fertig zu werden. Doch zuerst muss geklärt werden, was überhaupt das Problem ist.

Das P2P-Problem

Wie bekannt ist, kann man per QoS verschiedenen Filesharing Programme nicht ohne Probleme beschränken, da die Pakete mit Source-Port/Ip und Destination-Port/Ip nicht klar von anderen unterscheidbar sind.

Es gibt nämlich sowohl beim Up- als auch beim Download 2 Arten des Transfers

1. von außen initiiert:
Femder PC : beliebiger Port -> Eigener Pc : von mir konfigurierter Port
Hier habe ich in der Hand welcher Port bei mir genutzt wird. Also filterbar.

2. von mir initiiert:
Mein PC : beliebiger Port -> Fremder Pc : im Programm konfigurierter Port
Diese Art ist problematisch. Denn der fremde Port ist oft nicht der Standard-Port des Programms.

Lösungen

Filesharing als default

Hier steckt man einfach alles, was priorisiert werden soll in verschiedene Klassen. Der Rest landet dann in der default-Klasse.

Nachteil: Man ist sehr unflexibel weil man für das Priorisieren immer Ports braucht. Und z.b. FTP nimmt einfach zufällige Ports.

Filesharing in getrennte Klasse

Wenn man Filesharing in eine Klasse stecken möchte, dann gibt es ein Problem: Welche Ports nehmen?

Emule {{{4600-4700 als "client" Forwarding-Port als "server" }}} Bittorrent {{{6800-7000 als "client" Forwarding-Port als "server" }}}

Nachteil der Lösung ist, dass nicht alle die "client" Ports auf dem Standard belassen und sich damit Filesharing-Verkehr aus der Klasse rausschummeln kann. Denn die anderen sind ja ebenso frei in ihrer Forwarding-Port-Wahl.

weitere Ip-Adresse

Man erstellt in den TCP/IP Verbindungsoptionen eine zweite Ip-Adresse. Dann stellt die Filesharing Programme auf diese zweite IP ein. In QoS kann man dann bequem nach der IP filtern.

Derzeit bei Bittorrent mit Bittornado, Azureus und Shareaza möglich. Bei Emule gibt es einen Mod "BindIP", der realativ schwer zu beschaffen ist. Ich stelle in unregelmäßigen Abständen auf http://home.arcor.de/jojo4umod eine Version bereit. Die Einstellung ist dann unter Connections.

Vorteile:

Nachteile:

Das TOS-Bit setzen

Siehe <MPG.1b2fceca8e6db17f989682@news.spline.de> bzw. http://lists.spline.inf.fu-berlin.de/mailman/htdig/fli4l_filesharing/2004-June/006278.html. Der Download-Pfad hat sich allerdings geändert auf http://home.arcor.de/jojo4umod

Nachteile:

Wenn man Linux einsetzt kann iptables Pakete an Hand der user-id des Filesharingprozesses verarbeiten. Siehe: http://lists.spline.inf.fu-berlin.de/mailman/htdig/fli4l_opt/2002-November/001954.html.

Vorteile der beiden:

Nachteile der beiden:

Separater Rechner

Man stellt einfach einen weiteren Rechner hin. Dann kann man auch nach IP filtern.

Sourcecode ändern

Man ändert den Sourcecode in den Applikationen so, dass die zweite - von mir initiierte - Verbindungsart sich für den lokalen Port nur einem bestimmten Portrange bedient.

Praxis

Anwendungsbeispiele gibt es in den Beispielen unten.

Ändern von QOS im laufenden Betrieb

Fli4l 2.0.x

Wenn man nur die Attribute der Klassen ändern möchte, ist ein einfaches Umschreiben der rc.qos möglich. Der tc-Befehl "change" statt "add" ändert die Klassen. Joachim Kluge hat eine rc.qos umgeschrieben und stellt sie weiter unten bereit. Man muss sie einfach ausführen und die neue Konfiguration wird sofort übernommen. Vorher muss man natürlich die Umgebungsvariablen ändern. Entweder direkt auf der Konsole (z.B. QOS_CLASS_15_MAXBANDWIDTH=100kbit) oder über eine aktualisierte rc.cfg. Änderungen in einer rc.cfg werden wirksam, indem man sie mit ./rc.cfg ausführt.

Möchte man die Struktur der Klassen ändern, ist es am besten, QOS komplett neu zu starten. Hier das Script für Version 2.0.x von Oliver Walter aus der Mailingliste: 

-- aus
tc qdisc del dev "$QOS_LOCALNET_DEV" root
tc qdisc del dev "$QOS_INTERNET_DEV" root
ipchains -D input -i "$QOS_LOCALNET_DEV" -j qosout
ipchains -F qosout
ipchains -X qosout
rmmod cls_fw
rmmod cls_u32
rmmod sch_prio
rmmod sch_sfq
rmmod sch_htb

-- an
. /etc/rc.cfg
. /etc/rc.d/rc.qos

Fli4l 2.0.x mit OPT_QOS_05

Möchte man in dieser Version die QOS-Konfiguration anpassen, so ist es am einfachsten, eine neue rc.cfg mit mktgz zu generieren. Anstatt diese zusammen mit dem opt.tgz in den /boot-Ordner auf dem Router zu verschieben und diesen neuzustarten, kopiert man stattdessen nur die rc.cfg auf den laufenden Router in den /etc-Ordner und startet QOS mit folgender Eingabe neu: 

qos.sh restart

Da es hierbei unnötig ist, bei jeder kleinen Änderung mit mktgz.bat auch das opt.tgz neu einzupacken, habe ich mir eine Kopie von mktgz.bat geschnappt, dort die Zeilen fürs Packen auskommentiert und diese mkrc.bat benannt. Damit kann ich nun ganz schnell nur die rc.cfg neu generieren, wenn ich nur ein paar Änderungen für QOS testen möchte. mkrc.bat

Hinweis: Werden beim Neustarten von QOS Fehlermeldungen ausgegeben, oft in der Form Cannot find device "root", liegt es meistens daran, dass das rootfs voll ist. Mit dem Befehl df -h auf der Konsole lässt sich die Belegung des Dateisystems anzeigen. Hier ist das Dateisystem relevant, das an '/' eingehängt ist. Eine typische Ausgabe, wenn das rootfs vollgelaufen ist, könnte z.B. so aussehen:
ram  1.3MB   1.3MB   7.0kB   99 %    /       
Hier ist nur noch 7kb frei, viel zu wenig für eine einwandfreie Funktion des FLI4L.

Fli4l 2.1.x

Version 2.1 oder höher hat dafür ein Skript eingebaut. Die Konfiguration lässt sich u.a. durch Editieren von /var/run/qos.conf ändern. Einfach per E3 editieren oder per (Win)SCP rüberkopieren und das folgende Skript ausführen. 

/usr/local/bin/qos.sh stop
/usr/local/bin/qos.sh start
/usr/local/bin/qos.sh restart

Prüfen mit:
iptables -t mangle -L

Sollte leer sein nach einem Stop ...

Beispiel QOS

Bitte keine kompletten qos.txt hier reinschreiben, sonder sie mit AttachFile anhängen (siehe Fußbereich der Seite).

Beispiel von Joachim Kluge

Ich habe jetzt Fli4l Version 2.1.4 laufen. Nach dem Umschiffen einiger Klippen (aktuellen Patch runterladen, SSHD von 2.1.5 benutzen) bin ich sehr zufrieden.

Meine Versuche zu Downloadobergrenze zeigten: 

Knoppix von ftp.leo.org 
QoS-Downloadrate in Kibit / tatsächliche Downloadrate in KiB
ohne QoS / 92-93
710 / 85-88
730 / 90-91
730 / 90-91
740 / 91-92
750 / 92-93
768 / 92-93

Meine Versuche bezüglich welche Uploadrate optimal ist: 

Knoppix von ftp.leo.org sowie Mailupload
QoS-Uploadrate in Kibit / tatsächliche Downloadrate in KiB
115 / 90-92
120 / 90-92
122 / 90-91
124 / ~85
off / ~22

Aber grau ist alle Theorie :( Mit einem Bittorrent, einem Emule und 2 Downloads bekam ich erst 80-90KiB Download mit 105Kibit eingestellter Uploadrate.

Hier meine aktuelle qos.txt. Dort gibt es auch noch upload.png und download.png. Diese PNG zeigen die Klassensortierung im Fl4lqosadmin damit die Reihenfolge in der Konfiguration auch stimmt. Sie ist auf dem neuesten Stand was mein Qos-Wissen angeht. Die unrunden Ratenangaben kommen daher weil ich die Klassen auch im Fli4l unterscheiden möchte. Der Fli4lqosadmin lässt sich durch Ändern des Systemdatums zum Speichern überreden.

Features:

Ich habe jeder Klasse eine Prioriät gegeben damit z.b. Filesharing auch wirklich nur 12Kibit bekommt wenn andere auch was wollen. Filesharing bekomme ich durch 2 Dinge unter Kontrolle: Erstens habe ich die Portbereiche von Emule halbwegs eingegrenzt. Die "server" Regeln in der Filesharing Klasse müssen natürlich an das jeweilige Portforwarding angepasst werden. Und 2. habe ich Bittorrent und Shareaza auf meiner Netzwerkverbindung eine zweite Ip zugewiesen (.12/.13).

Bursts füge ich für die HTTP-Klassen und die POP3+NNTP Downloadklasse durch folgende Befehle hinzu: 

tc class change dev eth0 parent 10:1 classid 10:7 htb rate 153Kbit ceil 740Kbit burst 8000Kbit prio 1
tc class change dev eth0 parent 10:4 classid 10:9 htb rate 137Kbit ceil 740Kbit burst 1000Kbit prio 1
tc class change dev eth0 parent 10:4 classid 10:11 htb rate 139Kbit ceil 740Kbit burst 1000Kbit prio 1
tc class change dev ppp0 parent 20:13 classid 20:18 htb rate 13Kbit ceil 105Kbit burst 1000Kbit prio 1
tc class change dev ppp0 parent 20:13 classid 20:20 htb rate 12Kbit ceil 105Kbit burst 1000Kbit prio 1

-- JoachimKluge <qos AT jokluge DOT mailshell DOT com>

Beispiel von J. Dietrich Boock


Achtung Änderung!

Emule lässt sich mit den unten beschriebenen Filtern nicht gut kontrollieren. Ich habe verschiedenste Wege ausprobiert, und bin zu dem Schluss gekommen, das man den gesamten Traffic vom LAN in eine Klasse stecken sollte, die benachteiligt wird, und den zeitrelevanten Traffic in eine bevorzugte. Also z.B. Port 80, SSH, FTP, smtp usw.

Hier meine aktuelle qos.txt: 

//Beginn qos.txt//

OPT_QOS='yes'

QOS_INTERNET_DEV='ppp0' # Device über das Daten ins Internet übertragen werden
QOS_INTERNET_BAND_DOWN='767kbit' # Maximale Downstreambandbreite des Internet-Zugangs
QOS_INTERNET_BAND_UP='127kbit' # Maximale Upstreambandbreite des Internet-Zugangs
QOS_INTERNET_DEFAULT_DOWN='0' # Standardklasse für Down
QOS_INTERNET_DEFAULT_UP='2' # Standardklasse für Up
QOS_LOCALNET_DEV='eth0' # Device über das das lokale Netzwerk angebunden ist
QOS_LOCALNET_BAND='100mbit' # Maximale Übertragungsrate ins lokalen Netz (LAN)

QOS_CLASS_N='2'

QOS_CLASS_1_PARENT='0'
QOS_CLASS_1_MINBANDWIDTH='95kbit'
QOS_CLASS_1_MAXBANDWIDTH='127kbit'
QOS_CLASS_1_DIRECTION='up'
QOS_CLASS_1_PRIO='0'

QOS_CLASS_2_PARENT='0'
QOS_CLASS_2_MINBANDWIDTH='32kbit'
QOS_CLASS_2_MAXBANDWIDTH='79kbit'
QOS_CLASS_2_DIRECTION='up'
QOS_CLASS_2_PRIO='1'

QOS_FILTER_N='8'

QOS_FILTER_1_CLASS='1'
QOS_FILTER_1_IP=''
QOS_FILTER_1_PORT='80'
QOS_FILTER_1_TYPE='client'
QOS_FILTER_1_OPTION=''

QOS_FILTER_2_CLASS='1'
QOS_FILTER_2_IP=''
QOS_FILTER_2_PORT='443'
QOS_FILTER_2_TYPE='client'
QOS_FILTER_2_OPTION=''

QOS_FILTER_3_CLASS='1'
QOS_FILTER_3_IP=''
QOS_FILTER_3_PORT='53'
QOS_FILTER_3_TYPE='client'
QOS_FILTER_3_OPTION=''

QOS_FILTER_4_CLASS='1'
QOS_FILTER_4_IP=''
QOS_FILTER_4_PORT='53'
QOS_FILTER_4_TYPE='server'
QOS_FILTER_4_OPTION=''

QOS_FILTER_5_CLASS='1'
QOS_FILTER_5_IP=''
QOS_FILTER_5_PORT='25'
QOS_FILTER_5_TYPE='client'
QOS_FILTER_5_OPTION=''

QOS_FILTER_6_CLASS='1'
QOS_FILTER_6_IP=''
QOS_FILTER_6_PORT='25'
QOS_FILTER_6_TYPE='server'
QOS_FILTER_6_OPTION=''

QOS_FILTER_7_CLASS='1'
QOS_FILTER_7_IP=''
QOS_FILTER_7_PORT='110'
QOS_FILTER_7_TYPE='client'
QOS_FILTER_7_OPTION=''

QOS_FILTER_8_CLASS='1'
QOS_FILTER_8_IP=''
QOS_FILTER_8_PORT=''
QOS_FILTER_8_TYPE=''
QOS_FILTER_8_OPTION='ACK'

//Ende qos.txt//

Hier habe ich endlich den Emule unter Kontrolle. Ein Nachteil des qos mit Fli4l scheint mir bisher, das htb mit dem 2.2 er Kernel schlecht implementiert ist. Mit jeder Konfiguration wird das Netz langsamer sobald Emule sendet. mit opt.qos zwar schneller, jedoch nie so gut, wie wenn der Emule aus ist. Vor allem scheint Fli4l Probleme mit dem Aufbauen von Verbindungen zu haben. Leider bin ich hier noch nicht soweit vorgedrungen, das ich genau weis woran es liegt. Fakt ist, das es mit der Entwicklerversion von Fli4l, also einem 2.4 er Kernel besser läuft. Jedoch vorerst Finger weg davon.

Problem ist nach wie vor, das Emule nie nur über die definierten Ports läuft, also z.B. TCP 4662, und UDP 4672, sondern auch von irgendeinem freien lokalen Port zum TCP-Port der anderen USer, der durchaus z.B. 6675 sein könnte Verbindungen öffnet. Das hat man erst unter Kontrolle, wenn man standardmäßig ALLE Verbdindungen AUSSER den wichtigen (s.o.) in eine benachteiligte Standardklasse steckt.

Ende Änderung

Mein Problem war folgendes:

Ein Fli4l-Router, im Intranet dahinter zwei Rechner, auf einem, oder manchmal sogar beiden, läuft Emule. Wenn beide stark am Laden sind, so wird das Surfen arg langsam. Das liegt weniger an der Bandbreite, die für den Download zu Verfügung steht, sondern an der für den Upload. Denn die Datenpakete der ausgehenden Anfragen beim Surfen werden ja gleichrangig mit den Datenpaketen behandelt, wie die die vom Emule kommen und in die Welt geschickt werden.

Also dachte ich mir: Her mit QoS Nach einigen Fli4l-Versionswechseln, hunderten Re-Boots und einigen Kilo Tabak entschied ich mich dann mal das ganze richtig anzugehen, und siehe da: Ich surfe so schnell wie noch nie, und Emule arbeitet trotzdem sehr gut. Keine einbrechenden Downloads oder sowas etc.

Wie ich das geschafft habe: 

Fli4l Version 2.0.8
opt_qos_v0.4
Lokales Subnetz: 10.0.0.0/8 bzw. Subnetzmaske 255.0.0.0
768 KBit down
128 KBit up
eth0 zeigt zum Intranet
ppp0 zeigt zu Internet

Man muss erst folgendes über Emule wissen:

Um am Donkeynetz teilnehmen zu können, muss man selbst einen TCP-Port, und einen UDP-Port als Clientport angeben. In der Regel liegen diese zwischen 4660 und 4680. Ich verwende 4661 als TCP und 4672 als UDP. Diese zwei Ports muss man natürlich vom Fli4l aus an den eigenen Rechner im Intranet weiterleiten via Portforarding. Nun werden aber mitunter durch Emule/Edonke hunderte Verbindungen zu mir und von mir zu anderen aufgebaut. Dies kann ich mir anschauen mit netstat -na an der Windows-Eingabeaufforderung. Was man sieht sind ernorm viele Verbindungen von irgendeinem meiner Ports zum Port 4661 oder 4662 irgendwo "draußen". Diese Ports "draußen" sind die Clientports, die der jeweilige Emule-Benutzer bei sich eingegeben hat. Will ich also den Upload von mir aus restriktieren, so muss ich folgende Filter anlegen, die gleich den Portbereich 4660 bis 4680 abdecken: 

von allerechner.lokal.irgendeinport zu rechner.remote.4661:4680
von allerechner.lokal.4660:4680 zu rechner.remote.irgendeinport

Die zwei Filter hierfür sehen wie folgt aus: 

QOS_FILTER_2_CLASS='3'
QOS_FILTER_2_IP='10.0.0.0/8'
QOS_FILTER_2_PORT='4660:4680'
QOS_FILTER_2_TYPE='server'
QOS_FILTER_2_OPTION=''

QOS_FILTER_3_CLASS='3'
QOS_FILTER_3_IP='10.0.0.0/8'
QOS_FILTER_3_PORT='4660:4680'
QOS_FILTER_3_TYPE='client'
QOS_FILTER_3_OPTION=''

Diese Filter sind dann z.B. folgender Klasse zugewiesen: 

QOS_CLASS_3_PARENT='0'
QOS_CLASS_3_MINBANDWIDTH='8kbit'
QOS_CLASS_3_MAXBANDWIDTH='80kbit'
QOS_CLASS_3_DIRECTION='up'
QOS_CLASS_3_PRIO='3'

Jetzt will ich aber noch, das alle Verbindungen, die von irgendeinem meiner lokalen Ports zum Port 80 (WWW, also surfen) geöffnet und unterhalten werden bevorzugen. Der Filter hierzu sieht folgendermaßen aus: 

QOS_FILTER_1_CLASS='4'
QOS_FILTER_1_IP='10.0.0.0/8'
QOS_FILTER_1_PORT='80'
QOS_FILTER_1_TYPE='client'
QOS_FILTER_1_OPTION=''

Und die dazugehörige Klasse: 

QOS_CLASS_4_PARENT='0'
QOS_CLASS_4_MINBANDWIDTH='112kbit'
QOS_CLASS_4_MAXBANDWIDTH='128kbit'
QOS_CLASS_4_DIRECTION='up'
QOS_CLASS_4_PRIO='1'

Jetzt kommen aber noch die berühmten ACK-Packete ins Spiel. Wenn die nicht mit allerhöchster Priorität rausgeleitet werden, dann brechen Downloads die im Emule laufen schnell ab. Wichtig: Beim erstellen des Filters für die ACK-Packete ist, das keine IP, kein Port, Portrange, und kein Type angegeben ist. Sonst werden die beim Booten des Fli4l und damit bei Übergabe durch das Script rc.qos an ipchains und tc falsch eingerichtet. Auch wichtig ist, daß der Filter für ACK-Packete als letztes kommt. Warum wird ansatzweise im zweitem Kapitel erklärt.

Sieht so aus: 

QOS_FILTER_6_CLASS='5'
QOS_FILTER_6_IP=''
QOS_FILTER_6_PORT=''
QOS_FILTER_6_TYPE=''
QOS_FILTER_6_OPTION='ACK'

Dessen zugehörige Klasse: 

QOS_CLASS_5_PARENT='0'
QOS_CLASS_5_MINBANDWIDTH='1kbit'
QOS_CLASS_5_MAXBANDWIDTH='32kbit'
QOS_CLASS_5_DIRECTION='up'
QOS_CLASS_5_PRIO='0'

Jetzt habe ich noch eine Standardklasse eingerichtet, über die jeder UP-Datenverkehr geht, der nicht in die obigen Filter passt. Fürs erste, ich denke beim ersten Mal FTP-Upload werd ich mir da noch was anderes einfallen lassen. Die Frage ist das dann, ob das Sinn macht, denn surfen ist wesentlich zeitsensitiver als alles andere.

Klasse für Standard: 

QOS_CLASS_2_PARENT='0'
QOS_CLASS_2_MINBANDWIDTH='4kbit'
QOS_CLASS_2_MAXBANDWIDTH='128kbit'
QOS_CLASS_2_DIRECTION='up'
QOS_CLASS_2_PRIO='2'

Und noch eine Standardklasse für den Download. Die hab ich erstmal nur Pro-Forma eingerichtet. Später werde ich da vielleicht den Downwärtigen Strom noch aufteilen: 

QOS_CLASS_1_PARENT='0'
QOS_CLASS_1_MINBANDWIDTH='1kbit'
QOS_CLASS_1_MAXBANDWIDTH='768kbit'
QOS_CLASS_1_DIRECTION='down'
QOS_CLASS_1_PRIO='0'

Hier die qos.txt: boock.txt

<didiboo AT gmx DOT de>

Beispiel von DAU2001

Das Problem war, mit opt_qosV4s, opt_mldonkey, Squidproxy auf fli4l2.08 und mehrere Dienste im LAN und einen möglichst guten Ping in Onlinegames (z.B. Counterstrike und Battlefield42) zu erreichen.

Qos unterstüzt ja leider trafficshaping nicht für die Dienste direkt auf dem fli4l. Mit opt_qosv4s (Patch von Lutz) sollte es aber funktionieren.
(Funktioniert auch mit opt_qosv05a!) 

Fli4l Version 2.0.8 auf AMD K6-2 350mhz 128mb RAM
opt_qos_v0.4s
Lokales Subnetz: 192.168.0.0/24
768 KBit down
128 KBit up
eth0 zeigt zum Intranet
ppp0 zeigt zu Internet

Habe es durch folgenden Trick (aus der Newsgroup und den Howtos zumsammen gestellt) den Proxy und mldonkey "prioriesieren" können. 

OPT_QOS='yes'

QOS_INTERNET_DEV='ppp0' # DSL Gerät
QOS_INTERNET_BAND_DOWN='768kbit' # T-DSL Bandbreite Down
QOS_INTERNET_BAND_UP='122kbit' # T-DSL Bandbreite Up
QOS_INTERNET_DEFAULT_DOWN='5'
QOS_INTERNET_DEFAULT_UP='2'
QOS_LOCALNET_DEV='eth0'
QOS_LOCALNET_BAND='100Mbit'
...

Dabei wird durch qos erstmal alles in beschränkten Traffic Classen geleitet. Hierfür benötigt man folgende Classen: 

...
QOS_CLASS_N='6'

QOS_CLASS_1_PARENT='0' # upload LAN
QOS_CLASS_1_MINBANDWIDTH='86kbit'
QOS_CLASS_1_MAXBANDWIDTH='122kbit'
QOS_CLASS_1_DIRECTION='up'
QOS_CLASS_1_PRIO='1'
...

Die Standard "UPLOAD" Classe: 

...
QOS_CLASS_2_PARENT='0' # upload mldonkey@router
QOS_CLASS_2_MINBANDWIDTH='12kbit'
QOS_CLASS_2_MAXBANDWIDTH='70kbit'
QOS_CLASS_2_DIRECTION='up'
QOS_CLASS_2_PRIO='3'
...

Eine Classe für "wichtige Dienste" im LAN (Tipp kam aus Newsgroup von Lars Riehl) 

...
QOS_CLASS_3_PARENT='0' #up-Klasse für "wichtige" Dienste (ftp/http/mail/irc/icq/usw.)
QOS_CLASS_3_MINBANDWIDTH='12kbit'
QOS_CLASS_3_MAXBANDWIDTH='122kbit'
QOS_CLASS_3_DIRECTION='up'
QOS_CLASS_3_PRIO='2'
...

Die Classe für "schnelle" Downloads für Clients im LAN 

...
QOS_CLASS_4_PARENT='0' # download LAN
QOS_CLASS_4_MINBANDWIDTH='640kbit'
QOS_CLASS_4_MAXBANDWIDTH='768kbit'
QOS_CLASS_4_DIRECTION='down'
QOS_CLASS_4_PRIO='0'
...

Und hier beschränkt man nun, den "mldonkey" und alles andere direkt auf dem fli4l 

...
QOS_CLASS_5_PARENT='0' # download mldonkey@router
QOS_CLASS_5_MINBANDWIDTH='128kbit'
QOS_CLASS_5_MAXBANDWIDTH='768kbit'
QOS_CLASS_5_DIRECTION='down'
QOS_CLASS_5_PRIO='1'
...

Damit die Download Geschwindigkeitsraten nicht einbrechen, werden ACK Pakete bevorzugt: 

...
QOS_CLASS_6_PARENT='0' # ACK Klasse
QOS_CLASS_6_MINBANDWIDTH='12kbit'
QOS_CLASS_6_MAXBANDWIDTH='32kbit'
QOS_CLASS_6_DIRECTION='up'
QOS_CLASS_6_PRIO='0'
...

Durch diese Classen, kann jetzt wunderbar alles geregelt werden, in den Filtern.

Wichtigste Filter die sozusagen der "Trick" sind: 

...
QOS_FILTER_N='20'

QOS_FILTER_1_CLASS='1' # upload direkt auf fli4l für proxy bevorzugen
QOS_FILTER_1_IP='1.1.1.1'
QOS_FILTER_1_PORT='80'
QOS_FILTER_1_TYPE='server'
QOS_FILTER_1_OPTION=''
...

Hiermit wird alles, z.B. der opt_squid seine Anfragen, auf Port 80 (surfen)ins Internet bevorzugt. 

...
QOS_FILTER_2_CLASS='4' # download direkt auf fli4l für proxy bevorzugen
QOS_FILTER_2_IP='192.168.0.1'
QOS_FILTER_2_PORT='80'
QOS_FILTER_2_TYPE='client'
QOS_FILTER_2_OPTION=''
...

Und nun die Bandbreite einschränken, damit z.b. Filesharingprogramme, wie mldonkey, nicht die Leitung dicht machen. 

...
QOS_FILTER_3_CLASS='2' # rest vom fli4l in eingeschränkte klasse UPLOAD
QOS_FILTER_3_IP='192.168.0.1'
QOS_FILTER_3_PORT=''
QOS_FILTER_3_TYPE='server'
QOS_FILTER_3_OPTION=''

QOS_FILTER_4_CLASS='5' # rest vom fli4l in eingeschränkte klasse DOWNLOAD
QOS_FILTER_4_IP='192.168.0.1'
QOS_FILTER_4_PORT=''
QOS_FILTER_4_TYPE='client'
QOS_FILTER_4_OPTION=''
...

Die Filter sollten immer in der Reihenfolge gesetzt werden, in der sie abgearbeitet werden sollen. D.h. der Filter, der die "größten Einschränkungen" vornimmt, zuerst usw ...

Am Schluss kommt dann der Filter der sozusagen alles aus dem LAN was nicht in den anderen Filtern geregelt worden ist wieder bevorzugt und somit zu guter Performance beim surfen bringt. Und auch z.B. Tools wie Internetupdate von Antivir oder MSN Messenger sauber arbeiten lässt.( Ausser wenn es über Squidproxy geht, da kommt es immer zu leichten verzögerungen da ja Proxy zuerst seite selber chachen muss) 

...
QOS_FILTER_18_CLASS='1' # upload klasse 1 (unbegrenzt)
QOS_FILTER_18_IP='192.168.0.0/24' # für 192.168.0.x
QOS_FILTER_18_PORT=''
QOS_FILTER_18_TYPE=''
QOS_FILTER_18_OPTION=''

QOS_FILTER_19_CLASS='4' # download klasse 4 (unbegrenzt)
QOS_FILTER_19_IP='192.168.0.0/24' # für 192.168.0.x
QOS_FILTER_19_PORT=''
QOS_FILTER_19_TYPE=''
QOS_FILTER_19_OPTION=''
...

Und damit natürlich die Downloadsraten zum LAN hin nicht einbrechen der "ACK Filter" 

...
QOS_FILTER_20_CLASS='6'
QOS_FILTER_20_IP=''
QOS_FILTER_20_PORT=''
QOS_FILTER_20_TYPE=''
QOS_FILTER_20_OPTION='ACK'

Das waren die grundsätzlichen wichtigen Filter, der Rest ist dann je nach Bedürfnis anzupassen.

Alle Filter aufzuzeigen und zu Erklären ist mir im Moment zuviel Schreibarbeit, die ich gerade an Zeit nicht habe, deshalb schaut euch, doch einfach, die Beispielqos mit den Restlichen Filtern, im Anhang hier an: dau2001qos.txt Und den htb Patch nicht vergessen (siehe oben) oder diese rc.qos ins fli4l-2.0.8\opt\etc\rc.d\ kopieren. Dann funktioniert diese opt_qosv04s mit fli4l2.08 wunderbar

Gruss DAU2001 <DAU2001 AT gmx DOT net> ICQ: 97987436

Hinweis: Da durch das opt_qos die NICs sehr gut ausgelastet werden, kommt es bei NICs basierend auf Realtek8139 Chipsatz manchmal zu Aussetzern, im Zusammenhang mit Fli4l2.08. Das liegt an dem Treibermodul 8319too, welches in der alten Version im Fli4l2.08 beiliegt. Den Fehler behebt man, durch Deaktiveren der "ACPI Funktionen" im BIOS (meist unter PNP/PCI Settings zu finden) des Routers. 

P.S. zum Abschluss, bitte beim Editieren der Seite vorsichtiger sein! Habe gerade 1 Std gebraucht
um die Seite wieder aufzuräumen.

OffeneFrage: Ist es möglich, sowohl für QOS_INTERNET_DEV als auch für QOS_LOCALNET_DEV 'eth0' anzugeben? Hintergrund: Der Internet-Zugang erfolgt über einen anderen Router, der im gleichen LAN hängt, fli4l mit opt_QoS soll nur zum Bandbreitenmanagement eingesetzt werden (kein Masquerading).

Auch eine offene Frage: Was passiert eigentlich mit eth0, wenn ich im Router 2 Netzwerkkarten fürs LAN habe ich aber QOS nur an eine binde (QOS_LOCALNET_DEV='eth1')? Ist es sinnvoll, die Bandbreiten zu splitten (z.B. QOS_INTERNET_BAND_DOWN='512kbit' QOS_INTERNET_BAND_UP='64kbit') und somit dem Netz an eth1 generell nur die halbe Bandbreite zur Verfügung stellen? Eine Bridge, wie hier schon mehrfach vorgeschlagen, wollte ich eigentlich nicht machen, die Netze sollten getrennt bleiben.

Zur Offenen Frage 1: Bandbreitenmanagement ohne Masquerading wird schlecht gehen, weil man, um die Bandbreite zu managen, erreichen muss, dass alle Pakete durch den fli4l laufen. Damit die nicht verwechselt werden, braucht man aber Masquerading. Ich würde vorschlagen, den fli4l überall als Gateway einzutragen und auf dem fli4l den Internet-Router als Gateway einzutragen. Damit würde das Masquerading auf dem fli4l ablaufen. Portforwardings müsste man entweder durch den fli4l durchleiten oder sie gehen am QOS vorbei.

fli4l/OptQos (zuletzt geändert am 2007-12-23 22:46:56 durch localhost)