CBQ probleem

[Appesteijn]

Hoi,
Ik probeer om CBQ goed aan de praat te krijgen, zodat ik beter de bandbreedte kan verdelen. Nu lukt dat goed voor het downloaden, ik kan gebruikers cappen op elke gewenste snelheid. Het vreemde is echter dan het upstream niet lukt. Al het verkeer loopt via 1 server met 2 netwerkkaarten.

De configfile van CBQ ziet er zo uit: (voor het upload gebeuren)

DEVICE=eth1,500Kbit,50Kbit
RATE=80Kbit
WEIGHT=10Kbit
PRIO=8
RULE=192.168.100.10

En voor het downloaden:

DEVICE=eth0,100Mbit,10Mbit
RATE=4Mbit
WEIGHT=400Kbit
PRIO=6
RULE=192.168.100.10

Ik heb het even snel via speedtest geprobeerd en de download wordt keurig op 400 KB/s gecapped, maar de upload blijft op 50 KB/s (maximaal) lopen. Wie weet wat ik fout doe?

[Blaasvis]

ik heb nog nooit gehoord van een config file voor CBQ, naar mijn weten waren het een aantal rules.
Dus kijk wat voor eens script je distro er voor gebruikt of schrijf er zelf een.

ik ga er natuurlijk wel van uit dat je de traffic control howto hebt door gespit!
http://tldp.org/HOWTO/Traffic-Control-HOWTO/index.html

[Appesteijn]

Tuurlijk heb ik die doorgespit, anders was het me downstream nooit gelukt. De syntax van de configfile heb ik uit een cbq-init document. Er staat ook duidelijk dat alleen de versturende netwerkkaart de snelheid af kan remmen, eth1 is dus mijn externe. Maar het lijkt er dus op dat daar iets mis gaat, het ip blijft gewoon uppen met 50 KB/s.

[Arnout]

Appesteijn schreef op 11 februari 2004 @ 11:06:
Tuurlijk heb ik die doorgespit, anders was het me downstream nooit gelukt.

Vraagje tussendoor (als dat mag), heb je de IMQ patch daarvoor gedaan? Zover ik kan zien zit dit niet in Linux 2.6.x, en de patch op die site is voor 2.4.x. Welke kernel draai je?

[Appesteijn]

De IMQ patch zegt me eigenlijk niets. Ik gebruik e-smith met kernel 2.4. Ik ben nu bezig om met cbq-init-v0.7.3 wat verder te komen. het ziet erg redelijk uit, maar weer alleen de download.

[AlterEgo]

Appesteijn schreef op 11 februari 2004 @ 11:06:
Tuurlijk heb ik die doorgespit, anders was het me downstream nooit gelukt.

Volgens mij is CBQ geschikt voor het shapen van upload, en niet van download.
Ik twijfel een beetje aan je uitspraak hierboven.

code:

# The configuration says that we will control traffic on 10Mbit ethernet
# device eth0 and the traffic going to network 192.168.1.0 will be
# processed with priority 5 and shaped to rate of 128Kbit.
#
# Note that you can control outgoing traffic only. If you want to control
# traffic in both directions, you must set up CBQ for both interfaces.
#
# Consider the following example:
#
#                    +---------+      192.168.1.1
# BACKBONE -----eth0-|  linux  |-eth1------*-[client]
#                    +---------+
#
# Imagine you want to shape traffic from backbone to the client to 28Kbit
# and traffic in the opposite direction to 128Kbit. You need to setup CBQ
# on both eth0 and eth1 interfaces, thus you need two config files:
#

stukje uit het script

[Arnout]

AlterEgo schreef op 11 februari 2004 @ 12:15:
[...]


Volgens mij is CBQ geschikt voor het shapen van upload, en niet van download.
Ik twijfel een beetje aan je uitspraak hierboven.
[...]

Zou wel kunnen, als je de upload capped van je interne (LAN) interface. Dat is ook wat hij doet volgens mij, dus in die zin kun je de download limiteren door ervoor te zorgen dat je interne interface qua upload gecapped is.

Toch?

[Appesteijn]

Via dat bestand (cbq-init) heb ik het eerst ook geprobeerd. 2 files aangemaakt: cbq-4000.inet-user en cbq-0100.user-inet met de instellingen hierboven. Als ik nu "cbq start" intik dan worden deze 2 files (in /etc/sysconfig/cbq/) geladen en kan ik downloaden met 4Mbit (of minder als ik er bv 1Mbit van maak) dat lukt perfect. Alleen de upload dus niet, die blijft op 500Kbit.
Ik heb nu ook dat script (cbq-init.v0.7.3) gebruikt en als ik dan "./cbq.init-v0.7.3 compile" doe dan zie ik dat er met tc 2 classes/qdisc's worden aangemaakt met de juiste info (dus 4Mbit op eth0 en 80Kbit op eth1) en dat er wordt gefilterd op ip 192.168.100.10 maar na "./cbq.init-v0.7.3 start" kan ik nog steeds ftp-uppen met 50KB en ook speedtest zegt 50 KB/s.

@MetHod:

Ja idd, je kan alleen het uitgaande verkeer cappen, aangezien er 2 netwerkkaarten zijn, kun je van hun allebei de upstream cappen. De upstream van eth1 is van client->inet en de upstream van eth0 is van inet->client

[ Voor 16% gewijzigd door Appesteijn op 11-02-2004 12:32 ]

[Appesteijn]

Iemand een idee wat er fout gaat?

[pierre-oord]

Jah, lukte mij oo niet. Enige wat werkt is pakketen met iptables markeren. @ liev modus, hier een voorbeeldje:

code:

iptables -A POSTROUTING --out-interface eth0 --table mangle --source 10.0.1.1 -j MARK --set-mark 2

