Iemand ervaring met shapen van Incoming Traffic?

[Red devil]

Ik krijg straks kabelmodem en wil de traffic van bepaalde clients lekker shapen!

Ik gebruik hiervoor Rshaper
te vinden op: http://freshmeat.net/projects/rshaper/

Hiervoor moest ik de source van mijn 3c59x (3com) kaart veranderen, dat is gelukt, althans make modules / modules_install gaf geen foutmeldingen.

Echter het werkt nog niet, eigenlijk zou ik het liefst door willen gaan met Rshaper maar als er makkelijker manieren zijn om naar Rome te komen dan sta ik daar ook open voor!

Anyone??
Alvast bedankt!

[Red devil]

Nobody??

[Verwijderd]

Ik had eerlijk gezegd hier nog nooit van gehoord. Het klinkt wel handig, hoewel ik het voor mezelf niet echt nodig vind. Waarom zou je internet traffic willen afkappen na een bepaald limiet? Zoals Freshmeat.net al duidelijk aangeeft is het handig voor ISPs. Ik weet niet hoeveel programma's hiervoor te verkrijgen zijn, maar ik heb het nog nooit eerder gezien, dus ik zou zeggen nog even doorzetten als het zonodig moet

[Verwijderd]

Dit soort dingen zitten al standaard in de kernel. Is alleen een kwestie van meebakken erin.

Het heet o.a. Class Based Queuing (CBQ).
Ik zou zeggen lees de advandced routing HOWTO eens door

[edit]
Oeps ik zie nu pas dat het om incomming traffic gaat en niet om outgoing traffic.
Bovenstaand verhaal geld namelijk voor outgoing traffic.
Ik zou zo niet weten waarom je incomming trafic zou willen beperken, terwijl dit in de meeste programma's (lees servers zoals ftp-server, www-server etc) al kan

[Red devil]

Op donderdag 01 maart 2001 18:05 schreef nelske het volgende:
Dit soort dingen zitten al standaard in de kernel. Is alleen een kwestie van meebakken erin.

Het heet o.a. Class Based Queuing (CBQ).
Ik zou zeggen lees de advandced routing HOWTO eens door

[edit]
Oeps ik zie nu pas dat het om incomming traffic gaat en niet om outgoing traffic.
Bovenstaand verhaal geld namelijk voor outgoing traffic.
Ik zou zo niet weten waarom je incomming trafic zou willen beperken, terwijl dit in de meeste programma's (lees servers zoals ftp-server, www-server etc) al kan

10 punten!
Just to get things straight, ik beheer straks een kabelmodem internet verbinding die wordt gedeeld door 10 man (ja 10 man)
Daarom wil ik bepaalde personen die anders te veel trekken even afknijpen.

Het programma werkt trouwens! Ik had het verkeerd gelezen!! Het werkt namelijk op de upload van je clients en niet de download!!
Gisteren even getest, je kunt bijv gewoon instellen dat je maar met 2 k kunt uploaden naar de server.

ff getest en ik kreeg dit:
met 1500 bytes upload kon je nog met 100k/s downloaden
met 1000 bytes upload nog 70k/s

70k/s is te veel!
Aangezien ik BOFH ben en volgens @home 16.1 k download breedband is wil ik ook nog eens de download traffic shapen,
als ik het goed begrijp kan dat met dat CBQ??
Dan zal ik dat nog even beter bekijken!
Alvast bedankt!

[Verwijderd]

Zoek even bij FreshMeat op 'traffic shaping', kom je interessante dingen tegen.

Schijnt trouwens dat in kernel 2.4 daar hele aardige dingen voor ingebakken zitten.

[Red devil]

Op vrijdag 02 maart 2001 12:53 schreef TCT_Nexus het volgende:
Zoek even bij FreshMeat op 'traffic shaping', kom je interessante dingen tegen.

Schijnt trouwens dat in kernel 2.4 daar hele aardige dingen voor ingebakken zitten.

