CBQ op basis van poorten?

[Red devil]

Paar mensen hier die veel downloaden via kazaa, op zich geen probleem maar dat ze hele films binnensleuren en die dan niet bekijken omdat ie toch niet leuk en/of niet draait, dat stoort me wel.

Ook in deze topic werd het genoemd:
[topic=174427]

Kun je op basis van poorten ook CBQ toepassen???

[duronbug]

Daar ben ik ook al mee aan het experimenteren geweest. Om bijvoorbeeld mijn upload af te knijpen naar bijvoorbeeld 8k.
Maar het probleem met CBQ is dan, als die 8K dan eenmaal vol is gaat het downloaden ook verschrikkelijk traag, gaat ook ongeveeer naar 8k.
Dus je hebt nog eerder last van die verschrikkelijk trage download met een volle upload.
Kan er niet achter komen waardoor dit wordt veroorzaakt. Waarschijnlijk maken de upload en de download gebruik van dezelfde queue.

[Red devil]

Op dinsdag 27 november 2001 14:34 schreef duronbug het volgende:
Daar ben ik ook al mee aan het experimenteren geweest. Om bijvoorbeeld mijn upload af te knijpen naar bijvoorbeeld 8k.
Maar het probleem met CBQ is dan, als die 8K dan eenmaal vol is gaat het downloaden ook verschrikkelijk traag, gaat ook ongeveeer naar 8k.
Dus je hebt nog eerder last van die verschrikkelijk trage download met een volle upload.
Kan er niet achter komen waardoor dit wordt veroorzaakt. Waarschijnlijk maken de upload en de download gebruik van dezelfde queue.

Ik heb zelf nu ook een goed werkend CBQ gebeuren op de server. Alleen die is gebaseerd op IP nummer. Dat werkt trouwens voortreffelijk.
Sommige mensen kunnnen met 485 KB/s downloaden, sommige weer met max 240 KB/s en een paar maar met 16KB/s

Dat werkt voortreffelijk! Maar als iemand met een upload van 8KB/s gaat uploaden en tegelijkertijd wil downloaden dan zal die laatste erg langzaam ja. Is dat niet logisch? Omdat er domweg geen upload meer over is om te downloaden?

Ik wil dus nu per poort gaan verdelen. Dus dat de server ziet, HEE, dit is poort 1214 (van kazaa) ipv normalitair 240 KB/s mag diegene nu maar 10 KB/s downloaden.
Snap je?

[Verwijderd]

Leuk om weer eens een CBQ probleempje te zien

CBQ op basis van poorten is heel goed mogelijk (sterker nog ik doe het hier).

Je moet in de match regels gewoon het ip vervangen door een poort. Bijvoorbeeld zo:

match regel met ip:

code:

tc filter add dev eth1 parent 10:0 protocol ip prio 25 u32 \
match ip dst 192.168.0.2 flowid 10:100

match regel met poort:

code:

tc filter add dev eth1 parent 10:0 protocol ip prio 25 u32 \
match ip sport 1214 0xffff flowid 10:100

De 0xffff is verplicht

Meerdere matches zijn ook mogelijk. Denk aan een source ip met poort en bijv. alleen een destination ip:

code:

tc filter add dev eth1 parent 10:0 protocol ip prio 25 u32 \
match ip src 192.168.0.2 match ip sport 1214 0xffff \
match ip dst 192.168.0.80 flowid 10:100

Succes iig

Op dinsdag 27 november 2001 14:34 schreef duronbug het volgende:
Daar ben ik ook al mee aan het experimenteren geweest. Om bijvoorbeeld mijn upload af te knijpen naar bijvoorbeeld 8k.
Maar het probleem met CBQ is dan, als die 8K dan eenmaal vol is gaat het downloaden ook verschrikkelijk traag, gaat ook ongeveeer naar 8k.
Dus je hebt nog eerder last van die verschrikkelijk trage download met een volle upload.
Kan er niet achter komen waardoor dit wordt veroorzaakt. Waarschijnlijk maken de upload en de download gebruik van dezelfde queue.

Ze gaan sowieso niet over dezelfde queue. Alleen uitgaand verkeer gaat over een queue (uitgaande interface).
Ofwel je kan binnekomd verkeer van internet queuen op je interne nic en intern verkeer, dat naar inet toegaat queuen op je internet nic.
Heb je wel boundend statements gebruikt, zodat er niet geborrowed gaat worden van andere classes etc?

[edit]
0xfffff in 0xffff veranderd

[duronbug]

Yep heb alles al wel geprobeerd. Ook veel gelezen over CBQ.
Het zal wel komen doordat er te weinig ruimte/capaciteit over is voor ACK's bij het downloaden. Mischien is het wel goed op te lossen door goed te filteren en het verkeer daardoor goed te scheiden en de ACK's voorrang te geven. Zal nog wel eens een keer mee aan het klooien gaan.

[Red devil]

thanx Nelske, ik hoopte al dat je deze topic zou tegenkomen

eerst even de class aangemaakt:

