| "Autor" |
Shaping mit tc |
|
|
|
geschrieben am: 28.05.2004 um 17:37 Uhr
|
|
Liebe Liebenden,
mein Traffic-Shaping bereitet mir Kopfschmerzen. Laut iptables -v -n -L werden die Pakete so getaggt, wie ich mir das wünsche -- insbesondere der Eimer 29 wird korrekt getaggt.
Trotzdem: Sobald dort viele Pakete durchlaufen, werden die anderen Eimer (insbesondere die Eimer 21/22, wo der http-Traffic reinkommt) unerträglich langsam, und das trotz der entsprechend gesetzten Priorität und dem Limit von 8kbit.
Wo liegt mein Denkfehler? Ist POSTROUTING der falsche Aufhänger für den Sprung in die SHAPING-Chain?
(zitat)#!/bin/bash
TC=/usr/sbin/tc
DEV=ppp0
MAX=192
TCCA="$TC class add dev $DEV"
TCQA="$TC qdisc add dev $DEV"
# remove old entries
$TC qdisc del dev $DEV root
# root qdisc
$TCQA root handle 1: htb default 26
# general limit
$TCCA parent 1: classid 1:1 htb rate ${MAX}kbit
# create 5 classes of MAX/5 to MAX each
$TCCA parent 1:1 classid 1:20 htb rate $[MAX/5]kbit ceil ${MAX}kbit prio 0
$TCCA parent 1:1 classid 1:21 htb rate $[MAX/5]kbit ceil ${MAX}kbit prio 1
$TCCA parent 1:1 classid 1:22 htb rate $[MAX/5]kbit ceil ${MAX}kbit prio 2
$TCCA parent 1:1 classid 1:23 htb rate $[MAX/5]kbit ceil ${MAX}kbit prio 3
$TCCA parent 1:1 classid 1:24 htb rate $[MAX/5]kbit ceil ${MAX}kbit prio 4
$TCCA parent 1:1 classid 1:29 htb rate 8kbit ceil 16kbit prio 5
# leaf classes each get a sfq qdisc attached to them
$TCQA parent 1:20 handle 20: sfq perturb 10
$TCQA parent 1:21 handle 21: sfq perturb 10
$TCQA parent 1:22 handle 22: sfq perturb 10
$TCQA parent 1:23 handle 23: sfq perturb 10
$TCQA parent 1:24 handle 24: sfq perturb 10
$TCQA parent 1:29 handle 29: sfq perturb 10
# show what we've done
$TC class show dev $DEV
IPT="/usr/sbin/iptables -v -t mangle"
IPS="$IPT -A SHAPING"
# create table
$IPT -N SHAPING
$IPT -F SHAPING
$IPT -Z SHAPING
$IPT -I POSTROUTING -o $DEV -j SHAPING
$IPS -p tcp --sport 22 -j MARK --set-mark 20 # ssh
$IPS -p tcp --dport 22 -j MARK --set-mark 20 # ssh
$IPS -p tcp --sport 80 -j MARK --set-mark 21 # http
$IPS -p tcp --sport 8080 -j MARK --set-mark 22 # http
$IPS -p tcp --dport 80 -j MARK --set-mark 21 # http
$IPS -p tcp --dport 8080 -j MARK --set-mark 22 # http
$IPS -p tcp --sport 25 -j MARK --set-mark 23 # smtp
$IPS -p tcp --dport 25 -j MARK --set-mark 23 # smtp
$IPS -m owner --uid-owner daniel -j MARK --set-mark 29 # choke
$IPS -p tcp --sport 5001 -j MARK --set-mark 29 # choke
$IPS -m mark --mark 0 -j MARK --set-mark 24 # mark any unmarked
(/zitat)
|
|
|
|
|
|
|
Top
|
| "Autor" |
|
|
|
|
geschrieben am: 28.05.2004 um 19:31 Uhr
|
|
vielleicht mal die problem-eimer auf die gleiche Priorität setzen wie der eimer29 sie besitzt...? Oder den eimer29 an erster stelle setzen...?
hmmm...war nur so'ne Idee, weil das shaping unter linux nicht so mein Ding ist...*gg*
*prof*
schöne pfingsten wünsch ich dir... :-) |
 |
|
|
|
|
|
|
Top
|
| "Autor" |
|
|
|
|
geschrieben am: 30.05.2004 um 21:32 Uhr
|
|
Das mit "Eimer 29 = Problem-Eimer" scheint zu klappen. Mit iptables werden die zu drosselnden Bereiche (sport: 5001 und uid: 500) als "29" getaggt und landen auch im entsprechenden Eimer.
Die Reihenfolge sollte (bei tc) eigentlich egal sein, da die Klassen in einer Baumstruktur angelegt werden. Bei iptables sollte (und tut es) mit dieser Reihenfolge funktionieren, da die ersten paar Regeln (ssh/http) bei diesen Paketen noch nicht greifen.
Da ich größere Verständnisprobleme mit den Eimern und QDiscs habe, vermute ich den Fehler eigentlich eher dort. :/
Trotzdem danke. ;)
|
|
|
|
|
|
|
Top
|