Dan via je script die marks opgeven. En volgende keer handig als je de locatie van het script vermeld. http://sourceforge.net/projects/htbinit/

Ow, da's trouwen een beter project als die cbq ofzo, check dat maar eens.. wel erop gebaseerd.

[ Voor 12% gewijzigd door pierre-oord op 12-02-2004 18:01 ]

[Appesteijn]

Ok ik heb naar HTB gekeken, maar die module zit niet in mijn kernel. Ook heb ik verder gekeken naar cbq.init. Dit lijkt te werken, als ik ./tc -s class show dev eth1 doe dan laat hij alle classes zien waaronder 1 met max bandwidth en 1 met 100kb bandwidth. Maar alleen de root node heeft traffic, de rest dus niet.
Als ik nu ./tc -s filter show dev eth1 doe, dan laat hij zien dat er gefiltert wordt naar: "match c0a800000/ffff0000 at 12" als het goed is zou dit 192.168.100.0/16 moeten zijn. (Ik heb even het hele domein genomen om te testen) Blijkbaar matched niets hierop en stopt hij dus niets in de langzame cbq-class.
Ik heb nu de download naar de client weggehaald en draai nu alleen met een file in de hoop de upstream te cappen. Eth1 is mijn interface naar het inet, dit is de inhoud:
DEVICE=eth1,512Kbit,50Kbit
RATE=100Kbit
WEIGHT=10Kbit
PEAK=128Kbit
PRIO=6
RULE=192.168.100.0/16,

Nu zat ik te denken, ik gebruik NAT, zou het kunnen dat de ip's naar buiten al omgezet zijn en CBQ.init dus het externe ip voorbij ziet komen ipv het interne?

edit.

Ja hoor, als ik mijn externe ip gebruik, dan capped hij hem keurig op 12 KB/s. Maar dan is dat dus voor iedereen. Moet ik dan in mijn firewall die tagging gaan gebruiken?

/edit.

[ Voor 10% gewijzigd door Appesteijn op 12-02-2004 22:21 ]

[Verwijderd]

pierre-oord schreef op 12 februari 2004 @ 18:00:
Ow, da's trouwen een beter project als die cbq ofzo, check dat maar eens.. wel erop gebaseerd.

Wie bepaalt dat

Het idee achter het doen van dergelijke uitspraken is, dat je ze wel even fundeert op een forum

@Appesteijn: je geeft zelf al het antwoord

Tenzij je een routertje voor die server kunt hangen, zal een oplossing in de vorm van packet marking middels iptables de makkelijkste oplossing zijn.

Als je dat helemaal niet ziet zitten, zou je eventuel kunnen proberen om een extra ip aan de uitgaande interface te hangen. Vervolgens dat ip als gateway te gebruiken voor je server. Je uitgaande verkeer cappen op die interface en alle verkeer dat vanauit je lan komt richting die interface doorsturen naar de externe interface.

In theorie moet dat werken en als ik me niet vergis heb ik dat ook wel eens een keer gedaan in een ver verleden

[ Voor 34% gewijzigd door Verwijderd op 12-02-2004 22:31 ]

[Appesteijn]

thx, mijn modem kan ook als router fungeren, dus dat ga ik morgen maar eens proberen.

edit:


De router stellen we maar even uit, dat is niet zo'n mooie oplossing.

Ik wilde dus de packets gaan marken. Kan ik de bovenstaande regel van Pierre-oord gewoon toevoegen aan mijn firewall? Of moet ik in de bestaande regels de 'mark' meegeven? Het eerst heb ik al geprobeerd (Wel ip-adres vervangen natuurlijk) en dat werkte niet. Is er een commando waarmee ik kan kijken of er wel packets worden gemarked?

[ Voor 72% gewijzigd door Appesteijn op 13-02-2004 12:17 ]

[om3ega]

Ik heb dus precies hetzelfde probleem

Situatie schets

code:

                                   eth0 - wifi netwerk (moet gecapped worden)
eth2 (internet) ---[Redhat 9.0]--- eth1 - lokaal netwerk (uncapped)

eth0 : 10.30.83.0/24
eth1 : 192.168.0.0/24

Download achter NAT kon ik prima indammen , maar de upload niet. Ik dacht slim te zijn door de pakketjes te marken..

code:

iptables -A POSTROUTING --out-interface eth2 --table mangle -j MARK --set-mark 2

En ik was dolblij , het werkte met CQB .. alleen omdat ik dus geen destination had opgegeven werd mijn eth1 netwerk ook gecapped in de upload

Maar als ik braaf invul

code:

iptables -A POSTROUTING --out-interface eth2 --table mangle --source 10.30.83.0/24 -j MARK --set-mark 2

Dan gebeurt er helemaal niets?

Ook als ik het IP adres van de betreffende client er in zet heeft het geen resultaat.
Dus zonder source werkt het met al het verkeer. Maar hoe kan ik zorgen dat alleen eth0's upload gecapped wordt?

[Appesteijn]

Kun je niet als source eth0 aangeven? Ik heb het niet verder meer geprobeerd, want de sociale-bandbreedte-begrenzer (even vragen dus) werkte nu wel.

Ik kan met nog wel herrinneren dat ik het wel even aan de praat heb gehad. Via het marken en dan filteren daarop.

edit

Je kan met ./tc -s filter show dev eth2 kijken wa er in welke class wordt gestopt.

/edit

[ Voor 17% gewijzigd door Appesteijn op 28-04-2004 10:35 ]

[om3ega]

Ik heb wel geprobeerd als source eth0 aan te geven , maar dat resulteerde in een error of een niet werkende situatie (kan het me even niet meer herinneren) maar ik zal het nog wel even proberen vanavond.