cbq_init

[kabufzk]

hallo!

ich tüftle schon seit stunden an einem traffic-shaping problem. hab schon das halbe internet abgegrast, aber nix gefunden. vielleicht könnt ihr mir helfen.

ich verwende eine linux-box, um eine 2mbit-leitung in einem netzwerk zu sharen (iptables, nat). des weiteren läuft ein transparenter squid-proxy zwecks content-filtering (nur für http). um die leitung bei einem download bzw. upload nicht zu verstopfen verwende ich das cbq_init scipt (http://freshmeat.net/projects/cbq.init). das funktioniert auch bestens für clients hinter der box, aber auf der box selbst nicht.

also wenn ich z.B einen download per ftp (von einem client im netz) mache dann shaped das cbq_init diesen wunderbar nach meinen vorgaben. wenn ich allerdings per http (proxy) etwas lade, dann funktioniert zwar das shaping von der box zum client, aber der squid auf der box selbst ladet weiter mit full-speed runter und verstopft die leitung erst recht.

kann ich cbq_init nicht verwenden um auch den download auf der box selbst zu shapen?? oder funktioniert es nur in der FORWARD-Chain? habe folgende confing versucht (analog zu der für die clients):

für download:

DEVICE=eth0,100mbit,10mbit
RATE=1700kbit
WEIGHT=170
PRIO=4
RULE=122.123.124.125

für upload:

DEVICE=eth0,100mbit,10mbit
RATE=1700kbit
WEIGHT=170
PRIO=4
RULE=122.123.124.125,

eth0 ist das externe interface mit der öffentlichen ip.

hat jemand eine idee wie ich das lösen könnte? bin echt verzweifelt

danke und lg,
kabufzk

[max_payne]

poste bitte mal ifconfig

//mein verdacht: es wird zwar der traffic über die eth0-schnittstelle geshaped, nicht aber der des servers selbst.

[kabufzk]

hallo!

eth0 Protokoll:Ethernet Hardware Adresse 00:10:4B:DC:95:62
inet Adresse:122.123.124.125 Bcast:122.123.124.129 Maske:255.255.255.248
inet6 Adresse: fe80::210:4bff:fedc:9562/64 Gültigkeitsbereich:Verbind ung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:38550820 errors:0 dropped:0 overruns:0 frame:0
TX packets:31310121 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:3083906280 (2.8 GiB) TX bytes:1352680801 (1.2 GiB)
Interrupt:10 Basisadresse:0x6800

eth1 Protokoll:Ethernet Hardware Adresse 00:50:BA:13:AB:AE
inet Adresse:10.0.1.1 Bcast:10.0.1.255 Maske:255.255.255.0
inet6 Adresse: fe80::250:baff:fe13:abae/64 Gültigkeitsbereich:Verbind ung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40658389 errors:0 dropped:0 overruns:0 frame:0
TX packets:27090248 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:3535777503 (3.2 GiB) TX bytes:1414483549 (1.3 GiB)
Interrupt:9 Basisadresse:0x6c00

eth0 ist wie gesagt die externe schnittstelle mit der öffentlichen ip. zu den clients wird über eth1 geshaped, den server kann ich aber logischerweise nur über eth0 shapen. den upload shaped er auch, aber mit dem download komme ich nicht zurecht. ich habe jetzt auch mal versucht die pakete mit iptables zu markieren und dann zu shapen, aber es funktioniert wieder nur mit dem upload.

iptables -A OUTPUT -t mangle -o eth0 -j MARK --set-mark 5
iptables -A INPUT -t mangle -i eth0 -j MARK --set-mark 4

die cbq-config habe ich dann so geändert:

DEVICE=eth0,100mbit,10mbit
RATE=1700kbit
WEIGHT=170
PRIO=4
MARK=4 (bzw 5)

wie gesagt, den upload vom server aus shaped er schön brav, aber den download nicht. ???

[jutta]

afaik ist es gar nicht so trivial, den download zu shapen, denn dazu muesste man ja die devices im upstream beeinflussen koennen.

[kabufzk]

das ist von der überlegung her schon richtig jutta, aber beim forwarding funktioniert es doch auch. ich shape einfach die bandbreite über eth1 und der downstream wird automatisch langsamer - ohne dass ich vorgelagerte devices beeinflusse.

wenn es so wäre wie du sagst, dann könnte ich zwar die bandbreite für meine clients beschränken, aber der server würde noch immer mit full-speed runterladen und einfach nur langsamer verteilen. das tut er aber definitiv nicht. die ganze verbindung wird verlangsamt. also denke ich mir, dass es mit dem download direkt auf der box genauso funktionieren muss.

tcp/ip implementiert ja eine flusskontrolle und deshalb regelt auch die gegenstelle ihren upload runter, wenn der client nicht so schnell downloaden kann. sonst würden zu viele pakete verworfen werden. siehe dazu:

http://de.wikipedia.org/wiki/Datenflusskontrolle

[max_payne]

Am einfachsten wäre es wahrscheinlich den Proxy über eine Virtuelle Netzwerkkarte zu leiten, und diese dann zu shapen.

[kabufzk]

hmmmm...nicht sehr elegant, aber wenn sonst nix hilft. danke für die antworten!

grüße,
kabufzk

[max_payne]

Was mir noch eingefallen ist:
Ein Proxy ist ja dazu gut, dass er die Daten zwischenspeichert, und dann mit fullspeed weitergibt.
Deshalb müsstest du evtl. nach einer Einstellungmöglichkeit im Proxyserver selbst suchen.

Gib auf jeden Fall Rückmeldung, obs klappt oder nicht.

[kabufzk]

es gibt bei squid delay pools. aber damit scheint die tcp/ip flusskontrolle nicht richtig zu funktionieren. wenn ich z.b mit squid den download der clients auf knapp unter die leitungsgeschwindigkeit beschränke, dann ladet der squid noch immer zu schnell runter. erst wenn ich mehr als 50kb wegnehme, dann bleibt die leitung halbwegs frei.

beim shaping mittels cbq genügt es wenn ich wenige kb wegnehme um die leitung nicht zu verstopfen.

grüße,
kabufzk

[lindian]

würd das auch wie max_payne machen... einfach das ganze nochmals über ne virtuelle nic routen...
der BB verlust dürfte eigentlich nur minimalst sein

[kabufzk]

und es geht doch!

nach längerem probieren habe ich es doch noch mit dem kernel-integrierten shaping geschafft. mit dem cbq_init skript habe ich es nicht hinbekommen, aber manuell mit dem kommando tc (welches cbq_init auch verwendet):

Code: Alles auswählen

tc qdisc add dev eth0 handle ffff: ingress

tc filter add dev eth0 parent ffff: protocol ip prio 5 u32 match ip src 0.0.0.0/0 police rate 1750 burst 5k drop flowid :1


der erste befehl legt eine qdisc für das zu shapende device an (in meinem fall eth0), der zweite legt einen filter für die qdisc an, der den gesamten ip-traffic auf 1750kbit beschränkt - und zwar auch den downstream auf der box selbst. man kann natürlich auch nach protokoll, ports, etc. filtern. hoffe das hilft jemandem.

danke für die anregungen!

grüße,
kabufzk