Thanx, maar ik draai nog met 2.2.18 en daar zit ik nog wel even aan vast.
Versvlees had ik al ontdekt, en 1 van die progjes (zie mijn 1e posting) gebruik ik dus nu ook, alleen die is alleen bedoeld voor het shapen van de upload van de users.
Nu nog de download, ik heb al flink wat paperassen uitgeprint over CBQ (ofzoiets)
dat schijnt standaard in kernel 2.2 te zitten. Daar ga ik even verder mee werken.

[Red devil]

Op donderdag 01 maart 2001 18:05 schreef nelske het volgende:Oeps ik zie nu pas dat het om incomming traffic gaat en niet om outgoing traffic.
Bovenstaand verhaal geld namelijk voor outgoing traffic.
Ik zou zo niet weten waarom je incomming trafic zou willen beperken, terwijl dit in de meeste programma's (lees servers zoals ftp-server, www-server etc) al kan

Nou ik snap wat je bedoelt, ik zou dus bijv mijn interne ftp/www server kunnen shapen maar als mensen via mijn server via ipchains het internet opgaan dan geldt die beperking natuurlijk niet meer... dan kunnen ze alsnog met >100k/s downloaden terwijl ik juist die stroom wil beperken, de upload lukt al, nu nog de download.. Maar zoals je al zei, CBQ moet dat kunnen dus dat zal ik dan maar even installeren.

[Verwijderd]

Je zou een aantal aliassen aan kunnen maken voor je interne netwerkkaart.

Dus verschillende IP nummers die allemaal uitkomen op dezelfde interne netwerkkaart.

Zeg dat je 3 virtuele IP-adressen aanmaakt op de intenrne netwerkkaart (zeg eth1): 192.168.1.1 192.168.2.1 192.168.3.1.

Deze laat je via CBQ "shapen".
Ofwel je verbind CBQ met eth1

tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit cell 8 avpkt 1000 mpu 64

Vervolgens maak je 3 klassen aan die je allemaal verschillende downloadsnelheids limieten geeft. Bijvoorbeeld
192.168.1.1 -> 10 Mbit
192.168.2.1 -> 5 Mbit
192.168.3.1 -> 1 Mbit

tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 10Mbit rate 10MBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21

tc class add dev eth1 parent 1:0 classid 1:2 cbq bandwidth 10Mbit rate 5Mbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21

tc class add dev eth1 parent 1:0 classid 1:3 cbq bandwidth 10Mbit rate 1Mbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21

Nu nog het onderscheid maken tussen de verschillende trafic-stromen:

tc filter add dev eth1 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 1

tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.1.1 flowid 1:1

tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.2.1 flowid 1:2

tc filter add dev eth1 parent 1:0 prio 5 u32 match ip src 192.168.3.1 flowid 1:3

Als je deze 3 IP-adressen nu als gateway adressen voor je interne clients gebruikt, betekent dat, dat hun download-snelheid wordt beperkt door bovenstaande opgegeven snelheden.

Het is dus een kwestie, van het aanpassen van de DHCP-server voor de verschillende clients die je hebt. Ze krijgen afhankelijk van in welke klasse ze zitten een bepaald gateway-IP toegewezen.
Let erop dat je dus ook je Ipchains regels zal moeten veranderen aan de bovenstaande IP's.

Dit alles komt trouwens in aangepaste vorm uit bovenstaande HOWTO.
Laat ff weten of het een beetje lukt

[wouzer]

Upload verkeer kun je wel inperken met trafficshapen. Zie onderstaande voorbeeld. Maar download verkeer beperken wordt wel moeilijk omdat je geen controle hebt over wat andere hosts naar JOU sturen. Voorbeeldje: Je kunt wel zelf bepalen hoeveel brieven je via de post verstuurt echter hoeveel brieven je krijgt heb je niet in de hand.

Voorbeeld upload beperking:

Uit mijn filewall script:

#!/bin/sh

CLIENTS="2 3 4 5 6 7"

## IP Masquerading ########

