Re(4): TC unter Linux

TC unter Linux (28 Beiträge, 309 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi, Folks!

Heute bin mal ich mit Fragen dran.... Wie einige wissen, habe ich im Haus 64KBit-ISDN, und mehrere parallel arbeitende PC's... Und nein, es /gibt/ einfach nix schnelleres in meiner Ortschaft 30km von Wien (außer Sat up- und down, und das ist mir mit 1GB p.m. zu teuer, außerdem ist die Latenzzeit wohl schlimmer als bei ISDN

).

Mir schwebt jetzt folgendes vor:
tc einzusetzen um zu priorisieren... Nachdem ISDN ja 64bit up- und down hat (und ich up keinen Streß habe), hatte ich folgende Idee:

HTB qdisc einsetzen (scheint mir simpel und clever) um mal outgoing grob wie folgt zu konfigurieren:

tc qdisc add dev ippp0 root handle 1: htb default 30

Maximale Priorität für Interaktiv(ssh)

tc class add dev ippp0 parent 1: classid 1:10 htb rate 50 kbit ceil 64kbit priority 10

Mittlere Priorität für Arbeitsserver-https und POP-Arbeit

tc class add dev ippp0 parent 1: classid 1:20 htb rate 12 kbit ceil 64kbit priority 10

tc class add dev ippp0 parent 1:20 classid 1:21 htb rate 11 kbit ceil 64kbit

tc class add dev ippp0 parent 1:20 classid 1:22 htb rate 1 kbit ceil 64kbit

normale Priorität für rest

tc qdisc add dev ippp0 parent 1: classid 1:30 htb rate 1 kbit ceil 64kbit priority 10

Die schlechteste Priorität - nur wenn NIX anderes upstream anliegt - Erklärung folgt

tc qdisc add dev ippp0 parent 1: classid 1:50 htb rate 1 kbit ceil 64kbit priority 50

Dann hätte ich
alles mit dport ssh in 1:10 gelegt,
alles mit https zum Arbeitsserver in die 1:21,
ssh zum Arbeitsserver und pop/smtp zu Arbeitsmailserver in 1:22
und der Rest würde in 1:30 kommen.

Nachdem ich ja Probs downstream habe, war die Idee wie folgt:
Bei denen, die Asynchron sind, findet man öfters die Empfehlung, daß sie die SYN/ACK und ACK höchst priorisieren, damit sie i.d.F. ihren Downstream immer voll bekommen. Meine Idee war nun, alle
ACKs, die nicht zum Arbeitsserver oder den Mail-Servern gehen, automatisch via iptables getagged werden - und dann in die allerletzte Queue kommen. Dadurch müßten die Downloads "außerhalb" der "ArbeitsIPs" langsamer kommen - weil sie seltener ACKs bekommen und daher drosseln müßten.

Ist das eine verfolgbare Idee, oder stellt sich klein-gepeinigter_aon_neukunde wieder mal alles zu einfach vor ?

Re: TC unter Linux (MidiFan am 14.11.2005, 19:51:22)

Re(2): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 19:52:03)

Re(3): TC unter Linux (MidiFan am 14.11.2005, 19:53:34)

Re(4): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 20:05:53)

Re(5): TC unter Linux (MidiFan am 14.11.2005, 20:24:30)

Re(6): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 20:29:48)

Re(7): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 20:30:37)

Re(8): TC unter Linux (MidiFan am 14.11.2005, 21:03:07)

Re(7): TC unter Linux (MidiFan am 14.11.2005, 21:00:31)

Re(7): TC unter Linux (patos am 14.11.2005, 21:20:09)

Re(8): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 21:50:37)

Re(9): TC unter Linux (patos am 14.11.2005, 21:53:29)

Ach ja, ergänzende noob-Frage: (gepeinigter_aon_neukunde am 14.11.2005, 19:56:00)

Ach ja, eine iptables-DAU-Frage habe ich noch: (gepeinigter_aon_neukunde am 14.11.2005, 19:58:12)

Re: Ach ja, eine iptables-DAU-Frage habe ich noch: (mIstA am 17.11.2005, 09:53:47)

Re: TC unter Linux (patos am 14.11.2005, 20:10:54)

Re(2): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 20:16:16)

Re(3): TC unter Linux (patos am 14.11.2005, 20:20:51)

Re(4): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 20:27:22)

Re(5): TC unter Linux (MidiFan am 14.11.2005, 21:04:39)

Re(6): TC unter Linux (gepeinigter_aon_neukunde am 14.11.2005, 21:09:45)

Re(5): TC unter Linux (patos am 14.11.2005, 21:18:35)

Re: TC unter Linux (mIstA am 17.11.2005, 09:26:33)

Re(2): TC unter Linux (gepeinigter_aon_neukunde am 17.11.2005, 09:46:29)

Re(3): TC unter Linux (mIstA am 17.11.2005, 10:22:43)

Natürlich krieg ich kein richtiges QoS hin mit der Bandbreite und ohne eingriff beim Provider...

Ach ja, noch eine blöde Frage:

ISDN bekommt bei mir default MTU (ich vermute im Rahmen der chap-Anmeldung) von 1500 - also dasselbe wie bei ethernet.

Aus dem Bauch raus kommt mir eine MTU von 1500 bei 64KBit extrem hoch vor...

Meine Überlegung war wie folgt:
Die kleinsten MTU's die ich gesehen habe, waren bei AFAIK 536 (Modems vor langer Zeit)... Also könnte es ja Sinn machen, wenn ich die MTU auf viel. 768 reduziere ? Natürlich steigt dann mein Netzwerk-Overhead bei größeren Paketen an - andererseits könnte ich ja doch Interaktivität gewinnen.

Meine größte Sorge dabei ist, daß diverse Clients (Windows) ziemlich sicher bei ihren Paketen das "Don't Fragment"-Bit setzen... Und evtl. keine gute PMTU-Discovery machen.

Ich könnte also:
1.) Bei den Clients fix eine MTU von 768 eintragen - ungut weil Papi's rechner
2.) via iptables folgende Regel bauen:
- wenn ein Paket von eth0 kommt
- und das DF-Bit gesetzt hat
- dann lösche /PREROUTING/ das DF-Bit - und füge es /POSTROUTING/ wieder an
3.) Auf MTU-Modifikationen wegen möglicher Probleme verzichten - und stattdessen via iptables fix postroutung auf ippp0 bei SYN-Paketen eine MSS von 768 anbieten.

Wenn ich es richtig verstanden habe, würde mir dann die Gegenstelle - auf tcp-Verbindungen [udp kann ich mal ignorieren, da kommt bei mir nix so großes her] - nie mehr als 768 bytes auf einmal senden - so als ob ich die MTU gesetzt hätte... Nun denn, dann wird's aber auch nicht gegen das DF-Bit helfen, oder ?

ARGH!
Vor ewigkeiten hab' ich mich mal mit MTU's herumgespielt (wg. TR und ETH im selben Netz)... Dunkel erinner ich mich, daß das die Hölle war... Was huhn ?

Script... (gepeinigter_aon_neukunde am 19.11.2005, 22:21:38)

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung