[LARTC] tc filter not work, why?
I try to use tc on mips with linux-2.4.18 but the u32 filter dosn't work I added htb qdisc to linux-2.4.18 and use it to limit the speed in LAN, it only work well on the default class, for example tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000kbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 500kbit ceil 500kbit tc calss add dev eth0 parent 1:1 classid 1:11 htb rate 300kbit ceil 300kbit tc filter add dev eth0 protocol ip u32 match ip dst 192.168.18.100 flowid 1:11 the host 192.168.18.100 have a speed of 500kbit rather than 300kbit. if I don't set the default 10 class, all this dosn't have any effect. why? thank you. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Patch accurate packet scheduling for ATM/ADSL
Hi,
2007/7/26, Russell Stuart [EMAIL PROTECTED]:
On Wed, 2007-07-25 at 15:14 +0200, Edouard Thuleau wrote:
I use the patch
(http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate
the packet scheduling on ATM/ADSL link and i think I've found a bug.
I tried to write to the author but he didn't answer me.
Sorry. :( I have now.
Thanks for your answer.
I work on a Linux 2.6.17 with the iproute2-2.6.18-061002 package.
I change the type of the cell_align char to short of the struct
tc_ratespec in the file pkt_sched.h (in the include/linux/ directories
of iproute package and the kernel source) :
struct tc_ratespec
{
unsigned char cell_log;
unsigned char __reserved;
unsigned short feature;/* Always 0 in pre-atm patch kernels */
- charcell_align; /* Always 0 in pre-atm patch kernels */
- unsigned char __unused;
+ short cell_align; /* Always 0 in pre-atm patch kernels */
unsigned short mpu;
__u32 rate;
};
The results are much better and with my tests, it works very nicely.
If it can help someone,
I can't see how that would change things as the cell align
always lies within the range -7..0. The only thing that
springs to mind is perhaps you aren't using i386, and your
CPU doesn't sign extend char's??? What CPU are you using?
Yes I use an ARM big-endian architecture, it's my problem.
I understood now.
If we put a short, the patch works for all architecture, no ?
Thanks.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Rép : [LARTC] about default filter command
Le 26 juil. 07 à 13:55, Georgi Alexandrov a écrit : Vincent Dautremont wrote: Hi, here I have another newcomer question :-) in the section 9.6.1 of this how too http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html we can read commands about filters : -- # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip dport 22 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip sport 80 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 What does this say? It says: attach to eth0, node 10: a priority 1 u32 filter that matches on IP destination port 22 *exactly* and send it to band 10:1. And it then repeats the same for source port 80. The last command says that anything unmatched so far should go to band 10:2, the next-highest priority. -- i try to do this at home as i want my ssh traffic prioritary to other traffic but the problem is with the last command ! it simply don't work. The last command that says default trafic goes to prio 2 doesn't work # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 just give me the error: Unknown filter flowid, hence option 1:2 is unparsable So I don't get what do I must do in order to say that the default trafic goes on priority 2 of the prio filter is this how too always valid with the current version of tc ? did i do something wrong ? Thank you for your help. snip You should have posted *all* your tc rules. -- regards, Georgi Alexandrov key server - pgp.mit.edu :: key id - 0x37B4B3EE Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE Ok, thanks for you advise, here are all my tc rules : # tc qdisc add dev eth0 root handle 1: prio # tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0x flowid 1:1 # tc filter add dev eth0 protocol ip parent 1: prio 2 flowid 1:2 does this lack one rule ? anyway the last one is not accepted by tc. Vincent. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: tc filter not work, why?
Does the tc and the linux kernel net/sched/ version must match exactly? or the kernel configuration miss some modules? I have compiled in all the Qos and/or fair queueing. thank you for your help. On 7/26/07, 吴明津 [EMAIL PROTECTED] wrote: I try to use tc on mips with linux-2.4.18 but the u32 filter dosn't work I added htb qdisc to linux-2.4.18 and use it to limit the speed in LAN, it only work well on the default class, for example tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000kbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 500kbit ceil 500kbit tc calss add dev eth0 parent 1:1 classid 1:11 htb rate 300kbit ceil 300kbit tc filter add dev eth0 protocol ip u32 match ip dst 192.168.18.100 flowid 1:11 the host 192.168.18.100 have a speed of 500kbit rather than 300kbit. if I don't set the default 10 class, all this dosn't have any effect. why? thank you. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] IPv6 in IPv6 tunneling
hello, is there any tool to support IPv6 in IPv6 or IPv6 in UDP over IPv6 out of the box solution (preferably :P)? Greetings, Marius Corici ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc filter not work, why?
Hello 吴明津, Maybe in your filter statement you should use src rather than dst? It is not clear what interface is connected to what hosts. HTH, -Nik 吴明津 wrote: I try to use tc on mips with linux-2.4.18 but the u32 filter dosn't work I added htb qdisc to linux-2.4.18 and use it to limit the speed in LAN, it only work well on the default class, for example tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000kbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 500kbit ceil 500kbit tc calss add dev eth0 parent 1:1 classid 1:11 htb rate 300kbit ceil 300kbit tc filter add dev eth0 protocol ip u32 match ip dst 192.168.18.100 flowid 1:11 the host 192.168.18.100 have a speed of 500kbit rather than 300kbit. if I don't set the default 10 class, all this dosn't have any effect. why? thank you. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Patch accurate packet scheduling for ATM/ADSL
On Wed, 2007-07-25 at 15:14 +0200, Edouard Thuleau wrote:
I use the patch
(http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate
the packet scheduling on ATM/ADSL link and i think I've found a bug.
I tried to write to the author but he didn't answer me.
Sorry. :( I have now.
I work on a Linux 2.6.17 with the iproute2-2.6.18-061002 package.
I change the type of the cell_align char to short of the struct
tc_ratespec in the file pkt_sched.h (in the include/linux/ directories
of iproute package and the kernel source) :
struct tc_ratespec
{
unsigned char cell_log;
unsigned char __reserved;
unsigned short feature;/* Always 0 in pre-atm patch kernels */
- charcell_align; /* Always 0 in pre-atm patch kernels */
- unsigned char __unused;
+ short cell_align; /* Always 0 in pre-atm patch kernels */
unsigned short mpu;
__u32 rate;
};
The results are much better and with my tests, it works very nicely.
If it can help someone,
I can't see how that would change things as the cell align
always lies within the range -7..0. The only thing that
springs to mind is perhaps you aren't using i386, and your
CPU doesn't sign extend char's??? What CPU are you using?
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] about default filter command
Vincent Dautremont wrote: Hi, here I have another newcomer question :-) in the section 9.6.1 of this how too http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html we can read commands about filters : -- # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip dport 22 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip sport 80 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 What does this say? It says: attach to eth0, node 10: a priority 1 u32 filter that matches on IP destination port 22 *exactly* and send it to band 10:1. And it then repeats the same for source port 80. The last command says that anything unmatched so far should go to band 10:2, the next-highest priority. -- i try to do this at home as i want my ssh traffic prioritary to other traffic but the problem is with the last command ! it simply don't work. The last command that says default trafic goes to prio 2 doesn't work # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 just give me the error: Unknown filter flowid, hence option 1:2 is unparsable So I don't get what do I must do in order to say that the default trafic goes on priority 2 of the prio filter is this how too always valid with the current version of tc ? did i do something wrong ? Thank you for your help. snip You should have posted *all* your tc rules. -- regards, Georgi Alexandrov key server - pgp.mit.edu :: key id - 0x37B4B3EE Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: Definitive way to aggregate bandwidth using multiple links
On Thu, 26 Jul 2007 09:30:51 -0500 Grant Taylor [EMAIL PROTECTED] wrote: The only thing that comes to mind that would facilitate true aggregation of multiple links would be to have a server on very high bandwidth that you could create multiple tunnels (IPIP / IPSec / GRE) to and have it aggregate the multiple tunnels together and then use the aggregated tunnel as your larger pipe to the world and do all your NATing at that end so the world would see you from one largish connection. But his if you want to aggregate bandwidth to the world. Yes, in theory it should work. But I want to agregate bandwidth just for me (although it would be nice if the world could see one huge link). For external access, it would be nice (and simpler) if we had a universal protocol which just tell the client you can access this server through IPs x, y and z and the client would open connections to x, y and z. There's program that does this, but you have to tell the IPs to connect: http://aria2.sourceforge.net/ aria2 has segmented downloading engine in its core. It can download one file from multiple URLs http://wilmer.gaast.net/main.php/axel.html This support multiple servers too and can download a list of mirrors... -- Linux 2.6.22: Holy Dancing Manatees, Batman! http://www.lastfm.pt/user/danielfraga http://u-br.net ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Patch accurate packet scheduling for ATM/ADSL
Hi ! (Sorry for my bad english...) I use the patch (http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate the packet scheduling on ATM/ADSL link and i think I've found a bug. I use it too, this patch is great! :o) But, with TBF, both burst and limit parameters are affected by the patch (or I clearly missed something). tc qdisc add dev eth1 root handle 1:0 tbf rate 100kbit \ burst 1514b limit 1514b mpu 64 atm overhead -4 tc qdisc add dev eth1 parent 1:1 handle 10:0 pfifo Before the patch (without atm overhead -4), using PPPoA + VC/Mux and MSS set to 1438, TBF was working normally. Just after the patch (with atm overhead -4), it stopped working : packets were blocked until I raise up burst and limit to 1696 (32 * 53). In this case Linux sees 1492 bytes packets on eth1 (1438 + 20 IP + 20 TCP + 14 Ethernet) Same effect with a lower MSS : burst and limit must be set to 742b (14 * 53) when MSS = 574. Pretty sure I do not unsterdand something... and wondering why I cannot set set burst/limit to 628b (only for TCP streams). To get mimimal burst/limit values, an extra atm cell is needed : mss = 1150 eth1 packet = 1204b (1150 + 40 + 14) modem packet = 1200b ( 1150 + 40 + 2 PPP + 8 AAL5) Atm cells = 25 (1200 / 48) Add one cell... and... min burst/limit = 1378 ( 26 * 53 ) TBF rate also seems to be affected: I currently have it set to 159kbit on a 128kbits upstream link and it works like a charm! :o) This is not really a problem (if it works, don't touch it) but I would like to understand... Thanks! Philippe ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: Rép : [LARTC] about default filter command
i'm a bit lost with the command line of tc class add first i do that and it works # tc qdisc add dev eth0 root handle 1: prio # tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0x flowid 1:1 then i do # tc class add dev eth0 parent:1.0 classid1:2 and the result is RTNETLINK answers: File Exist which seams normal to me because when i create the prio qdisc with the first command it add automatically 3 classes (1:1, 1:2, 1:3) No, i think the problem is not here. It must be the 'how-to' i refer to which must be false. So how to choose 1 of the 3 queue of prio as the default one. ...that remains a mistery. anyway thanks for your help. Vincent. Le 27 juil. 07 à 04:00, 吴明津 a écrit : you should try to add the class that the filter said unknown flowid On 7/27/07, Vincent Dautremont [EMAIL PROTECTED] wrote: Are you sure ? because that's not what is written in the how-to http://lartc.org/howto/lartc.qdisc.classful.html check section 9.5.3 which says that three classes are automatically created by default. and in section 9.5.3.2 : # tc qdisc add dev eth0 root handle 1: prio ## This *instantly* creates classes 1:1, 1:2, 1:3 Vincent. Le 27 juil. 07 à 03:45, 吴明津 a écrit : It seems you miss the class . On 7/27/07, Vincent Dautremont [EMAIL PROTECTED] wrote: Le 26 juil. 07 à 13:55, Georgi Alexandrov a écrit : Vincent Dautremont wrote: Hi, here I have another newcomer question :-) in the section 9.6.1 of this how too http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html we can read commands about filters : -- # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip dport 22 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip sport 80 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 What does this say? It says: attach to eth0, node 10: a priority 1 u32 filter that matches on IP destination port 22 *exactly* and send it to band 10:1. And it then repeats the same for source port 80. The last command says that anything unmatched so far should go to band 10:2, the next-highest priority. -- i try to do this at home as i want my ssh traffic prioritary to other traffic but the problem is with the last command ! it simply don't work. The last command that says default trafic goes to prio 2 doesn't work # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 just give me the error: Unknown filter flowid, hence option 1:2 is unparsable So I don't get what do I must do in order to say that the default trafic goes on priority 2 of the prio filter is this how too always valid with the current version of tc ? did i do something wrong ? Thank you for your help. snip You should have posted *all* your tc rules. -- regards, Georgi Alexandrov key server - pgp.mit.edu :: key id - 0x37B4B3EE Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE Ok, thanks for you advise, here are all my tc rules : # tc qdisc add dev eth0 root handle 1: prio # tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0x flowid 1:1 # tc filter add dev eth0 protocol ip parent 1: prio 2 flowid 1:2 does this lack one rule ? anyway the last one is not accepted by tc. Vincent. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: Rép : [LARTC] about default filter command
Are you sure ? because that's not what is written in the how-to http://lartc.org/ howto/lartc.qdisc.classful.html check section 9.5.3 which says that three classes are automatically created by default. and in section 9.5.3.2 : # tc qdisc add dev eth0 root handle 1: prio ## This *instantly* creates classes 1:1, 1:2, 1:3 Vincent. Le 27 juil. 07 à 03:45, 吴明津 a écrit : It seems you miss the class . On 7/27/07, Vincent Dautremont [EMAIL PROTECTED] wrote: Le 26 juil. 07 à 13:55, Georgi Alexandrov a écrit : Vincent Dautremont wrote: Hi, here I have another newcomer question :-) in the section 9.6.1 of this how too http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html we can read commands about filters : -- # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip dport 22 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip sport 80 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 What does this say? It says: attach to eth0, node 10: a priority 1 u32 filter that matches on IP destination port 22 *exactly* and send it to band 10:1. And it then repeats the same for source port 80. The last command says that anything unmatched so far should go to band 10:2, the next-highest priority. -- i try to do this at home as i want my ssh traffic prioritary to other traffic but the problem is with the last command ! it simply don't work. The last command that says default trafic goes to prio 2 doesn't work # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 just give me the error: Unknown filter flowid, hence option 1:2 is unparsable So I don't get what do I must do in order to say that the default trafic goes on priority 2 of the prio filter is this how too always valid with the current version of tc ? did i do something wrong ? Thank you for your help. snip You should have posted *all* your tc rules. -- regards, Georgi Alexandrov key server - pgp.mit.edu :: key id - 0x37B4B3EE Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE Ok, thanks for you advise, here are all my tc rules : # tc qdisc add dev eth0 root handle 1: prio # tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport 22 0x flowid 1:1 # tc filter add dev eth0 protocol ip parent 1: prio 2 flowid 1:2 does this lack one rule ? anyway the last one is not accepted by tc. Vincent. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Multi-Path Load Balancing
Hi, We have the following config: Servers - BGP router (10 Gbit) - BGP router (1 Gbit) - BGP router (100 mbit) We would like to do the following. The server should first fill the 100 mbit link, then fill the 1 Gbit link, and then the 10 Gbit link, when traffic increases. The resverse applies when traffic decreases. I found lots of docs on round-robin weighted link, etc, but that would actually load balance these links evenly. We would like have it work like a bucket system though. Any ideas? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] help compiling tcng on 64bit
Hi, Trying to compile tcng on 64bit server (centos-5 64bit), I'm getting: -- cc -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -I../shared -DVERSION=\`cat ../VERSION`\ -DTOPDIR=\/usr/local/src/tcng-non-patched\ -DDOLLAR -DCONFIRM_EXCEED -c -o f_fw.o f_fw.c In file included from ../shared/memutil.h:13, from util.h:14, from f_fw.c:13: /usr/include/sys/types.h:46: error: conflicting types for loff_t /usr/include/linux/types.h:30: error: previous declaration of loff_t was here /usr/include/sys/types.h:62: error: conflicting types for dev_t /usr/include/linux/types.h:13: error: previous declaration of dev_t was here In file included from /usr/include/sys/types.h:133, from ../shared/memutil.h:13, from util.h:14, from f_fw.c:13: /usr/include/time.h:105: error: conflicting types for timer_t /usr/include/linux/types.h:22: error: previous declaration of timer_t was here In file included from ../shared/memutil.h:13, from util.h:14, from f_fw.c:13: /usr/include/sys/types.h:198: error: conflicting types for int64_t /usr/include/linux/types.h:98: error: previous declaration of int64_t was here /usr/include/sys/types.h:204: error: conflicting types for u_int64_t /usr/include/linux/types.h:97: error: previous declaration of u_int64_t was here In file included from /usr/include/sys/types.h:220, from ../shared/memutil.h:13, from util.h:14, from f_fw.c:13: /usr/include/sys/select.h:78: error: conflicting types for fd_setБ-? /usr/include/linux/types.h:12: error: previous declaration of fd_setБ-? was here In file included from ../shared/memutil.h:13, from util.h:14, from f_fw.c:13: /usr/include/sys/types.h:235: error: conflicting types for blkcnt_tБ-? /usr/include/linux/types.h:114: error: previous declaration of blkcnt_tБ-? was here In file included from data.h:14, from location.h:21, from error.h:14, from f_fw.c:14: /usr/include/stdint.h:56: error: conflicting types for uint64_t /usr/include/linux/types.h:96: error: previous declaration of uint64_t was here -- If I comment line #include sys/types.h in shared/memutil.h (like it is done in http://devel.dob.sk/tcng+esfq/) I get one error only: -- DTOPDIR=\/usr/local/src/tcng-non-patched\ -DDOLLAR -DCONFIRM_EXCEED -c -o f_fw.o f_fw.c In file included from data.h:14, from location.h:21, from error.h:14, from f_fw.c:14: /usr/include/stdint.h:41: error: conflicting types for int64_t /usr/include/linux/types.h:98: error: previous declaration of int64_t was here /usr/include/stdint.h:56: error: conflicting types for uint64_t /usr/include/linux/types.h:96: error: previous declaration of uint64_t was here -- Did anybody try compiling it under 64bit? Appreciate any help with this. Thanks Roman ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