tc class add dev eth1 parent 10:200 classid 10:250 cbq bandwidth 10Mbit rate \ 200Kbit allot 1514 weight 50Kbit prio 6 maxburst 20 avpkt 1000

das dus 25 KB/s max voor kazaa

Daarna

tc filter add dev eth1 parent 10:0 protocol ip prio 25 u32 match ip sport 6996 0xfffff flowid 10:250

Aangezien ik het eerst op mezelf ga testen heb ik eerst poort 6996 geknepen (das een poort van een ftp waar ik bij kan die erg snel is)
That should be it toch? Echter ik krijg deze melding:

Illegal "match"

... ik zal nog even kijken of er nog iets is aangemaakt.

tc -s class show dev eth1 levert dit op:

class cbq 10:250 parent 10:200 rate 200Kbit prio 6
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 890520 undertime 0

De class is dus wel aangemaakt?

[Verwijderd]

Scusi, moet dus 0xffff zijn.
Stom van me

[Red devil]

Op dinsdag 27 november 2001 16:07 schreef nelske het volgende:
Scusi, moet dus 0xffff zijn.
Stom van me

toppertje
net even veranderd en nu geen foutmelding.

Echter ik ben nu aan het pompen en ik heb nog steeds 400 KB/s, das zeker niet verkeerd maar ik wil graag 25 KB/s zien

Als ik tc -s class show dev eth1 doe verandert er helemaal niks aan de die 250 class....

komt misschien omdat mijn ip in de 100 class zit?

[Verwijderd]

Naar alle waarschijnlijkheid wel.
Bij mijn weten pakt hij altijd de eerste de beste match die hij tegenkomt.

Maar het is een beetje lastig beoordelen zo op afstand.
Je kan even proberen om de nieuwe klasse omhoog te halen en er zo dus voor te zorgen dat deze komt voor de klasse waarin hij nu valt. (als je begrijpt wat ik bedoel; het is nogal vaag omschreven )

[Red devil]

Op dinsdag 27 november 2001 16:17 schreef nelske het volgende:
Naar alle waarschijnlijkheid wel.
Bij mijn weten pakt hij altijd de eerste de beste match die hij tegenkomt.

Maar het is een beetje lastig beoordelen zo op afstand.
Je kan even proberen om de nieuwe klasse omhoog te halen en er zo dus voor te zorgen dat deze komt voor de klasse waarin hij nu valt. (als je begrijpt wat ik bedoel; het is nogal vaag omschreven )

whehe ik snapte denk ik wel wat je bedoelde

heb nu eerst class 103 aangemaakt die als class gaat dienen voor die poort.

Daarna mijn eigen 102 class

Daarna IP;s koppelen, en die poort class wordt eerst gekoppeld. Daarna pas mijn IP aan class 102.

Class 103 wordt netjes aangemaakt. Maar er gebeurt niks in, maw, er gaat geen data doorheen. (ik heb hem trouwens wel bounded gemaakt)

Hmmm

[wouzer]

Op dinsdag 27 november 2001 15:27 schreef nelske het volgende:

code:

tc filter add dev eth1 parent 10:0 protocol ip prio 25 u32 \
match ip dst 192.168.0.2 flowid 10:100

Toch grappig waarom jij wel op ip kan matchen en ik het via handle's aan masq'd packages moet doen omdat het anders dus onmogelijk gaat werken.

Care to show the rest of your shaping script?

[Verwijderd]

/me gebruikt cbq-init script (in Debian heet hij shaper) om te shapen en dus ook alleen voor upload; ofwel een "match ip src"
Dan zit je dus ook niet me masq'd packages.

Ik weet wel dat ik toen ik het nog met de hand inklopte ook zat te klooien met dst ip's omdat die gemasqued worden.
Je kan dan eventueel gewoon packets gaan marken zoals ook in de Adv Routing HOWTO staat en op basis daarvan gaan shapen.

/me wil best wel al z'n cbq-init files posten hoor, maar ik denk niet dat je daar veel aan hebt

Op dinsdag 27 november 2001 16:23 schreef Red devil het volgende:
Class 103 wordt netjes aangemaakt. Maar er gebeurt niks in, maw, er gaat geen data doorheen. (ik heb hem trouwens wel bounded gemaakt)

Hmmm

Over welke klasse gaat het verkeer dan nu?

[Red devil]

Op dinsdag 27 november 2001 17:22 schreef nelske het volgende:

Over welke klasse gaat het verkeer dan nu?

Nou over mijn eigen 101 entry. Mijn PC heeft een eigen class genaamd 101, net even 15 meg gedownload ongeveer.

oud

10823628576

nieuw

10838461583

verschil is idd ong 15 meg...
Hij pakt dus gewoon de class die perfect bij de IP matched?

[duronbug]

Nog ff een vraagje:

Hoe kun je onderscheid maken tussen upload die wordt veroorzaakt door download en upload van bijvoorbeeld Kazaa of edonkey.
Je zou zeggen filteren op verschillende poorten, maar nu is bij edonkey de download en de upload over dezelfde poort als ik het goed heb.
Weet 1 van jullie hier een oplossing voor ?