for I in $CLIENTS; do

$IPCHAINSBIN -A forward -j MASQ -s 192.168.1.$I/32 -m 0x$I

done

## Traffic shaping #########

# Configure queueing discipline
$TCBIN qdisc add dev $EXTERNALIF root handle 1: cbq bandwidth 128Kbit avpkt 1000

# Configure root class
$TCBIN class add dev $EXTERNALIF parent 1:0 classid 1:1 cbq bandwidth 128Kbit rate 128Kbit \
allot 1514 weight 12Kbit prio 8 maxburst 20 avpkt 1000

# Configure class divisions
$TCBIN class add dev $EXTERNALIF parent 1:1 classid 1:2 cbq bandwidth 128Kbit rate 32Kbit \
allot 1514 weight 4Kbit prio 8 maxburst 20 avpkt 1000 bounded

# configure ips for 40Kbit
for I in $CLIENTS; do

$TCBIN class add dev $EXTERNALIF parent 1:2 classid 1:1$I cbq bandwidth 128Kbit rate 32Kbit \
allot 1514 weight 2Kbit prio 5 maxburst 20 avpkt 1000 bounded
$TCBIN qdisc add dev $EXTERNALIF parent 1:1$I sfq quantum 1514b perturb 15
$TCBIN filter add dev $EXTERNALIF parent 1:0 protocol ip prio 100 handle $I fw classid 1:1$I

done

Ik beperk hier het verkeer van 6 clients tot elk 4KB/s maximaal. Zorg wel dat je de kernel op de juiste manier compileerd.

[Red devil]

Op vrijdag 02 maart 2001 19:15 schreef nelske het volgende:
[break interessant verhaal]
[/break interessant verhaal]

Super!
Dit weekend probeer ik alles mooi draaiende te krijgen en komende week ga ik 's avonds met CBQ aan de slag!

[Red devil]

Op zaterdag 03 maart 2001 18:21 schreef wouzer het volgende:
[break ook een interessant verhaal]
[/break ook een interessant verhaal]

Topper, ik heb nu mijn upload verkeer geshaped met rshaper, mbv een module.
Zou jouw methode makkelijker werken?
Het gaat namelijk nu nog om 1 client, dus dat stop ik gewoon in rc.local

Bedankt voor de input!

[Verwijderd]

Op zaterdag 03 maart 2001 18:21 schreef wouzer het volgende:
Upload verkeer kun je wel inperken met trafficshapen. Zie onderstaande voorbeeld. Maar download verkeer beperken wordt wel moeilijk omdat je geen controle hebt over wat andere hosts naar JOU sturen. Voorbeeldje: Je kunt wel zelf bepalen hoeveel brieven je via de post verstuurt echter hoeveel brieven je krijgt heb je niet in de hand.

Als je via routing ervoor zorgt dat ie over het goede IP de pakketjes doorstuurt (zie bovenstaand verhaal), dan is het van de server uit gezien eerst pakketjes downloaden en vervolgens pakketjes doorsturen (lees uploaden) naar de clients. Als je deze laatste stroom beperkt, zoals boven beschreven staat, betekent dit, dat de clients de maximale snelheid zullen halen die opgegeven is voor hun klasse op de interne interface.

Mijn verhaal gaat dus volledig over de interne netwerkkaart (beter gezegd, de netwerkkaart in de server die verbonden is met het interne netwerk, voordat er mensen gaan zeuren:)) en niet over de externe netwerkkaart, waar jouw verhaal over gaat.

De server bepaalt nu (vanaf de clients gezien), de maximale download-snelheid.
Dit is dus ook gewooon upload verkeer vanuit de server gezien en aangezien je de server beperkt hebt in zijn snelheid, lijkt het voor de buitenwereld, alsof de interne clients zo "langzaam" zijn als de snelheid waarop je de interne kaart hebt afgeknepen voor de klasse waarin de client valt.

Zorg er natuurlijk wel voor, dat je inderdaad de juiste dingen in de kernel meecompileert, anders zal het niet werken.

