Hi, I have a rather simple problem I have to solve, well I thought it would be simple, I've run into a problem. I think I must be missing something fundamental. I am trying to build a Linux router that simply throttles everything down to certain bandwidths. That is, no priority queuing ...etc, just slow all traffic down to the specified rates, which are 64,128,256,512 kbit. We want to setup the bandwidth on the router, then pump a known load from an application through the router and see how that behaves over various link speeds. (we are in a lab environment) Using kernel 2.6.5-1.358 I simply used these commands from Stef's version of tc from docum.org, module sch_htb is loaded. tc qdisc add dev eth0 root handle 10: htb tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kit I thought that would do the job, but my testing from uploading files via ftp to another box, show nothing gets shaped. I think I've missed something here and need a clue. Alternatively can anyone suggest any programs that are designed for doing this type of work. Thanks Darryl
On Wednesday 17 November 2004 22:29, Darryl Cording wrote: > Hi, > <snip> > I am trying to build a Linux router that simply throttles everything > down to certain bandwidths. That is, no priority queuing ...etc, just > slow all traffic down to the specified rates, which are 64,128,256,512 > kbit. We want to setup the bandwidth on the router, then pump a known > load from an application through the router and see how that behaves > over various link speeds. (we are in a lab environment) Using the htb qdisc with ceil equal to rate ought to accomplish this. > Using kernel 2.6.5-1.358 I simply used these commands from Stef's > version of tc from docum.org, module sch_htb is loaded. > > tc qdisc add dev eth0 root handle 10: htb > tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kit You need to classify your traffic. tc qdisc add dev eth0 root handle 10: htb default 10 tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kit If you add the default parameter, htb will put any unclassified into classid 10:1. > I thought that would do the job, but my testing from uploading files via > ftp to another box, show nothing gets shaped. Right, because it wasn't classified. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff
Thanks for the feedback Jason, Jason Boxman wrote: > On Wednesday 17 November 2004 22:29, Darryl Cording wrote: > > <snip> > >>I am trying to build a Linux router that simply throttles everything >>down to certain bandwidths. That is, no priority queuing ...etc, just >>slow all traffic down to the specified rates, which are 64,128,256,512 >>kbit. We want to setup the bandwidth on the router, then pump a known >>load from an application through the router and see how that behaves >>over various link speeds. (we are in a lab environment) > > > Using the htb qdisc with ceil equal to rate ought to accomplish this. I thought the same thing, so far so good. > >>Using kernel 2.6.5-1.358 I simply used these commands from Stef's >>version of tc from docum.org, module sch_htb is loaded. >> >>tc qdisc add dev eth0 root handle 10: htb >>tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kit > > > You need to classify your traffic. > > tc qdisc add dev eth0 root handle 10: htb default 10 > tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kit > > If you add the default parameter, htb will put any unclassified into classid > 10:1. That makes sense. > > >>I thought that would do the job, but my testing from uploading files via >>ftp to another box, show nothing gets shaped. > > > Right, because it wasn't classified. > Ok, so I have to classify my traffic before this will route them throu the qdisc. Are you taking about classifying via iptables?? I thought that was optional, more for filtering ...etc. regards darryl
Darryl Cording wrote: >> >> Right, because it wasn't classified. >> > Ok, so I have to classify my traffic before this will route them throu > the qdisc. Are you taking about classifying via iptables?? I thought > that was optional, more for filtering ...etc. > > regards > darryl > I was getting confused with the terminology. I was thinking filtering was meaning something else when "tc filter ..." actually does the classifying. I was also assuming that if you don't specify any packet attributes to filter on it would just catch everything, seems it's the opposite. OK, so I used this; tc qdisc add dev eth0 root handle 10: htb default 10 tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kbit and have been experimenting with classifying like this, tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip protocol 0 0xff tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip protocol 6 0xff But it seems my ftp transfers are not being shaped, in fact, lol, they are going faster from when I first started experimenting. So it's not matching correctly. I just want to shape everything going past the NIC's. I thought that if I could classify the entire ip protocol or the tcp protocol that would shape the bulk of the traffic ? I was hoping not having to get down to specifying ports, but find a simple way to shape all outgoing traffic on a multi-homed host. Am I on the right track? And what worries me also now, is that the application traffic coming over the wire will be DCOM, which I think is rpc based, another world of hurt if I have to figure out what ports that app is using. thanks for any tips, darryl
Darryl Cording wrote: > > But it seems my ftp transfers are not being shaped, in fact, lol, they > are going faster from when I first started experimenting. So it's not > matching correctly. I just want to shape everything going past the > NIC's. I thought that if I could classify the entire ip protocol or the > tcp protocol that would shape the bulk of the traffic ? I was hoping > not having to get down to specifying ports, but find a simple way to > shape all outgoing traffic on a multi-homed host. > > Am I on the right track? > I guess I could match by ip addresses but I hoping for a simpler way to match everthing.
Darryl Cording wrote: > Darryl Cording wrote: > >> >> But it seems my ftp transfers are not being shaped, in fact, lol, they >> are going faster from when I first started experimenting. So it's not >> matching correctly. I just want to shape everything going past the >> NIC's. I thought that if I could classify the entire ip protocol or >> the tcp protocol that would shape the bulk of the traffic ? I was >> hoping not having to get down to specifying ports, but find a simple >> way to shape all outgoing traffic on a multi-homed host. >> >> Am I on the right track? >> > I guess I could match by ip addresses but I hoping for a simpler way to > match everthing. You were close - default refers to the number after the : 10: is short for 10:0 . tc qdisc add dev eth0 root handle 10: htb default 1 tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kbit should shape everything. Andy.
Andy Furniss wrote: > Darryl Cording wrote: > >>> >> I guess I could match by ip addresses but I hoping for a simpler way >> to match everthing. > > > You were close - default refers to the number after the : I guess I am still struggling with the syntax of tc. > > 10: is short for 10:0 . Thanks for that clue. > > tc qdisc add dev eth0 root handle 10: htb default 1 > tc class add dev eth0 parent 10: classid 10:1 htb rate 64kbit ceil 64kbit > > should shape everything. And in fact it does. :-D Thanks for the help. > > Andy. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- Ascend Business Solutions Pty Ltd Level 3, 232 Adelaide St, Brisbane, Qld, 4000 Phone (07) 3223 5555 Fax (07) 3223 5500 www.ascend.net.au This email is from the offices of Ascend Business Solutions Pty Ltd, Software Testing Specialists, Brisbane, Queensland, Australia. This email contains privileged and confidential information. It is intended for the recipient only. Should this email be received in error please notify this office immediately by reply email and delete this email from your inbox.