frank-w
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
Hallo,
ich möchte gerne bei meinem Linux-Router VoIP-Verkehr priorisieren. aktuell habe ich "Best Effort", also nur reines routing ohne Prio. in den bisherigen Anleitungen, die ich dazu gefunden habe (u.a. LinuxMagazin) werden 5 oder mehr Prioritätsklassen (mit verschiedenen Filtertypen) aufgebaut...ist das wirklich nötig für ein einfaches privates LAN? prinzipiell würden mir aktuell 2 Klassen reichen (priorisiert [VoIP {SIP/RTP},ICMP] oder nicht [Rest]). diese Priorisierung würde ich gerne rein mit IP-Tables Markierung realisierung (ohne Einbindung von u32 oder L7). ist das theoretisch richtig/sinnvoll? oder habe ich irgendetwas nicht bedacht? kann mich vielleicht jemand leiten, sowas aufzubauen? Gruß Frank
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7659
|
Ausgehenden Traffic kannst du so priorisieren mit der PRIO qdisc. Standardmäßig richtet die sich einfach nach dem TCP/IP ToS Feld. ( https://en.wikipedia.org/wiki/Type_of_service ) Wenn deine VoIP Clients das setzen (und Torrent-Clients das nicht auf hohe Priorität setzen) dann brauchst du da fast schon nichts weiter machen. Aber bei PRIO kann man auch eine eigene priomap/eigene Filter. Wenn dann mehrere Pakete zum rausschicken da sind, kommt immer das mit der höchsten Priorität zuerst... Die Probleme fangen an, wenn deine Leitung in beide Richtungen dicht ist: du hast keinen direkten Einfluss darauf, was dir geschickt wird. Wenn du da runteregeln musst (durch droppen von Paketen und der Hoffnung, dass die Gegenstelle einlenkt und langsamer schickt) wird es kompliziert. Und je mehr Queues du hast (z.B. SFQ) bringt das dann auch eine Verzögerung bei den Paketen mit sich. Was bei Downloads egal ist, aber bei VoIP und Spielen eben irgendwann auffällt. Wenn PRIO nicht reicht dann mal einen Blick auf HFSC werfen. Leider schwer gute Dokumentation dazu zu finden, QoS ist eine Wissenschaft für sich. Ich habe mich früher mal damit beschäftigt, da waren 5 Leute in der Studenten-WG am 768er/1024er (weniger als 1MBit-) DSL und eine simple SSH-Shell hatte 5-10 Sekunden Lag. Heute nehme ich das einfach so wie es von der Fritzbox kommt. Die macht auf jeden Fall mehr als nur ein einfaches PRIO, wenn da jemand telefoniert merkt man sofort wie alles andere massiv runtergeregelt wird. (DSL ist hier halt auch "nur" 16MBit). Schnellere Leitungen bekommt man ja wirklich nur mit der entsprechenden Anzahl Nutzer und/oder eben Steam/Filesharing/... dicht.
|
frank-w
(Themenstarter)
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
Hallo,
danke für deine Antwort. Ich habe halt keine Fritzbox sondern eine Selbstbau-Lösung, und die wird aktuell (nur Firewall+statisches routing) nicht auf das TOS eingehen, selbst wenn es vom Client kommt. Weiterhin habe ich aktuell auch nur einen 16Mbit (AnnexB)-Anschluss und will mein Netzwerk schonmal Voip-fähig machen, bevor der Provider auf Voip umstellt und kein sauber funktionierendes Telefon mehr habe (außer Handy halt). deswegen würde ich gerne an meiner Linux-Kiste Voip (und auch ssh, icmp) priorisieren, damit diese immer durch den geringen Upload durchgehen, selbst wenn ein größerer Upload läuft (mache häufiger RSYNC-Backup vom NAS auf ein Remote-NAS). würden die 2 Klassen (+ die Hauptklasse darüber) und eine reine Port-Priorisierung (5060,51xx,22) + Type icmp reichen? Gruß Frank
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7659
|
frank-w schrieb: würden die 2 Klassen (+ die Hauptklasse darüber) und eine reine Port-Priorisierung (5060,51xx,22) + Type icmp reichen?
Wenn es dir primär um den Upload geht, würde ich da auf jeden Fall mit der PRIO anfangen und die komplizierteren Lösungen erst, wenn sich das als nicht ausreichend herausstellen sollte. ToS kannst du auch per iptables setzen. Wie das bei mir mal aussah kannst du hier sehen: https://github.com/frostschutz/FairNAT (vorsicht, das Zeug ist über 10 Jahre alt). Viele QoS Scripte produzieren bestenfalls nur zufällige Ergebnisse.
|
frank-w
(Themenstarter)
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
Danke dir
Ich möchte nur ungern ein fertiges script nehmen und möchte gerne verstehen, was ich da mache ☺
deswegen die Frage nach jemanden, der mich leitet (keine fertige lösung).
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: Zähle...
Wohnort: Sachsen
|
frank-w schrieb: Danke dir
Ich möchte nur ungern ein fertiges script nehmen und möchte gerne verstehen, was ich da mache ☺
deswegen die Frage nach jemanden, der mich leitet (keine fertige lösung).
Ich würde dir empfehlen dieses Howto durchzuarbeiten. Dort geht es nicht nur um QoS und Priorisierung, aber es bietet einen recht umfangreichen Überblick über Traffic-Kontrolle unter Linux. Diesbezüglich ist es am wichtigsten die ganzen Grundbegriffe und Konzepte von qdiscs etc. zu verstehen.
|
frank-w
(Themenstarter)
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
Dieses HowTo habe ich auch schon gefunden. Ich habe aber Probleme das genau zu verstehen (auch weil es auf englisch ist...). Ich bin zwar in Englisch recht fit, aber das Thema ist recht speziell und von daher tue ich mir da schwer. Ich habe das Tutorial gefunden: https://systemausfall.org/wikis/howto/QoSHowTo wenn da soweit alles richtig ist, würde ich mich daran halten.
Wenn ich mit IPTables ein Paket markiere (-j MARK --set-mark 1) kann ich aber mit dem Paket noch weiterarbeiten (Verarbeitung beendet? ggf. anderen Marker setzen), oder? bei normalen (Firewall-) Regeln ist für das Paket ja nach dem ersten match Schluss. müsste ich das dann vor meinen Firewall-Regeln anwenden oder durchlaufen die (nicht geblockten) Pakete die mangle-Tabelle nochmal bzw. danach?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7659
|
bei normalen (Firewall-) Regeln ist für das Paket ja nach dem ersten match Schluss.
Eigentlich nur bei Endmarkern wie DROP / ACCEPT / ... Du kannst eben nur ein Mark setzen, setzt du ein anderes ist das alte weg.
Ich habe das Tutorial gefunden: https://systemausfall.org/wikis/howto/QoSHowTo
Das ist nicht so toll... also da kannst du vielleicht mal eine Idee von den Befehlen bekommen aber HTB wird dort eigentlich falsch verwendet. (htb prio ist was anderes als die PRIO qdisc die umgekehrt auch wieder nichts mit HTB zu tun hat)
|
frank-w
(Themenstarter)
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
ich müsste den marker also setzen bevor ich accept nutze,richtig? Mhm..das tutorial war überschaubar und verständlich erklärt ☹ und hat die Technik verwendet die ich nutzen will (tagging via iptables ohne u32 o.ä.) Kannst du mit die fehler korrigieren oder ist das zu aufwendig?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7659
|
HTB solltest du eigentlich gar nicht benutzen, wenns um Priorisierung geht. Der prio Parameter bei HTB bestimmt primär wer von überschüssiger Bandbreite zuerst einen Anteil bekommt. Wenn dann aber jede Unterklasse die gleiche rate wie Parent hat (wie in deinem Howto), gibts keine überschüssige Bandbreite in dem Sinne... was HTB dann genau macht ist schwer zu verstehen. Das war mal hier ganz gut beschrieben http://www.docum.org/docum.org/docs/htb/
If you add more then 1 subclass, make sure that the sum of the rates of the child class is equal or smaller then the rate of the parent.
Auf der Seite kannst du dir auch mal das Diagramm anschauen http://www.docum.org/docum.org/kptd/ Da wird dargestellt wie die Pakete die einzelnen Schichten durchlaufen und das müsste heute immer noch so zutreffen. Hier habe ich ein Beispiel mit PRIO gefunden: https://www.voip-info.org/wiki/view/QoS+with+Linux+using+PRIO+and+HTB (Den HTB und SFQ Anhang kann man da auch erstmal ignorieren.) Dort gibts PRIO mit 2 Bändern, priomap 1 1 1 (alles ins zweite Band), und dann ein Filter für VoIP ins erste Band. VoIP kommt da immer zuerst dran. Und das wäre die Idee die ich auch zuerst ausprobieren würde...
|
frank-w
(Themenstarter)
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
wenn ich das richtig verstehe auf der Seite http://www.docum.org/docum.org/docs/htb/: | tc qdisc add dev ppp0 root handle 1: htb default 10 # damit lege ich die root-QDISK = Oberste Ebene der Verarbeitung an, jeder Traffic geht nach 1:10, wenn nicht anders gehandled
#geht von Upload-Kapazität von 100kbit/s aus, rate=reserviert, ceil=maximum (wenn mehr frei ist bis uploadlimit), burst (wenn mehr geht im Upload?)??
tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps burst 2k # die erste Klasse nimmt sich die volle Bandbreite = Upload-Geschwindigkeit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps burst 2k prio 0 # defaultklasse oben mit geringerer (= priorisierter???) prio für die Standard-Packete / ungetagged
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps burst 2k prio 1 # hier würde vermutlich Voip landen mit Prio 1
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps burst 2k # Traffic der aufgeschoben wird = nicht so wichtig, daher ohne Prio
|
brauche ich diese Priomap? irgendwie irritiert mich das dass die default-Klasse 1:10 die höchste Prio hat...normal sollte doch voip höchste prio haben und ggf. icmp+ssh+syn-Pakete, der rest sollte imho geringere Prio haben, damit es zuerst herausgeschickt wird beim 2. Beispiel htb weglassen ist imho nicht so einfach, da es weiter hinten verwendet wird
oder wirklich alles weglassen von
$TC qdisc add dev ${DEV} parent 1:1 handle 11: pfifo
bis
$TC qdisc add dev ${DEV} parent 12:12 handle 1212: sfq perturb 10
?
dann werden keine garantierten Bandbreiten o.ä. definiert und die Handles 10-12 fehlen dann auch, die weiter unten verwendet werden das Thema komplett in englisch zu verstehen ist schwere Kost..gibts da keine deutsche Anleitung? das Marking via iptables würde ich am liebsten postrouting auf ppp0 ansetzen (also wirklich kurz bevor die Pakete rausgehen, und alle anderen Firewall-Regeln gegriffen haben)...komme ich da ran? von den ersten Befehlen sehe ich nicht viel Unterschied zu dem HowTo von Systemausfall.org...bei beiden ist htb mit in der ersten Definition (qdisc) dabei. wo besteht der genaue Unterschied? Was sollte anders sein?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7659
|
frank-w schrieb: brauche ich diese Priomap?
Bei HTB gibt es keine priomap. 😉 Und bei HTB würde ich auch prio 0 / 1 für den Anfang mal weglassen und nur die rate so einstellen wie die einzelnen Klassen das brauchen. Bei VoIP (wieviele Telefonate gleichzeitig) müsste sich das ja halbwegs ausrechnen lassen.
dann werden keine garantierten Bandbreiten o.ä. definiert
Braucht man (ausgehend) auch nicht unbedingt.
von den ersten Befehlen sehe ich nicht viel Unterschied zu dem HowTo von Systemausfall.org...
Die rate ist in deinem Beispiel jetzt richtig (parent hat 100kbps, kinder haben 30+10+60 = auch 100kbps).
das Marking via iptables würde ich am liebsten postrouting auf ppp0 ansetzen (also wirklich kurz bevor die Pakete rausgehen, und alle anderen Firewall-Regeln gegriffen haben)...komme ich da ran?
sollte klappen, postrouting mangle
|
frank-w
(Themenstarter)
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
das Beispiel ist 1:1 aus dem HTB-Tutorial...nur mit meinen Kommentaren... OK, versuche ich das mal mit meinen Werten:
SPEC habe ich einfach mal die 3. Warteschlange genannt (bzw. die Bandbreite), da ich noch nicht weiß wozu ich die nutze/brauche 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | UPLINK=1100
DOWNLINK=9400 #der vollständigkeit halber
PRIO=110 #VOIP ~100kBit / SSH
SPEC=60
DEF=$(( $DOWNLINK-$SPEC-$PRIO ))
OUTDEV=ppp0
#delete root-qdisk (upload/download)
tc qdisc del dev ${OUTDEV} root
tc qdisc del dev ${OUTDEV} ingress
tc qdisc add dev ${OUTDEV} root handle 1: htb default 10
tc class add dev ${OUTDEV} parent 1: classid 1:1 htb rate ${UPLINK}kbps ceil ${UPLINK}kbps burst 2k # die erste Klasse nimmt sich die volle Bandbreite = Upload-Geschwindigkeit
tc class add dev ${OUTDEV} parent 1:1 classid 1:10 htb rate ${DEF}kbps ceil ${UPLINK}kbps burst 2k prio 0 # defaultklasse oben mit geringerer (= priorisierter???) prio für die Standard-Packete / ungetagged
tc class add dev ${OUTDEV} parent 1:1 classid 1:11 htb rate ${PRIO}kbps ceil ${UPLINK}kbps burst 2k prio 1 # hier würde vermutlich Voip landen mit Prio 1
tc class add dev ${OUTDEV} parent 1:1 classid 1:12 htb rate ${SPEC}kbps ceil ${UPLINK}kbps burst 2k # Traffic der aufgeschoben wird = nicht so wichtig, daher ohne Prio
|
beispiel fürs taggen:
| #so ist das forwarding definiert für den VOIP-Adapter
#${ipt} -t nat -A PREROUTING -p udp --dport 5160 -j DNAT --to-destination 192.168.0.9
#${ipt} -t nat -A PREROUTING -p udp --dport 5104:5120 -j DNAT --to-destination 192.168.0.9
#weis jetzt natürlich nicht, ob die dports Richtung Inet die gleichen sind...
#egal, eigentlich reicht die IP
iptables -t mangle -A POSTROUTING -o $OUTDEV -p udp -s 192.168.0.9 -j MARK --set-mark 1
#iptables -t mangle -A POSTROUTING -o $OUTDEV -p udp --dport 5104:5120 -j MARK --set-mark 1
|
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7659
|
$PIO → $PRIO
filter fehlen noch.
|
frank-w
(Themenstarter)
Anmeldungsdatum: 30. September 2008
Beiträge: 408
|
PIO ausgebessert, Filter (habe aktuell nur Mark=1 ⇒ "handle 1"):
tc filter add dev $OUTDEV parent 1: protocol ip handle 1 fw flowid 1:11 richtig?
|