Als je geen intern netwerk achter de server zou hebben, dan kan je inderdaad niet bepalen in welke mate de download beperkt zou moeten worden op bovenstaande manier

(overigens zit er in de nieuwe 2.4.x kernels ook een nieuwe manier om traffic te shapen, maar ik had begrepen, dat een nieuwe kernel niet van toepassing was)

[Red devil]

ok!
Eerst richt ik me even op het CBQ gebeuren, ik heb daar namelijk meer dingetjes over gehoord.

Misschien moet ik eerst maar zeggen dat dit eigenlijk mijn eerste Linux projectje is, ik ben dus eigenlijk een newbie.

Ik heb nu mijn kernel opgenieuwd gecompileerd
(dat was 3 dagen geleden al reden voor een feestje )
Ik heb advanced routing aangeklikt, zou ik nu al die toffe CBQ achtige opties erbij moeten krijgen? Ik ga er even mee prutsen!

[Red devil]

Damn!

Als ik dit intik:

[root@CC87886-A /]# tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit cell 8 avpkt 1000 mpu 64
RTNETLINK answers: Invalid argument
[root@CC87886-A /]#

foutmelding dus, heb ik dus toch niet goed mijn kernel gecompileerd?

[Red devil]

Jo Nelske! Are u there?

[wouzer]

Probeer onderstaande opties mee te linken in je kernel:

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NET_SCH_CBQ=y
# CONFIG_NET_SCH_CSZ is not set
CONFIG_NET_SCH_PRIO=y
# CONFIG_NET_SCH_RED is not set
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_ROUTE4 is not set
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_POLICE is not set

[Red devil]

Op zondag 04 maart 2001 18:43 schreef wouzer het volgende:
Probeer onderstaande opties mee te linken in je kernel:

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NET_SCH_CBQ=y
# CONFIG_NET_SCH_CSZ is not set
CONFIG_NET_SCH_PRIO=y
# CONFIG_NET_SCH_RED is not set
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_ROUTE4 is not set
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_POLICE is not set

Jo Wouzer!

Hmmm hoe link ik dat? Ikwas een newbie!
Verder dan make menuconfig en dan dingen aanvinken kom ik eigenlijk niet...

[Verwijderd]

Hier bent ik:)

Je gaf zelf al het antwoord op je eigen vraag:). Inderdaad is je kernel niet goed geconfigureerd als ie bovenstaande foutmelding geeft.

Je moet inderdaad de door Wouzer genoemde onderdelen met "ja" beantwoorden tijdens het configureren van de kernel.
Als je het via "make menuconfig" doet i.p.v. "make config" zijn alle bovenstaande dingen te vinden in het submenu "Networking Options"->"QOS and farequeueing".

Daar komt een heel lijstje tevoorschijn. Als je in de help bij elk onderdeel kijkt dan zul je bovengenoemde namen terug herkennen. Die onderdelen moeten dus allemaal meegebakken worden in de kernel.

Dit zijn dus:

Qos and/or farequeueing
CBQ packet scheduler
The simplest PRIO pseudoscheduler
SFQ queue
QOS support
Rate estimator
Packet Classifier API
Routing table based classifier
Firewall based classifier
U32 classifier
Ingres traffic policing

verder moet je nog in het submenu "Networking Options" hetvolgende aan hebben staan.

Kernel/User netlink socket
Netlink device emulation
IP: aliasing support

In principe zou hij dan het bovenstaande probleemloos moeten doen:)

[Red devil]

Op maandag 05 maart 2001 02:24 schreef nelske het volgende:
uitleg

Yeah, wouzer en nelske bedankt, mijn oog keek weer eens niet verder dan mijn neus, ik kon nog omlaag scrollen


stomstom! maar nu gaat het lukken, huppakee, make dep!

[Red devil]

Oh yeah! Net even ingelogd op ip van de te shapen client, vlug een download opgestart + een upload.



Plaatje zegt genoeg he?
Werkt perfect!

[Verwijderd]

Gefeliciteerd:)

Tja, werkt toch wel mooi he dat linux:)

[Red devil]

Op maandag 05 maart 2001 22:16 schreef nelske het volgende:
Gefeliciteerd:)

Tja, werkt toch wel mooi he dat linux:)

inderdaad! bedankt he!
en wouzer natuurlijk ook!

[duronbug]

Wouzer, ik heb ongeveer hetzelfde als jou. Ik probeer dus de upload naar buiten toe (internet) af te knijpen tot 4k/sec (128Kbit).
Dit lukt me wel met CBQ, maar als ik dat eenmaal heb en ik heb een upload van 4k dan zakt m'n download ook naar 4k. Dit is dus niet de bedoeling. Ik heb overal al gezocht naar info over dat CBQ gebeuren maar kan niet die info vinden die ik nodig heb.

Hier mijn regels :

# Configure queueing discipline
tc qdisc add dev eth1 root handle 1: cbq bandwidth 128Kbit avpkt 1000

# Configure root class
tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 128Kbit rate 128Kbit \
allot 1514 weight 12Kbit prio 8 maxburst 20 avpkt 1000

# Configure class divisions
tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 128Kbit rate 32Kbit \
allot 1514 weight 4Kbit prio 8 maxburst 20 avpkt 1000 bounded

tc qdisc add dev eth1 parent 1:2 sfq quantum 1514b perturb 15
tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip src $extIP flowid 1:2

Ow ja, mijn linux bakkie is dus de router voor een netwerk met 3 clients (windows). Eth1 is de interface verbonden met internet.

[Verwijderd]

Helaas is er door BC3 het meest interessante deel uit deze hele discussie verloren gegaan.

Meer info (performance, voor- en nadelen) kan je vinden door o.a. op Sally Floyd (uit m'n hoofd) te zoeken. Zij is een van de belangrijkste figuren achter het hele CBQ-gebeuren.

Het is dus de bedoeling dat je via aliasses verschillende klassen op zet en dat je het verkeer over de goed klasse route.

Ofwel je wil dat interne clients waarschijnlijk over de snelste klasse naar buiten toe gaan.

[duronbug]

Heb ff lopen zoeken naar Sally Floyd. Vind idd wel wat info maar voor mij iets te ingewikkeld. Gaat vooral over hoe het algoritme in elkaar zit enzo.

Het is een beetje hetzelfde probleem als wat je standaard met je provider al hebt. Bij de meeste providers heb je een upload limit van 16k/sec. Als deze vol in gebruik is kun je ook maar met 16k/sec downloaden. Daarom was het mijn idee ook om die upload laag te houden, zodat de download snelheid hoger kan blijven. Maarja.. als hetzelfde probleem ook ontstaat met die bandbreedte indeling met CBQ schiet je nog niet erg op. Het wordt zelfs erger als je hem op 4k hebt afgesteld.
Maarja, we zullen doorzoeken naar een oplossing

[Verwijderd]

is zoiets ook te gebruiken in een hostingbedrijf? dus dat je aan elke server een bepaalde bandbreedte geeft?
ik praat over een klein bedrijfje hoor hehehe

[odysseus]

Dat lijkt me dat geen probleem, gewoon rules aanmaken zoals hierboven staan voor de verschillende clients. Om incoming traffic te shapen moet je er wel een router tussen hebben staan, maar ik vermoed dat dat wel geregeld is.

[Verwijderd]

Incoming traffic kun je ook via CBQ shapen..

Je maakt eerst de rules aan met ipchains en markeerd de packets welke je gequeued wilt hebben, daarna vertel je via tc en ip hoe je die pakketjes gequeued wilt hebben.

e.e.a. staat vrij basic uitgelegd in genoemde routing howto, kijk ook op netfilter.filewatcher.org.

//edit

negeer dit bericht maar, hezik moet eerst eens gaan lezen voordat hij z'n muil opentrekt.. excuses..