Re: [LARTC] List fault?
Same here, after having not received mails from this list for a long, long time. On 05/03/2011 11:52 PM, Don Gould wrote: I'm getting a small stream of old posts and spam off this list. Are others seeing same? D ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Simple Example isnt working (ssh/bulk traffic)
Hello, Julius wrote: > Hi, > > the script below should allow to get ssh connections running well while > downloading, but even the 100kbps (100kbyte/s?) doesnt work - can still > download with 500+kb/s. Whats wrong? > > INTERFACE=eth0 are you mixing egress with ingress? (IMQ in that case) What's you network-configuration (it's a router? what eths)? And yes, kbps actually is kbyte/s, kbit for kbit/s. If all should be setup right, what does # tc -s -d class show dev eth0 say? Bye, Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc filter question
Hi Daniel. Daniel wrote: > Dear all, > > I have big question in my mind about "tc filter" sintax. If I give "tc -s -d > filter sh dev eth0" command, then the output is like below : > > filter parent 1: protocol ip pref 1 u32 > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt > 0 flowid 1:2 (rule hit 21553629 > success 37907) > match 0016/ at 20 (success 37907 ) > > ... > > My question is : > 1. What is "fh 800:" and "fh 800::800" mean ? > 2. How I change the value "800" in "fh 800::800" ? I'm guessing this is > default value and I need to change that because my filter rule can be more > than 0xfff line. Hi, that values are for the hash-tables of u32, see: http://lartc.org/howto/lartc.adv-filter.hashing.html > > Thanks for all, > > Daniel > PadiNet Makassar Bye, Andreas. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Distro ready out of the box
Hi, [EMAIL PROTECTED] wrote: > Debian 4.0 has all I need including iptables and tc, but _not_ L7 filter or > ipp2p :-( > > You should look into Zeroshell, which has L7 (haven't tried it) > http://linuxdevices.com/news/NS9446520379.html > http://www.zeroshell.net/eng > > Shorewall appears to have ipp2p (but apparently not L7?) > > and it looks like there are add ons to IPCop. > > It is sad it is not easier... I looked into L7 etc. and ended up deciding > that is is such an imperfect way of classifying data that it is better (for > me at least) to instead choose a different policy - prioritize ssh, VOIP > and web by port and then prevent each host from hogging more than their > fair share of the total bandwidth. > > But e.g. DD-WRT (embedded distro for wireless routers like the WRT54GL) > seems to do a quite good job of it (with L7). By the way, OpenWRT also offers an x86 version (Kamikaze) which might suit you. > > sincerely, > Nicolas Sincerely, Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Why not qos for downloading stream??
Hi, Beat Meier wrote: > HI there > > Simple question :-) > Why there is always only qos examples for upload and not download stream of > adsl? The packages are allready on your router, so why slowing down the routing? You cannot hinder anyone to send you data but you can control the questioning for more incoming traffic. (the case here is a "slow" internet connection) [...] > > Now comes the filtering and I was wondering if there > 1. makes sense i.e. it helps us if download speed is at limit to priorize > ssh, voip etc. > 2. what will be the cpu load if you have not only 5 connected clients if > not say 30 > and a lot of filter rules i.e. each customer needs his full filter set ... [...] That's how I would argue on the other questions with a "no". (Btw., afaik the traffic of 5 or 30 people would not fully load a 200MHz mipsel router on this line, but effectively shaping for low latency (voip) could be hard to deal with on that line). Bye, Andreas. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] cpufreq affects rate in, at least, htb
Hi, DervishD DervishD wrote: > Hi all :) > > I've tested this and having a cpufreq that slows down the CPU > affects the rate of HTB. My ondemand cpufreq governor scales down the > CPU frequency about 40% and this is more or less the slowdown the rate > suffers, 40%. > > Any known way of dealing with this without having to disable > cpufreq? > > Thanks in advance :) > > Raúl Núñez de Arenas Coronado > What kernel-version do you use? In 2.6.22 another timer is used for psched. Maybe NO_HZ could interfere on this issue too. Bye, Andreas. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] help compiling tcng on 64bit
Hi Roman, try a patch from a distributor, e.g. Debian (http://ftp.debian.org/debian/pool/main/t/tcng/tcng_10b-1.diff.gz). Andreas Roman Ledovskiy wrote: > 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 " 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 > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Why does scp stall on low bandwidth connections?
The first one only recognize IP traffic, the line with default will match any kind of traffic. Regards, Andreas Quoting Nikolay Kichukov <[EMAIL PROTECTED]>: Hello Andy, Is that line: tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match u32 0 0 flowid 1:2 not equal to: tc qdisc add dev eth0 root handle 1:0 htb default 2 in terms of achieved results? If not, what is the difference? Thanks, -Nikolay ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HFSC with tcng
Hi Simo, Simo wrote: > [...] > I don?t know how to use HFSC queuing discipline with tcng configuration > language. I become always this error: syntax error near "hfsc" > [...] > Is it possible, that tcng provides no support for this classful hfcs queuing > discipline? > [...] no, there is no such support and might never be, because this project is no longer under active development. Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: LARTC Digest, Vol 26, Issue 24
Hallo terraja-based, terraja-based wrote: [snip] > iptables -t mangle -A PREROUTING -i eth1 -p tcp --dport 80 -j MARK > --set-mark 2 > iptables -t mangle -A PREROUTING -i eth1 -p tcp --dport 20 -j MARK > --set-mark 3 > iptables -t mangle -A PREROUTING -i eth1 -p tcp --dport 21 -j MARK > --set-mark 3 [snip] > The traffic it continues goes out by the "default" qdisc (1:30), and it was > not clasified by the correct qdisc. [snip] the marks you set here will be gone as soon as the packet leaves, connmark could do the trick here. Still, matching --sport on the imq device should do the job as well, at least for http at port 80. For ftp, passive mode (data) connections will go to the default-class as the server's port is chosen at runtime, to catch them better use a level-7 filter (e.g. http://sourceforge.net/projects/l7-filter/). Bye, Andreas. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Setting bandwidth to unlimited
Make a filter which sent the traffic to an none existing class id. This traffic will not apply to any class rule and will not be shaped. In fact the only qdisc which is then limiting the traffic (and you can't avoid) ist the root qdisc of the interface. Cheers, Andreas On Fri, 2007-03-23 at 11:11 -0700, Joel Parker wrote: > Hello, > I am using the following commands to "throttle" the bandwidth > of the NIC at eth0 : > > tc qdisc del dev eth0 root > tc qdisc add dev eth0 root handle 10: cbq bandwidth 100mbit avpkt 1000 > tc qdisc add dev eth0 root handle 10: htb > tc class add dev eth0 parent 10: classid 10:1 cbq bandwidth 100mbit > rate128kbit allot 1514 maxburst 20 avpkt 1000 bounded prio 3 > tc class add dev eth0 parent 10: classid 10:1 htb rate 128kbit > > (1) First question is, will the above successfully throttle the > bandwidth of the nick to 128 kilibits per second ? > > (2) Next question what value do I use for unlimited bandwidth ? > > Thanks for the help, > > -- Joel Parker > > > > > ___ > 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] TC Filter matching all
I use this one for "match anything" http://mailman.ds9a.nl/pipermail/lartc/2005q3/016774.html Andreas Quoting Michał Margula <[EMAIL PROTECTED]>: Hello! I was always using "default" in HTB to choose default class, but now I need to do it with filters. Tried following command: # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 Unknown filter "flowid", hence option "10:2" is unparsable It is from example in LARTC Howto. My question is then - how to make a filter matching all without eating too much CPU cycles? Thanks -- Michał Margula, [EMAIL PROTECTED], http://alchemyx.uznam.net.pl/ "W życiu piękne są tylko chwile" [Ryszard Riedel] ___ 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] know if packets are marked
Also connection tracking (cat /proc/net/ip_conntrack) if loaded will show up the mark id (mark=). Andreas On Wed, 2007-01-24 at 07:29 -0300, Roberto Pereyra wrote: > Hi !! > > I marking packets in a bridge: > > Mark outbound www packets from clients: > > /usr/local/sbin/iptables -A PREROUTING -t mangle -m physdev > --physdev-in eth1 -p tcp --dport 80 -j MARK --set-mark 2 > > How I can know if this packets are marked ? > > roberto > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Traffic shaper based on UIDs
Hi, [EMAIL PROTECTED] wrote: ... > But there is no filter based on unix user id (the reason is clear for > everybody -- ip packet doesn't contain this information). > > I've found the very interesting netfilter patches at the patch-o-matic: ... There is no need for POM patches, you may use the "owner" match from iptables. (see: man iptables) > Am I on the right way? How can I combine the power of netfilter and > traffic control systems to solve my problem? ... You might match for each user and then set a mark or even classify directly by iptables. (see man, too) Howto mark: http://lartc.org/howto/lartc.qdisc.filters.html (9.6.2, fwmark) Btw.. there is no best (classful) qdisc, this varies on your needs. Nevertheless, I'd take htb because it's relativly simple to setup (personally I like hfsc though). You may just try them out. :) Bye, Andreas. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] I not find in the kernel code the code of this command
Franco wrote: > Hi!, > My problem is this: > I'm searching, in kernel code, the code that implement thi command: > > tc filter add dev eth2 parent : protocol ip prio 1 u32 match ip src > 0.0.0.0/0 police rate $1 burst $2 drop flowid :1 > > I thought that this code was police.c but seem that it isn't > i must implement a proc file in the code and recompiling the kernel. > > Please send eventual response to my mail address ([EMAIL PROTECTED]) > > Thanks > > Franco > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc In 2.6.17.11 it should be in net/sched/act_police.c . Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Linux router performance
Hi, Maybe: Khan, Sohel; Waheed, Abdul (2003): High Performance Routing on PCshttp://www.ccse.kfupm.edu.sa/~sohel/networking/references/Routing.pdf A rule of thumb: - with current COTS hardware and (standard) PCI Bus, you can reach the maximum of the PCI bus bandwidth. That's 1 GB/s, e.h. two NICs with 500 Meg/s each ( one in and one out ) - with PCI-X and in the future PCI-express you'll for sure be able to reach more performance. I didnt find a sponsor for a test-lab yet :) - in DoS secnarios it may get worse :/ I heavily depends on driver type (polling and NAPI preferred). The problem with the performace is _always_ the number of interrupts, nothing else is a bottleneck (well, we didn't talk about thousands of iptables rules yet, but you ask for a 'maximum'). - The question you have to ask in high-performance scenarios is not "MBit/s" but MPPS (megapackets per seconds). FreeBSD and Linux broke the 1 MPPS barrier some time ago (on dual xeons). rgds, Andreas Fermín Galán Márquez wrote: > Hi, > > I wonder about the performance of a Linux box used as router (I guest I'm > not the first :). Althought I know it mainly depends on the hardware, I'm > trying to find some references on the topic or comparations with other > routing solutions (FreeBSD box used as router, Cisco, etc). For example, > http://facweb.cti.depaul.edu/jyu/Publications/Yu-Linux-TSM2004.pdf > (althought is related with Linux-briding more than with Linux-routing) shows > in Figure 14 that with an AMD Duron 1.3GHz 512M RAM a throughput of 90 Mbps > can be achieved. > > Anybody knows any other similar analysis, please? > > Best regards, > > > Fermín Galán Márquez > CTTC - Centre Tecnològic de Telecomunicacions de Catalunya > Parc Mediterrani de la Tecnologia, Av. del Canal Olímpic s/n, 08860 > Castelldefels, Spain > Room 1.02 > Tel : +34 93 645 29 12 > Fax : +34 93 645 29 01 > Email address: [EMAIL PROTECTED] > > ___ > 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] Fair shaping over link with variable parameters
On Sun, May 28, 2006 at 09:31:29PM +0200, Rafal Krypa wrote: > I am trying to construct following shaping solution: > * several users are using one link to the Internet > * all of them have equal priority and should be given fair amount of bandwidth > * no kind of traffic is considered more important than other > * our Internet connection has no CIR, only "maximum dl/ul speeds" given by > provider > * most important: our outgoing and incoming traffic must be shaped to some > rate > that will provide possibly low latency. For users that do not have active > connections I'd like to ensure no more than 100ms latency for ping or any > other low-traffic connections http://www.metamorpher.de/fairnat ...not what you're looking for probably, but as close as I could get to fair sharing. But then again, I only have (or rather, had) a small home network with a cheap, constant-rate dialup connection. > For several years of my experiments with traffic shaping over Linux I found > no > tool for creating such system. For example, HTB require given, constant > 'ceil' > parameter. I would like to have some qdisc that can automatically adjush its > rate/ceil parameter depending on achieved latency. How do you measure latency? Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: Fwd: [LARTC] HTB shaping & borrowing info
On Sun, May 28, 2006 at 02:04:57AM +0200, Stefano Mainardi wrote: > Like I said above, in the case that B is not producing traffic, 7/8 of the > 20 MB/s need to be assigned to A and the remaining 1/8 will remain to B. Well, reducing the ceil of A by 1/8 of B's bandwidth in the tree I posted earlier would do that. > Is possible, to change dynamically their band assignment? The bandwidth in HTB is dynamic, as classes are allowed to borrow bandwidth from other classes depending on their rate-ceil settings. In the tree I posted, the bandwidth behaviour is as follows: 10mbit will be reserved for C at all times, B can use up to 20mbit, A has 70mbit reserved, but can also use 20mbit of B if B is idle. If the borrowing/lending bandwidth between HTB classes is not dynamic enough for you, the only other option you have is to somehow externally delete/create new HTB classes on the fly, which is not a good solution in most situations. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: Fwd: [LARTC] HTB shaping & borrowing info
On Sun, May 28, 2006 at 12:11:10AM +0200, Stefano Mainardi wrote: > >> If B don't make traffic, 7/8 of 20Mb/s must be assigned to A and all the > >> rest at B > > Sorry, "all the rest at A" :) So, in other words, A is allowed to take bandwidth from B. B and C stick to their bandwidth limits. A tree like this could probably accomplish this: HTB qdisc | \--- HTB root class (100mbit) | \--- HTB class (90mbit|90mbit) || |\--- HTB class A (70mbit|90mbit) |\--- HTB class B (20mbit|20mbit) | \--- HTB class C (10mbit|10mbit) This way, C and B never borrow any bandwidth (as they have rate==ceil), and if A borrows, it will be from B, as the parent class (which has rate==ceil as well) will never borrow from C. > We have tested this script with CEIL=RATE, and CEIL=100Mbit, but i view that > the data-rate calculated for each PC is not proportional to the traffic > assigned at Firewall. HTB expects to be able to use the full specified rate at any point of time, so you probably should use something lower than 100mbit as a base value. Even in 100mbit networks, you never actually get this rate, due to overhead, collisions, etc. Other than that, are there really just these three classes of traffic going out on eth1? The setup should work, as long as the classification is working properly. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB shaping & borrowing info
On Sat, May 27, 2006 at 11:28:12PM +0200, Stefano Mainardi wrote: > The goal is to divide the traffic for classes of workstations, at example in > three classes, let say A, B and C. Sounds simple enough... > If B don't make traffic, 7/8 of 20Mb/s must be assigned to A and all the > rest at B Why would you assign traffic at B if it doesn't make traffic? > We have used CBQ and HTB, with poor succes. > Anybody can help me please? Post your HTB script and I (and probably others) will have a look at it. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Hi, a important doubt
In tcng you can use common comparators on "if", for example: if tcp_sport > 1000 && tcp_sport < 1200 tcng translates this to several u32 matches with masks for tc use, which is afaik the only way with tc to match a port-range. It may be easier to do this with iptables (although I dislike using two different interfaces for one purpose). Andreas Juan Felipe Botero wrote: > How can i put a port range in a tcng or tc configuration > > > >Does somebody know??? > > > >It´s important, cause i need to regulate the bandwidth from the TCP port > >1054 until TCP port 1200, how can i do that > > > > > ___ > 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] iptables CLASSIFY and MARK not working?
Have you checked that the ip_conntrack module is loaded or compiled into the kernel? If not the mark is lost... Cheers, Andreas Eliot, Wireless and Server Administrator, Great Lakes Internet schrieb: I have to match my packets based on MAC address, which I cannot do in the POSTROUTING chain, so I do it in PREROUTING using MARK. Then, I match on the MARK in the POSTROUTING chain to do a CLASSIFY. But this does not seem to work: wireless-r1 bwlimit # iptables -L -v -n -t mangle Chain PREROUTING (policy ACCEPT 3353K packets, 941M bytes) pkts bytes target prot opt in out source destination 12527 11M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore 3227 130K MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:05:9E:81:3D:07 MARK set 0x30 3231 132K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x30 CONNMARK save 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:05:9E:81:3D:07 multiport ports 53,4569,5060,1:2 MARK set 0x2f 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:05:9E:81:3D:07 multiport ports 22,23,53 MARK set 0x2f 3 180 MARK icmp -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:05:9E:81:3D:07 MARK set 0x2f 3222 129K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x18/0x10 MAC 00:05:9E:81:3D:07 MARK set 0x2f 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 MAC 00:05:9E:81:3D:07 MARK set 0x2f 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 MAC 00:05:9E:81:3D:07 MARK set 0x2f 10272 10M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x2f CONNMARK save 0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:05:9E:81:3D:07 ipp2p v0.8.0 --ipp2p MARK set 0x31 0 0 CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 MARK match 0x31 CONNMARK save Chain INPUT (policy ACCEPT 1177K packets, 165M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 1157K packets, 703M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 535K packets, 95M bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 1613K packets, 790M bytes) pkts bytes target prot opt in out source destination 3225 129K CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x2f CLASSIFY set 47:1 2 506 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x30 CLASSIFY set 48:1 0 0 CLASSIFY all -- * br1 0.0.0.0/0 0.0.0.0/0 MARK match 0x31 CLASSIFY set 49:1 6352 9321K CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x2f CLASSIFY set 47:1 4 1932 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x30 CLASSIFY set 48:1 0 0 CLASSIFY all -- * wivl4 0.0.0.0/0 0.0.0.0/0 MARK match 0x31 CLASSIFY set 49:1 wireless-r1 bwlimit # tc -s qdisc show dev wivl4 qdisc prio 5: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 11887911 bytes 8179 pkt (dropped 878, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc htb 26: parent 5:1 r2q 10 default 1 direct_packets_stat 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc htb 27: parent 5:2 r2q 10 default 1 direct_packets_stat 0 Sent 10657 bytes 162 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc htb 28: parent 5:3 r2q 10 default 1 direct_packets_stat 0 Sent 11877254 bytes 8017 pkt (dropped 878, overlimits 1120 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc htb 47: parent 26:1 r2q 10 default 1 direct_packets_stat 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc htb 48: parent 27:1 r2q 10 default 1 direct_packets_stat 0 Sent 10657 bytes 162 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc htb 49: parent 28:1 r2q 10 default 1 direct_packets_stat 0 Sent 11877254 bytes 8017 pkt (dropped 878, overlimits 1120 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 wireless-r1 bwlimit # tc -s class show dev wivl4 class prio 5:1 parent 5: leaf 26: class prio 5:2 parent 5: leaf 27: class prio 5:3 parent 5: leaf 28: class htb 26:1 root leaf 47: prio 0 rate 3Kbit ceil 3Kbit burst 16593b cburst 16593b Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 4532 ctokens: 4532 class htb 27:1 root leaf 48: prio 0 rate 6Kbit ceil 6Kbit burst 31590b cburst 31590b Sent 54187 bytes 790 pkt (dropped 0
Re: [LARTC] tc del class not working
I allways forget attachments. ;)
--- linux/net/sched/sch_hfsc.c~ 2006-01-15 07:16:02.0 +0100
+++ linux/net/sched/sch_hfsc.c 2006-05-10 00:07:07.0 +0200
@@ -970,14 +970,15 @@
{
struct hfsc_class *p;
unsigned int level;
-
+ int adj = 0;
do {
level = 0;
list_for_each_entry(p, &cl->children, siblings) {
if (p->level > level)
level = p->level;
+ adj = 1;
}
- cl->level = level + 1;
+ cl->level = level + adj;
} while ((cl = cl->cl_parent) != NULL);
}
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc del class not working
Hi, this is a bug in the sch_hfsc.c module, the level count doesn't get adjusted correctly. The following patch works for me, but is not a beauty and may be wrong. Andreas Eliot, Wireless and Server Administrator, Great Lakes Internet wrote: ... > Also, a quick test by hand shows that it is only from having a child > class assigned to it that it becomes un-deletable. ... > > This does not: > > wireless-r1 raddb # tc class add dev wivl4 parent 5:0 classid 5:56 hfsc > ls m1 1536.0Kbit d 2000ms m2 256.00Kbit ul m2 1024Kbit > > wireless-r1 raddb # tc class add dev wivl4 parent 5:56 classid 5:57 hfsc > sc umax 1500b dmax 30ms rate 80Kbit > > wireless-r1 raddb # tc class del dev wivl4 parent 5:56 classid 5:57 hfsc > sc umax 1500b dmax 30ms rate 80Kbit > > wireless-r1 raddb # tc class del dev wivl4 parent 5:0 classid 5:56 hfsc > ls m1 1536.0Kbit d 2000ms m2 256.00Kbit ul m2 1024Kbit > RTNETLINK answers: Device or resource busy ... ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] How to write a catch all rule?
http://mailman.ds9a.nl/pipermail/lartc/2005q3/016774.html Unga schrieb: Hi all I'm new to Qos and iproute2, but studied well the documentation. According to http://lartc.org/howto/lartc.qdisc.filters.html, catch all rule should be written as follows: tc filter add dev eth0 protocol ip parent 10: prio 2 \ flowid 10:2 But it doesn't work because filtertype is missing. Can somebody please kindly explain how to write a catch all rule? Many thanks in advance. Best Regards Unga __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] tc counters "problem"
On Sun, Apr 09, 2006 at 04:24:20PM -0300, Francisco wrote: > I expected that meassuring the root class I would get values similar that > the ones I get measuring the interface counters but they differ by a > large amount. The statistics you posted seem to be fine. Which interface counters are you talking about? tc starts counting only after the qdiscs/classes were created, so if you have a separate count somewhere which started counting some other time, the difference will of course be huge (as far as total packet count is concerned). Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] u32 and iptables do not work together
On Sat, Apr 08, 2006 at 03:18:01PM +0200, Piotr Chytla wrote: > On Sat, Apr 08, 2006 at 08:21:40AM -0300, Nataniel Klug wrote: > > I think it worked fine... This is my new script (below the text). I just > > dont know how can I know if this traffic is relly going to the class I > > send it... hehehehe... I am marking Skype packages using L7-Filter like > > this: > > > If you want to see packets in class you can use sch_log, quite good > module, you must attach it to class and you will see every packet > in this class in tcpdump. Or, without additional software, and a bit less of information, you could just have a look at the tc statistics. In case of mixed classes you can temporarily create an extra class for the packets you want to test filters on. If packets go into this class and it's the same number as are marked by iptables, the classification works. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] u32 and iptables do not work together
On Fri, Apr 07, 2006 at 03:26:00PM -0300, Nataniel Klug wrote: > RTNETLINK answers: Invalid argument > We have an error talking to the kernel This message usually translates to: 'tc understood your syntax just fine, and tried to tell the kernel about it, but the kernel did not understand, most likely because it does not support this feature.' Do you have 'Netfilter marks support' enabled? (Just a guess, may be a different setting) Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Tocken Bucket with priority?
On Wed, Apr 05, 2006 at 03:18:06PM +0200, Emanuele Colombo wrote: > Hi. I'm trying to get a traffic shaper like this: > > > -- > VoIP pkts-->||_| > -- \ | > ---O -> > -- / > Data pkts-->| > -- > > In this shaper voip packets are in a different queue than any other kind of > packet. I want a data packet to be served only when no packets are in the > voip queue (when voip queue is empty). > Furthermore the total traffic that leaves this shaper needs to be limited to > a specific (and precise) value of bandwidth, like a token bucket. > > > I can't use something like this (PRIO + TBF) because in this way when "data > congestion" happens, voip packets may be lost too(packet drop appens on the > TBF queue): > > -- > VoIP pkts-->| |_| > -- \ -| > O --->|---O -> > -- / - > Data pkts-->| > -- > > I also can't use HTB because it doesn't provide a priority mechanism like my > needs, and CBQ because his bandwidth limiting algorithm isn't very precise > (according to the documentation). What about using HTB and *then* using PRIO as its leaf class? You would use HTB only to shape. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] How to define class type hierarchy of speeds?
On Thu, Mar 30, 2006 at 01:17:00AM +0200, Beat Meier wrote: > What I want now is that for example in "class" 128Kbps the ip > 10.0.0.5, 10.0.0.8 etc. goes BUT every ip adress will have 128Kbps. > The same for 256Kbps. > 128Kbps > |_ 10.0.0.5 > |_ 10.0.0.8 > > 256Kbpss > |_ 10.0.0.6 > |_ 10.0.0.7 I don't know if such a scheduler exists. With HTB, you could do it, but you would have to create a separate class per user. Which is not that much different from what this scheduler would do, as it has to keep track of every single IP's bandwidth either way. > Do I have to do it like in example 15.1 (Cookbook) in the howto i.e. > if I have 1000 ip addresses they are all flat there in? Example 15.1 seems to be based on CBQ. I did not have much luck with this scheduler myself. But as far as I know, it also would require you to create one separate class per user. > What I have noticed there are a lot of example but always with 2 different > speeds but no one with customers of the same speed, same queueing disiplines > but should not share the bandwidth but have each one the full speficied > bandwidth. I do not know such a script, since I'm doing traffic shaping for home use only. If you're looking for a script that does not primarily work by prioritizing traffic classes, but which works on a per-user basis, you could have a look at my own script. (http://www.metamorpher.de/fairnat) That is if you're willing to regard my former flatmates as customers and my former linux-based old PC router as high-end internet gateway. The script will by far not be flexible enough for a project of your scale, but at least it's user based and I put some effort into documenting it, so maybe it will be useful as an example to you. Kind regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Please help - totally confused (NAT + FWMARK + IMQ + HTB)
On Tue, Mar 28, 2006 at 10:07:36AM +0200, Jan Rovner wrote: > 1. There is a router connected to the internet line via interface eth0 That's fine. > 2. There are users connected to the router via two interfaces : eth1 and > wlan0 Two possibilities come to mind: a) If you can provide two completely separate bandwidth pools, you can use one HTB qdisc per device. b) Otherwise you have to use a virtual device, for example IMQ. > 3. All users are assigned private IP addresses (192.168.1.xxx on eth1, > 192.168.2.xxx on wlan0) That's fine. > 4. The number of public IP addresses is limited, so the router does SNAT > (and for some users having assigned a public IP address also DNAT) More than one public IP address, but only one physical line, right? That seems to be fine. > 5. For the traffic classification I need to use iptables (and MARK > target) > 6. For the traffic shaping, I need to use HTB > 7. Each user has only one IP address and should have allocated some > upload and download bandwitdh > 8. I need to get both UPLOAD and DOWNLOAD shaping, based on user's > private address Alright, judging from your description, it should be possible to do things that way. > Please can someone post me some *really working* script for that? Or at > least tell me, where is my fault? I think it could be in sequence of > iptables calls, POSTROUTING/PREROUTING misunderstanding, etc... I don't have a working script for exactly that; mine uses just one interface on the download side and only one public IP. But it distributes bandwidth on a per-user basis using HTB. I've also put some effort into documenting it, so maybe it can serve as an example: http://www.metamorpher.de/fairnat/ > # setup IMQ > ip link set imq0 up > ip link set imq1 up Since I'm not using IMQ myself, I'm not sure about this part, but why are you using two devices? imq0 seems fine, but imq1 looks wrong to me. I would do the upload shaping on your internet device (eth0) directly. About your script, depending on what is working and what is not, you can debug it by doing the following: - verify that the iptables rules match the packets you want it to match. For example, iptables can list you the rules it is using as well as counters for them. Or you could add some logging rules. If the packets are not matched, and thus not getting marked, your shaping can not work. - verify that the packets go in the HTB classes you want them to go. This can probably be done by using HTB statistics (tc -s -d qdisc/class show ...). If you can describe in more detail what is (not) working about your script, maybe I can give you some better hints. Just by glancing at a script without knowing what is wrong it's hard to give recommendations. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb and priorizing class
On Fri, Mar 24, 2006 at 04:56:44PM +0100, Fabio wrote: > Is this a configuration problem? > > Also, when I set tc rules I get: "quantum of class is big. Consider r2q > change" Well, that message can be avoided by configuring quantum properly (not always possible if difference between rates is too huge) or by setting r2q for each class manually. For more about quantum & r2q, see for example: http://www.docum.org/docum.org/faq/cache/31.html This may fix your problem or not, if it doesn't, can you post the tc commands you're using? Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Fix list so it adds Reply-To: header
On Wed, Mar 15, 2006 at 04:57:54PM -0500, Jody Shumaker wrote: > Could whomever is in charge of the lartc mailing list please change it > to add the header: > Reply-To: lartc@mailman.ds9a.nl > > Every other list I'm on is setup so that by default replies will go to > the list. When replying to lartc emails I notice myself and others > constantly forgetting this list does not behave like the rest, and > that we have to either do a reply-to-all, or manually enter in the to > address. I'm on several mailing lists as well, but none of them has such a Reply-To setting. The list has proper list headers such as: List-Id: "Mailinglist of the Linux Advanced Routing & Traffic Control project" List-Post: <mailto:lartc@mailman.ds9a.nl> etc... Some mailing programs offer a 'Reply to list' function that respects these mailing list headers and thus will send a reply to the list only. Also, I do not mind getting direct replys in addition to what goes over the list, actually I even do group replies on purpose, because the list does not always work reliably. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] multipath algorithm
On Wed, Mar 15, 2006 at 04:22:06PM +0100, Eduardo Fernández wrote: > Seems really interesting, I also noticed this in kernel sources but I > didn't try it since I didn't see it in any howtos out there. I'm using > load balancing with Julian's patch for 5 dsl lines but I will be > adding 20 more in short, so I may try out this. BTW Julian's patch > didn't work for me with 2.6 kernel, but it did with 2.4.29. I never used those patches. For me, not being included in the mainstream kernel for all those years has to mean something is broken somewhere. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] negative token/ctokens
In this simple htb setup: # tc -s -d class ls dev eth0 class htb 1:1 root rate 30bit ceil 30bit burst 1749b/8 mpu 0b overhead 0b cburst 1749b/8 mpu 0b overhead 0b level 7 Sent 13171835 bytes 13169 pkt (dropped 0, overlimits 0 requeues 0) rate 45848bit 10pps backlog 0b 0p requeues 0 lended: 5272 borrowed: 0 giants: 0 tokens: -84429 ctokens: -84429 class htb 1:2 parent 1:1 prio 0 quantum 1500 rate 8bit ceil 30bit burst 1639b/8 mpu 0b overhead 0b cburst 1749b/8 mpu 0b overhead 0b level 0 Sent 12243472 bytes 8787 pkt (dropped 0, overlimits 0 requeues 0) rate 43264bit 6pps backlog 0b 0p requeues 0 lended: 3515 borrowed: 5272 giants: 0 tokens: -181860 ctokens: -86779 class htb 1:3 parent 1:1 leaf 30: prio 0 quantum 2750 rate 22bit ceil 30bit burst 1709b/8 mpu 0b overhead 0b cburst 1749b/8 mpu 0b overhead 0b level 0 Sent 928363 bytes 4382 pkt (dropped 0, overlimits 0 requeues 0) rate 3400bit 4pps backlog 0b 0p requeues 0 lended: 4382 borrowed: 0 giants: 0 tokens: 61291 ctokens: 46039 class prio 30:1 parent 30: class prio 30:2 parent 30: class prio 30:3 parent 30: What does it mean when the leaf 1:2 class has a negative token/ctoken count? I'm generating this traffic with a "wget --limit-rate=5000" command. My understanding is that this indicates the number of tokens available for burst traffic, is that correct? How did it become negative? I thought that when the bucket is empty, traffic is delayed until a token shows up, or eventually dropped. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] multipath algorithm
I've been reading about multipath routes and found something that no howto I
saw mentioned so far: multipath algorithms.
The kernel has the followings:
# zgrep MULTIPATH_ /proc/config.gz
CONFIG_IP_ROUTE_MULTIPATH_CACHED=y
CONFIG_IP_ROUTE_MULTIPATH_RR=m
CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m
CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m
CONFIG_IP_ROUTE_MULTIPATH_DRR=m
CONFIG_DM_MULTIPATH_EMC
iproute2 also has support for these (at least, it passed them forward to the
kernel):
static char *mp_alg_names[IP_MP_ALG_MAX+1] = {
[IP_MP_ALG_NONE] = "none",
[IP_MP_ALG_RR] = "rr",
[IP_MP_ALG_DRR] = "drr",
[IP_MP_ALG_RANDOM] = "random",
[IP_MP_ALG_WRANDOM] = "wrandom"
};
The "ip route add" option is "mpath". I quickly tried with an adsl modem on
ppp0 and dialup one on ppp1 and using drr seems to have worked, tcpdump
showed locally originated traffic going out both interfaces.
Anybody else tried these and care to comment?
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Is this possible?
On Mon, Mar 06, 2006 at 10:53:13AM +1000, Russell Stuart wrote: > I can verify it doesn't. I have implemented this in real > life, and the class is limited to the "rate". Thanks for pointing it out. > The revised class structure is now: > > htb class parent 1: classid 1:10 rate 80% ceil 100% > htb class parent 1:10 classid 1:11 rate 100% ceil 100% > htb class parent 1:11 classid 1:19 rate 30% ceil 100% prio 0 [VOIP leaf] > htb class parent 1:10 classid 1:20 rate 70% ceil 100% > htb class parent 1:20 classid 1:21 rate 20% ceil 100% prio 1 [interactive > leaf] > htb class parent 1:20 classid 1:22 rate 50% ceil 100% prio 2 [other leaf] Interesting analysis, although it kind of defies my HTB logic (which is just an inaccurate model). If the 1:10 class is limited to the rate as you said above (which would be 80%), how can a child class have a rate of 100%? I still don't understand what to make of a root class with different rate / ceil settings. It's either limited to rate, or to ceil all the time; if it isn't, it decides to jump over it's rate under which circumstances? Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ATTN Andreas Klauer: ASCII art + comments, please?
On Sun, Mar 05, 2006 at 02:33:17PM -0800, gypsy wrote: > Since I understand your ASCII art and comments, I would very much > appreciate it if you would draw what you see and criticize the > following. Hopefully I'll better understand after that! Uh, right. Don't take anything I say for granted, though. > tc qdisc add dev imq0 root handle 1: htb default 20 > > tc class add dev imq0 parent 1: classid 1:2 htb rate 4522kbit ceil \ >4760kbit burst 16k cburst 16k quantum 1500 > > tc class add dev imq0 parent 1:2 classid 1:1 htb rate 4522kbit ceil \ >4760kbit burst 16k cburst 16k > > tc class add dev imq0 parent 1:1 classid 1:10 htb rate 2487kbit \ >ceil 4760kbit burst 16k cburst 16k quantum 1500 prio 1 > > tc class add dev imq0 parent 1:1 classid 1:20 htb rate 2034kbit \ >ceil 4341kbit burst 10k cburst 16k quantum 1500 prio 4 First, here is what I see: 1: HTB root qdisc (default 20) | \--- 1:2 HTB root class (4522kbit/4760kbit) | \--- 1:1 HTB class (4522kbit/4760kbit) | \--- 1:10 HTB leaf class (2487kbit/4760kbit) \--- 1:20 HTB leaf class (2034kbit/4341kbit) Now on to the criticising; the root class has a higher ceil than rate. However, different rate/ceil makes only sense if there is someone to borrow bandwidth from, which is not the case here. The root class acquires bandwidth directly from the QDisc, which has unlimited resources, as the root class itself is supposed to be the limiting factor. So what you have here should practically be no different from a 4760kbit class. The 1:1 class seems to be useless; it has exactly the same settings as it's parent, except for quantum, which is not explicitely set. Furthermore, it does not have any siblings. Does not make sense to me as such a class will just use exactly the same rate as it's parent. Compare the statistics of these two classes below. > class htb 1:1 parent 1:2 rate 4522Kbit ceil 4760Kbit burst 16Kb cburst > 16Kb > Sent 7826237 bytes 27128 pkts (dropped 0, overlimits 0) > rate 1728bit 4pps > lended: 1954 borrowed: 0 giants: 0 > tokens: 39532 ctokens: 37555 > > class htb 1:2 root rate 4522Kbit ceil 4760Kbit burst 16Kb cburst 16Kb > Sent 7826237 bytes 27128 pkts (dropped 0, overlimits 0) > rate 1728bit 4pps > lended: 0 borrowed: 0 giants: 0 > tokens: 39532 ctokens: 37555 As for the leaf classes, their rates are fine (add up to the parent class rate), except that the parent actually can use 4760kbit rate rather than 4522kbit. Their priorities are questionable; using 1 and 4 here should not be any different from 1 and 2 or 3 and 6 or 0 and 1. It's one high- and one low-priority class either way. I would probably set a priority just for the low priority class, so that it becomes more obvious what is intended by this setting here. That what you wanted? Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Balancing multiple connections and NAT
Em Qui 23 Fev 2006 20:41, Markus Schulz escreveu: > you need a patch for NAT processing with multiple gateways. this will > then save the routing information for each connection inside NAT > structures, so that each packet of an established connection will be > get routed over the same gateway. you can find the patches here: > http://www.ssi.bg/~ja/#routes > please read the guides (nano howto or dgd-usage) carefully. Any idea why these patches are not yet integrated into the upstream kernel? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Is this possible?
On Sun, Mar 05, 2006 at 01:43:11PM +1000, Russell Stuart wrote: > HTB Class structure the implements this: > > htb class parent 1: classid 1:10 rate 80% ceil 100% To my understanding, a root class that has a higher ceil than rate can always use bandwidth up to it's ceil. Thus it would be more correct to set the rate to 100% here (whatever that is) as well. > htb class parent 1:10 classid 1:11 rate 30% ceil 100% > htb class parent 1:11 classid 1:19 rate 30% ceil 100% prio 0 [VOIP leaf] If class 1:19 is the only child of class 1:11, it can always use whatever bandwidth the parent class can get. So the parent class does not have any limiting factor here and you can just skip it and attach 1:19 to 1:10 directly. > htb class parent 1:10 classid 1:20 rate 70% ceil 80% > htb class parent 1:20 classid 1:21 rate 20% ceil 80% prio 1 [interactive > leaf] > htb class parent 1:20 classid 1:22 rate 50% ceil 80% prio 2 [other leaf] > > This is the small class tree I can think of that does it. The only difference to the tree before is that you grouped all non-voip traffic under a separate parent class which is capped at 80%, so voip always has 20% of available bandwidth which can not be taken away from it, right? If that was your intention, then it's fine. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Patch to allow for the ATM "cell tax"
On Fri, Mar 03, 2006 at 01:45:31PM -0500, Jason Boxman wrote:
> Andreas Hasenack said:
> > On Fri, Mar 03, 2006 at 11:18:00AM -0500, Jason Boxman wrote:
> >> On Friday 03 March 2006 08:43, Andreas Hasenack wrote:
> >> > On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote:
> >> > > Any chance something like this can be applied to q_tbf? It's been
> classful for a while and I find a tbf with a prio under it works
> quite well for my
> >> >
> >> > tbf qdisc is classfull?
> >>
> >> It has been since like 2.6.9, yes. I was as surprised as you, but I use it
> >> with a leaf prio all the time and have for a year now.
> >
> > If this is correct, then the docs are really in bad shape. They are not
> only outdated, but just plain wrong in many cases.
>
> Yes.
>
> > But tbf is still not your regular classfull qdisc, or I'm missinterpreting
> things:
>
> tc qdisc add dev eth0 root handle 1: tbf rate ${RATE}kbit \
> burst 1600 limit 1
> tc qdisc add dev eth0 parent 1:1 handle 2: prio bands 4
> tc qdisc add dev eth0 parent 2:1 handle 10: pfifo limit 10
> tc qdisc add dev eth0 parent 2:2 handle 20: pfifo limit 10
> tc qdisc add dev eth0 parent 2:3 handle 30: pfifo limit 10
> tc qdisc add dev eth0 parent 2:4 handle 40: tbf rate \
> $(($RATE-32))kbit burst 1600 limit 1
> tc qdisc add dev eth0 parent 40:1 handle 33: sfq perturb 1
>
> But, you're right. Classful is probably the wrong way of saying it.
>
> Perhaps I meant you can attach a different queueing disipline besides using
> tbf. It's more like tbf has a nested bfifo attached, which you can replace
> with anything you want since around 2.6.9.
>
> I guess I'm used to using prio and tbf, where you can attach various leaf
> qdiscs and have more leaf qdiscs attached. It's certainly not the same
> thing as cbq, htb, or hfsc. Oops. My bad.
Thanks for the example and the explanation, it was very helpful. It also
means I can try new things :)
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Patch to allow for the ATM "cell tax"
On Fri, Mar 03, 2006 at 11:18:00AM -0500, Jason Boxman wrote: > On Friday 03 March 2006 08:43, Andreas Hasenack wrote: > > On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote: > > > Any chance something like this can be applied to q_tbf? It's been > > > classful for a while and I find a tbf with a prio under it works quite > > > well for my > > > > tbf qdisc is classfull? > > It has been since like 2.6.9, yes. I was as surprised as you, but I use it > with a leaf prio all the time and have for a year now. If this is correct, then the docs are really in bad shape. They are not only outdated, but just plain wrong in many cases. But tbf is still not your regular classfull qdisc, or I'm missinterpreting things: # tc qdisc add dev eth0 handle 1: root tbf rate 300kbit burst 10k latency 10ms # tc class add dev eth0 classid 1:1 parent 1: tbf Error: Qdisc "tbf" is classless. or # tc qdisc add dev eth0 handle 1: root tbf rate 300kbit burst 10k latency 10ms # tc class add dev eth0 classid 1:1 parent 1: prio Error: Qdisc "prio" is classless. I'm using iproute2-2.6.15 and kernel-2.6.12 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Patch to allow for the ATM "cell tax"
On Thu, Mar 02, 2006 at 07:27:13PM -0500, Jason Boxman wrote: > Any chance something like this can be applied to q_tbf? It's been classful > for a while and I find a tbf with a prio under it works quite well for my tbf qdisc is classfull? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] counter-strike
On Thu, Mar 02, 2006 at 08:17:43PM +0200, Sorin Panca wrote: > I've made a test. I've added > 1: 1:1 --- 10: > htb class sfq If that SFQ is the standard sfq with a queuelength of 128 packets, it might be responsible for some of the delay. Unless you have connections in there that can choke the whole bandwidth (probably possible with CS if you set the rates up, I don't know), you may not need SFQ for interactive bands at all. > People in my LAN play almost exclusively in MAN, not in the Internet. I > allocated such high bandwidth because htb would allocate the spare based > on classes' rates ratios. And since 1:1 is a root class as 1:2 and 1:3 > (MAN and Internet respectively) it had to have such a rate even if it is > not found in my real bandwidth. I don't think I follow your explanation here. How do you expect HTB to guarantee a rate for a class (that's what it claims to do) when there is no bandwidth to back it up. I've never dealt with MANs before, so I may be completely wrong. Usually you should not have more than one root class, and you should not let HTB think it can use more bandwidth than there actually is. It's extremely hard to understand the logic behind setups like this and therefore likely to get unexpected results from them. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] counter-strike
On Thu, Mar 02, 2006 at 01:45:01PM +0200, Sorin Panca wrote: > ___ > > > 1:--+1:1 - [ counter-strike & icmp ] rate=1Mbit; ceil=1Mbit; > | prio 0; (u32 filter by ports) > | > |1:2 - [ Internet ] rate=1.5Mbit; ceil=rate; prio 1; > | | (RNR=rate) RNR = Root iNet Rate > | | > | |---1:20 - [ normal traffic ] rate=90% of $RNR; ceil=$RNR; > | | prio 0; (u32 filter by ports) > | | > | \---1:21 - [ p2p traffic ] (default class) rate=1kbit; > |ceil=90% of $RNR; prio 1 > | > |1:3 - [ MAN ] rate=1Mbit; ceil=10Mbit-$RNR; prio 1 > | | (RMC=ceil) RMC = Root MAN Ceil > | | MAN destinations are marked with 0x1 Marker > | | > | |---1:30 - [ normal traffic ] > | |rate=500kbit;ceil=($RMC-$RNR-1)kbit; > | |prio 0; (u32 filter by ports AND fw mark) > | | > | \---1:31 - [ p2p traffic ] rate=1kbit; ceil=($RMC-$RNR-1)kbit; > |prio 1; (u32 filter by fw mark) > | > \1:4 - [ LAN ] rate=89Mbit; ceil=89Mbit > > I assume that CS actually goes out to Internet and/or MAN, depending on the location of the server. I would make one CS class for each. Otherwise you may have 1MBit CS (which goes out to Internet) plus 1.5MBit Internet, which will work only if you got 2.5MBit Internet guaranteed in total. Likewise with MAN. Unless you really got that much bandwidth, this setup will not give you any good results at all. You could also use PRIO qdisc as a child to the HTB Internet / MAN classes to give CS absolute priority over HTTP over P2P. This approach worked very well for me and my flatmates, also for gaming. But that's on a way slower line and without Internet/MAN distinction, so we've been happy with 200ms (versus 1000-5000ms when unshaped) pings. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Htb queueing problem
On Wed, Mar 01, 2006 at 02:48:18PM +, Andy Furniss wrote: > than bulk. Also remember when setting rates that htb will see ip packets > as ip length + 14 when used on ethX Could you elaborate on this a bit? I suppose you also meant this in an earlier message when you mentioned that the overhead was not included in the bw calculations. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc filter can target only leaf classes?
Em Sáb 25 Fev 2006 08:43, Andy Furniss escreveu: > > Why does the filter stop working? I was expecting it to keep working and > > then I could further filter this traffic into 1:30 and 1:40 *at* 1:10. > > You need other filters with parent 1:10 to send to leafs below 1:10 Thanks, that was (part of) it. I had tested with other filters on 1:10, but the problem was the filters themselves which were not correct. Just for the record, I was using iptables MARK target to first mark packets going to a host and then attempting to set another mark on 1:10 on the same packets depending on the destination port so they would be sent to 1:30 or 1:40. I now tested with u32 on 1:0 sending traffic to 1:10 and with fw on 1:10 sending packets to 1:30 and 1:40 using the iptables mark and it's working just fine. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] why isn't 1:1 getting the traffic? [filter question]
On Fri, Feb 24, 2006 at 06:19:53PM -0300, Andreas wrote: > >This was fairly obvious looking at your tc statistics output, where it > >lists both 1:1 and 1:2 as roots with no parent. There can only be one > >valid root class. > > Why? I need two virtual circuits. I don't want the 90mbit class > interfere with the 200kbit class: no lending, no borrowing. I think there can be more than just one root class - the question is just wether it makes sense or not. I prefer using one root class - after all, you only got one interface, and you have to make sure that you do not exceed the total interface capacity. Therefore, the root class is the interface limiter. You can add isolated circuits to that root class easily; as long as all child classes of the root class have the same rate and ceil, no lending or borrowing between them will be done, simply because it is not necessary. This way you get your desired features plus an overview on how much rate the physical interface actually has to offer - from my point of view, that's a win-win situation. > It actually works if I use a *leaf* class as the target of the filter > (see my subsequent email). But this contradicts the documentation, which > even mentions one could gain speed by adding further filters to other > classes besides a root one. I never got filters to work that do not point to leaf classes. Wether it is possible at all or not, I do not know. Maybe it was planned and turned out to be too complicated - maybe it is implemented but not working due to some undiscovered bug. I'm too lazy to look at the code right now. I usually end up using iptables for classification; I find it to be far more userfriendly than the tc filters, and you can group filters any way you want. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] why isn't 1:1 getting the traffic? [filter question]
Jody Shumaker wrote: tc qdisc del dev eth0 root > /dev/null 2>&1 tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:1 parent 1: htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1: htb rate 90mbit ceil 90mbit quantum 1500 You're defining 2 root classes to the HTB qdisc, while it should possibly have given an error, it seems to instead just put the first one, 1:1, into a state of limbo where its never used. This was fairly obvious looking at your tc statistics output, where it lists both 1:1 and 1:2 as roots with no parent. There can only be one valid root class. Why? I need two virtual circuits. I don't want the 90mbit class interfere with the 200kbit class: no lending, no borrowing. Should really set it up something like this with one main root: tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:0 parent 1: htb rate 90100kbps ceil 90100kbps quantum 1500 tc class add dev eth0 classid 1:1 parent 1:0 htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1:0 htb rate 90mbit ceil 90mbit quantum 1500 Then I imagine your tc filter would actually work. It actually works if I use a *leaf* class as the target of the filter (see my subsequent email). But this contradicts the documentation, which even mentions one could gain speed by adding further filters to other classes besides a root one. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] tc filter can target only leaf classes?
(using htb) I'm trying to learn tc filter and it seems the flowid parameter can only point to leaf classes. Actually, it can point anywhere, but it doesn't seem to work unless it points to a leaf class. Is this correct? For example, I have this tree: eth0 | +--1:---+ | | +--1:101:20 | | | 1:301:4020: | | 30: 40: 1: is htb qdisc, with default pointing to minor 20. And this filter: iptables -t mangle -A OUTPUT -d $DSTHOST -j MARK --set-mark 1 tc filter add dev $DEV parent 1:0 prio 1 protocol ip \ handle 1 \ fw \ flowid 1:10 Now, I only see 1:10 getting the traffic if 1:30 and 1:40 don't exist. The moment I add 1:30, 1:40 and their qdiscs, the above filter stops working and this same traffic starts going to 1:20, which is the default set at 1:'s qdisc. Why does the filter stop working? I was expecting it to keep working and then I could further filter this traffic into 1:30 and 1:40 *at* 1:10. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] why isn't 1:1 getting the traffic? [filter question]
With the below script, whenever I ping 10.0.16.10 (which matches the only filter I have), traffic still get's sent to the default 1:2 class instead of 1:1 and I don't know why... Any hints? (kernel 2.6.12, iproute2-2.6.15) tc qdisc del dev eth0 root > /dev/null 2>&1 tc qdisc add dev eth0 handle 1: root htb default 2 tc class add dev eth0 classid 1:1 parent 1: htb rate 100kbps ceil 100kbps quantum 1500 tc class add dev eth0 classid 1:2 parent 1: htb rate 90mbit ceil 90mbit quantum 1500 tc qdisc add dev eth0 handle 2: parent 1:2 sfq perturb 10 tc class add dev eth0 classid 1:10 parent 1:1 htb prio 0 rate 30kbps quantum 1500 tc qdisc add dev eth0 handle 10: parent 1:10 sfq perturb 10 tc class add dev eth0 classid 1:11 parent 1:1 htb prio 0 rate 70kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 20: parent 1:11 sfq perturb 10 tc class add dev eth0 classid 1:12 parent 1:1 htb rate 60kbps ceil 100kbps quantum 1500 tc qdisc add dev eth0 handle 30: parent 1:12 sfq perturb 10 tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 \ match ip dst 10.0.16.10/32 \ flowid 1:1 Status after pinging 10.0.16.10 a few times (notice traffic on 1:2, but not on 1:1): qdisc htb 1: r2q 10 default 2 direct_packets_stat 0 ver 3.17 Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 2: parent 1:2 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 10: parent 1:10 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 20: parent 1:11 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc sfq 30: parent 1:12 limit 128p quantum 1514b flows 128/1024 perturb 10sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 class htb 1:11 parent 1:1 leaf 20: prio 0 quantum 1500 rate 56bit ceil 80bit burst 1669b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 24429 ctokens: 17408 class htb 1:1 root rate 80bit ceil 80bit burst 1699b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 7 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 17408 ctokens: 17408 class htb 1:10 parent 1:1 leaf 10: prio 0 quantum 1500 rate 24bit ceil 24bit burst 1629b/8 mpu 0b overhead 0b cburst 1629b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 55636 ctokens: 55636 class htb 1:2 root leaf 2: prio 0 quantum 1500 rate 9Kbit ceil 9Kbit burst 12836b/8 mpu 0b overhead 0b cburst 12836b/8 mpu 0b overhead 0b level 0 Sent 516 bytes 7 pkt (dropped 0, overlimits 0 requeues 0) rate 8bit 0pps backlog 0b 0p requeues 0 lended: 7 borrowed: 0 giants: 0 tokens: 1164 ctokens: 1164 class htb 1:12 parent 1:1 leaf 30: prio 0 quantum 1500 rate 48bit ceil 80bit burst 1659b/8 mpu 0b overhead 0b cburst 1699b/8 mpu 0b overhead 0b level 0 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 28329 ctokens: 17408 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change
On Thu, Feb 23, 2006 at 11:42:16PM -0300, Luciano Ruete wrote: > That's becouse the _real_ scenario will look like this: > > root->parent_all_hosts->client_host_1->prio > ->dfl [...] > ->client_host_N->prio > ->dfl Oh, okay, so you simplified it that way. All right. > As you see, after 3 minutes the lower rate class has sent 3000 packets vs > 1000 > packets from the high rate one. Don't know what to think... There may be a misunderstanding between us, the way you modified your class tree now, it seems to have errors. I'll explain below. > My test bed at this moment is a gentoo Right. No complaints here. ;-) > with vde_switch daemon listening in a tuntap device. > I suppose that htb is device independet, i hope it does not matter. I don't have any experience with vde_switch and tuntap's (I don't even know what those are, so much for ignorance). The only device-dependent factor I came across with HTB so far is the overhead problem - not all devices have the same overhead (PPP over Ethernet or whatever). So HTB calculating the rate incorrectly is a possibility. It can be tuned using overhead/mpu parameters, however in order to do that, you'd need to know correct values first, and they can be a little hard to come by. I also doubt it's the cause of your problem in this case. > class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate 23000bit > ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead > 0b level 0 > class htb 1:7004 parent 1:7000 leaf 7004: prio 1 quantum 1500 rate 207000bit > ceil 23bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead > 0b level 0 > class htb 1:7000 root rate 256000bit ceil 256000bit burst 12Kb/8 mpu 0b > overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 7 The problem with this tree is that you took out the client class (the one with rate and ceil 23bit). When I said that child classes without siblings don't make sense, I didn't mean to actually take out the child class, but rather take out the parent of this child class; in your example that would mean making the 23bit class the root class. In your setup now, by just looking at the class tree, not the statistics, my guess would be that while each leaf class has a ceil of 23bit, they won't share the same 23kbit, but rather utilize the full 256kbit of their parent. That does not seem to be what you want. It still does not explain the rates in this setup, too. Especially the rate of the parent class seems low - if this is a testing environment where you are filling out the classes to their maximum, it's really odd that the parent class does not use it's full bandwidth. On the other hand, I don't know how accurate the rate statistics of HTB are. I don't have access to a properly working shaping setup right now to verify wether it's the same on my setup. If it isn't, I'd probably check first how much rate HTB can actually use, because it's a very bad situation for HTB when it thinks it can use more bandwidth than the link actually can guarantee. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] userlevel should not need to know about HZ?
Em Qui 23 Fev 2006 19:47, Andreas Klauer escreveu: > > So, how do we reliably calculate the minimum value for > > buffer/burst/maxburts? > > Trial & Error, not that I ever had much luck with TBF though... From my experiments, the minimum seems to be either MTU plus a few bytes or the result of rate/HZ, whichever is higher. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] userlevel should not need to know about HZ?
On Thu, Feb 23, 2006 at 05:21:46PM -0300, Andreas Hasenack wrote: > Kernel people tell me users should never need to know the value of HZ > used by the currently running kernel. One kernel hacker even told me > that Linus once changed the value from 100 to 1000 just to see user > space programs break. Hmmm. Don't know the context of this statement, but from my (naive) point of view, TBF is not a user space program. The user space program is tc, and it just sets up structures in the kernel once. The shaping itself is done in kernel space. > So, how do we reliably calculate the minimum value for buffer/burst/maxburts? Trial & Error, not that I ever had much luck with TBF though... TBF doesn't really depend on the HZ value - you don't really need to know. Still, TBF is affected by the HZ, like many other parts of the kernel too. It can't be helped - dunno what else to say about it. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB: far unequal behaivor at a slight conf rate change
On Thu, Feb 23, 2006 at 07:08:27PM -0300, Luciano Ruete wrote: > root->parent_all_host(256,256)->client_host_1(X,X)->host_1_prio(X*0.9,X) > ->host_1_dfl(X*0.1,X) What's the purpose of the 256kbit class? In the setup you posted, the 200/230kbit child class does not seem to have any siblings. Except for the root class, classes without siblings don't make sense. At least, I haven't seen any useful purpose for them so far. > I've attached simplified ad-hoc scripts that reproduce the scenarios: > tc_at_200 (full tc/iptables commands to recreate the X<200 scenario) > tc_at_230 (full tc/iptables commands to recreate the X>200 scenario) I haven't tested them, but they seem to be all right (except for the question above). I don't know if it will help at all, but could you post tc statistics for both 200 and 230 cases? You can get the statistics using 'tc -s -d qdisc/class show dev $iface' or similar command. Also, did you check wether HTB is complaining about anything in dmesg when setting up the 230 class tree? Which kernel version and iproute/tc version are you running? Just in case you're still suffering from old HTB bugs... Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] userlevel should not need to know about HZ?
Kernel people tell me users should never need to know the value of HZ used by the currently running kernel. One kernel hacker even told me that Linus once changed the value from 100 to 1000 just to see user space programs break. However, it is needed for the buffer parameter in TBF. The tc-tbf(8) manpage: If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket. The mini- mum buffer size can be calculated by dividing the rate by HZ. My kernel (2.6.12), for example, doesn't have a CONFIG option in /proc/config.gz. I only found out the correct HZ value by looking into /usr/include/asm/param.h, and even there are two values: 1000 for __KERNEL__ and 250 for the rest. Newer kernels have CONFIG options and 1000 is just one of the possible values. So, how do we reliably calculate the minimum value for buffer/burst/maxburts? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] 1k: 1000 or 1024?
The docs[1][2] suggest it's 1024, but tc says something else: # tc qdisc add dev eth0 root tbf rate 1kbps latency 50ms burst 1500 # tc -s qdisc ls dev eth0 qdisc tbf 8009: rate 8000bit burst 1499b lat 48.8ms ^^^ Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 If 1k were 1024, then I would have 8192bit above. 1. http://www.docum.org/docum.org/faq/cache/74.html 2.http://ds9a.nl/2.4Networking/howto/lartc.qdisc.html#LARTC.QDISC.EXPLAIN ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: Fwd: [LARTC] ipp2p don't block Ares
On Thu, Feb 23, 2006 at 12:12:16PM -0300, Roberto Pereyra wrote: > How I can dump Ares packages ? There are a number of tools for this, for example tcpdump. You should really talk to the developer(s) about this, it depends on what they need. Dumping Ares packets specifically is a bit hard, since it seems that you can't match them - so you'd have to dump everything. You can increase the probability of getting Ares packages in a dump by doing this on an empty link that contains nothing but Ares traffic, or by similar criteria (e.g. dump packets of IPs that do nothing but Ares). Anyway, contact the author and see what he suggests. Most likely only the packets that open a connection are of interest. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ipp2p don't block Ares
On Thu, Feb 23, 2006 at 09:26:48AM -0300, Roberto Pereyra wrote: > This bridge works fine buts since two weeks can't block Ares traffic. All > protocols block fine but Ares not (upload and download). > > Somebody are using ipp2p blocking the latest Ares version ? Did you already contact the author about this? If the Ares protocol changed, you've practically got a new protocol there, which requires it's own pattern for matching. If you can provide details about the new protocol (by dumping Ares packets or something) and help with testing, it should be not that hard to fix, provided the new protocol isn't something nasty. In case of a protocol change, other projects (like l7-filter) should suffer from this problem too. Maybe it'd be a good idea to test them and inform the authors as well. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Is this possible?
On Thu, Feb 23, 2006 at 06:38:09PM +1000, Russell Stuart wrote: > For example, lets say we have a 1000kbit link, and two > classes sharing that link: > > - Voip - ie high prio real time, and > - Web - background traffic. Have you measured this link, i.e. when there is no activity and you start some Voip sessions, do they get a constant downstream of 1000kbit? It may very well be that you have to measure the real throughput and then go a little lower (since you have to be the bottleneck), however having to throw 30% of bandwidth away sounds a bit too harsh to me. > Guaranteed RateCeilingPrio > Link 700kbit 700kbit >|--Voip 200kbit 700kbit 1 >\--Web300kbit 700kbit 2 Are there other classes as well, because the sum of Voip + Web rate is just 500kbit, where the parent class offers 700kbit? You should make sure that the sum of child class rates equals the parent class rate. HTB results get more predictable that way. > To be more precise, I want to create some "headroom" that > VOIP can use, but Web traffic can't. Usually, this "headroom" is the rate. In your example, Voip has 200kbit of bandwidth guaranteed. Web traffic can't use it unless of course there is no Voip traffic at all. Another way of indirect headroom would be to hard limit the Web class, i.e. give the Web class a lower ceil than the other classes. This way, there is bandwidth that the Web class can't use no matter what, even if the link is completely empty. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB, strange capacity distribution
On Thu, Feb 23, 2006 at 05:00:12AM +0100, Boris Gereg wrote: > I did what you suggested and the results are as expected! > You can see this picture to verify: http://elusion.sk/visual_inet_7.png > > At 4:25 I started HTTP download. P2P class immediately droped down to > it's RATE, WWW class got it's RATE. At 4:33 I stopped HTTP download, > P2P class got rest of capacity. Alright. I suggest you do some measuring, to find out your real rates, and set HTB rates to be slightly lower so that you are the bottleneck. Most likely you'll have to experiment a little until you find the best setting for your setup. > Please, are there some hints for setting r2q or quantum parameters? Actually, I specify the quantum directly, with 'quantum $MTU' for every class. I don't know wether that's a good thing or a bad thing, but it worked very well for me, and seems to work well for others... at least nobody reported a problem to me so far that could be traced to be caused by this quantum setting. It should not be smaller than your MTU, and not too big. With a huge difference in rates (100Mbit vs 64kbit) there is no r2q that will fit all classes. So there is no other way as to set quantum directly at least for some classes (and I set it for all...). Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB, strange capacity distribution
On Tue, Feb 21, 2006 at 02:21:36PM +0100, Boris Gereg wrote: > thanks Andreas, I reconfigured HTB to get your suggested hierarhy: One thing I forgot in my graph: Make sure that the rates always add up, i.e. the sum of the child class rates should equal the parent class rate. It's unlikely to be the cause of your problem, but it's important to get this right nevertheless. > Any other things to test, please? Just to see wether we are going into the right direction at all, could you run the following experiment: - Lower the rate and ceil of class 1:2 to 8096kbit. - Lower the rate and ceil of class 1:2000 to 7072kbit. - Lower the rate and ceil of class 1:3000 to 1024kbit. - For class 1:3010, set rate to 64kbit, ceil to 256kbit. - For class 1:3020, set rate to 128kbit, ceil to 768kbit. - For class 1:3040, set rate to 704kbit, ceil to 1024kbit. - For class 1:5040, set rate to 128kbit, ceil to 1024kbit. (You can adjust the rates for these classes as you like, just make sure that the sum is 1024kbit) If in this setup the shaping works as expected - WWW should get 704kbit at all times, P2P only slightly more than 128kbit while WWW downloads are active - then the limiting and distribution of HTB most likely works, and it's just too high rates or r2q/quantum that make it go bad. In this case, you'd have to measure realistic throughput rates of your network (even a 100mbit LAN may not be able to guarantee 10kbit at all times) and of your internet connection (may not be able to serve 2048kbit at all times). For downstream shaping to work, you have to be the bottleneck. If you get the same problem in this setup (P2P taking all the bandwidth away from WWW), then the problem is most likely something different, and we have to look at it from a different angle. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] mysterious rebounce in htb
Attached is a graph obtained with ethereal where after time +/-45s there is a rebounce which I can't explain. Setup is this: - my machine starts to generate traffic at maximum speed against a target machine (using nc < /dev/zero here and nc -l > /dev/null there) - traffic pattern is: 0s: dst port 2500 (red) 20s: dst port 8000 (blue) 40s: kill port 2500 traffic 60s: kill port 8000 traffic - htb is limiting that traffic to 100mbps at all times (see below for htb configuration) Could that bounce be a result of some wrong configuration I have? Or some other traffic interfering with my measurements? I used a "host 10.0.16.10" filter in ethereal, and since the bounce is "compensated" in the other traffic I don't think it was some external interference, but who knows.6 htb config is created by this script. Note I created two root classes so that my regular work on this desktop doesn't interfere with the measurements and tests I'm performing (or so I hope): #!/bin/bash DEV=eth0 WWWPORT=8000 SMTPPORT=2500 MAPI=10.0.16.10 tc qdisc del dev $DEV root > /dev/null 2>&1 # root qdisc tc qdisc add dev $DEV handle 1: root htb default 2 # root classes tc class add dev $DEV classid 1:1 parent 1: htb rate 100kbps tc class add dev $DEV classid 1:2 parent 1: htb rate 90mbit tc qdisc add dev $DEV handle 2: parent 1:2 sfq perturb 10 # a/www tc class add dev $DEV classid 1:10 parent 1:1 htb rate 30kbps ceil 100kbps prio 0 tc qdisc add dev $DEV handle 10: parent 1:10 sfq perturb 10 # a/smtp tc class add dev $DEV classid 1:11 parent 1:1 htb rate 10kbps ceil 100kbps prio 0 tc qdisc add dev $DEV handle 20: parent 1:11 sfq perturb 10 # b tc class add dev $DEV classid 1:12 parent 1:1 htb rate 60kbps ceil 100kbps tc qdisc add dev $DEV handle 30: parent 1:12 sfq perturb 10 # qualquer coisa indo para a mapi8 cai na classe 1:1 tc filter add dev $DEV parent 1:0 prio 10 protocol ip u32 \ match ip dst $MAPI/32 \ flowid 1:1 # on 1:1: a/www -> 1:10 tc filter add dev $DEV parent 1:1 prio 5 protocol ip u32 \ match ip dst $MAPI/32 \ match ip protocol 0x06 0xff \ match ip dport $WWWPORT 0x \ flowid 1:10 # on 1:1: a/smtp -> 1:11 tc filter add dev $DEV parent 1:1 prio 5 protocol ip u32 \ match ip dst $MAPI/32 \ match ip protocol 0x06 0xff \ match ip dport $SMTPPORT 0x \ flowid 1:11 # on 1:1: b (telnet, for example) -> 1:12 tc filter add dev $DEV parent 1:1 prio 5 protocol ip u32 \ match ip dst $MAPI/32 \ match ip protocol 0x06 0xff \ match ip dport 23 0x \ flowid 1:12 rebounce-ann.png Description: PNG image ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] iproute2 dump nat
Sorry for disturbung you, but I am not aware about a specialized forum/ml for iproute2. I try to use iproute2's dumb nat, I tried with kernels 2.4.27, .32 and 2.6.8. While DNAT is working fine, I am not able to do any SNAT: 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:04:e2:10:88:5f brd ff:ff:ff:ff:ff:ff inet 10.10.20.10/24 brd 10.135.28.255 scope global eth0 inet6 fe80::204:e2ff:fe10:885f/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:04:e2:10:80:d2 brd ff:ff:ff:ff:ff:ff inet 192.168.3.1/24 scope global eth1 I defined a ip rule: lb-test-11:/usr/src/packages# ip rul sh 0: from all lookup local 32764: from 192.168.3.2 lookup main map-to 10.10.20.11 32766: from all lookup main 32767: from all lookup default Packets comming in here (from 192.168.3.2): # tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 16:53:07.472210 IP 192.168.3.2 > 10.10.20.80: icmp 64: echo request seq 1366 16:53:08.471939 IP 192.168.3.2 > 10.10.20.80: icmp 64: echo request seq 1367 16:53:09.471768 IP 192.168.3.2 > 10.10.20.80: icmp 64: echo request seq 1368 and go out here (They are _from_ 192.168.3.2 , so policy 32764 should match) # tcpdump -n -i eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 16:54:45.454799 IP 192.168.3.2 > 10.10.20.80: icmp 64: echo request seq 1464 16:54:46.454559 IP 192.168.3.2 > 10.10.20.80: icmp 64: echo request seq 1465 16:54:47.454396 IP 192.168.3.2 > 10.10.20.80: icmp 64: echo request seq 1466 Source NAT is not takeing place. And no, I dont have any iptables rules in PREROUTING. Am I too dumb for or do I miss the point? Is there a way to log what policies are "hit" by packets? Best Regards, Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB, strange capacity distribution
On Tue, Feb 21, 2006 at 12:49:59AM +0100, Boris Gereg wrote: > (first of all, please, how to reply to some article in LARTC via mail > to post it into right thread?) Using 'reply all', or 'reply list' if your mail software offers it. If all else fails, just hit 'reply' and add the mailing list to CC. > So, I am definitely shaping outgoing traffic (upstream) Yes, outgoing traffic from router to your network, which actually contains the downstream traffic from the internet. Right? > tc -d class show dev eth0 > > class htb 1:2 root rate 10Kbit ceil 10Kbit burst 51587b/8 mpu > 0b overhead 0b cburst 51587b/8 mpu 0b overhead 0b level 7 > > class htb 1:2000 parent 1:2 leaf 2000: prio 0 quantum 20 rate > 5Kbit ceil 10Kbit burst 26593b/8 mpu 0b overhead 0b cburst > 51587b/8 mpu 0b overhead 0b level 0 > > class htb 1:3010 parent 1:2 leaf 3010: prio 1 quantum 1000 rate > 64000bit ceil 256000bit burst 1631b/8 mpu 0b overhead 0b cburst > 1727b/8 mpu 0b overhead 0b level 0 > > class htb 1:3020 parent 1:2 leaf 3020: prio 2 quantum 1600 rate > 128000bit ceil 768000bit burst 1663b/8 mpu 0b overhead 0b cburst > 1983b/8 mpu 0b overhead 0b level 0 > > class htb 1:3030 parent 1:2 leaf 3030: prio 3 quantum 6400 rate > 512000bit ceil 2048Kbit burst 1855b/8 mpu 0b overhead 0b cburst > 2623b/8 mpu 0b overhead 0b level 0 > > class htb 1:5040 parent 1:2 leaf 5040: prio 4 quantum 4825 rate > 386000bit ceil 386000bit burst 1792b/8 mpu 0b overhead 0b cburst > 1792b/8 mpu 0b overhead 0b level 0 It's as I suspected, your current HTB tree looks like this: 1: HTB Qdisc | \--- 1:2 HTB root class (10Kbit:10kbit) | \--- 1:2000 HTB leaf class (5Kbit:10Kbit) \--- 1:3010 HTB leaf class (64000bit:256000bit) \--- 1:3020 HTB leaf class (128000bit:768000bit) \--- 1:3030 HTB leaf class (512000bit:2048Kbit) \--- 1:5040 HTB leaf class (386000bit:386000bit) HTB classes borrow from their parent; in this setup, the parent class offers a whopping 10Kbit for that purpose. Unless the 1:2000 class has got a very high priority and is maxing out the line all the time, there is no limit to borrowing at all, because the other classes will never reach the 10Kbit from their parent. So the classes above are actually not limited by their rate, but by their ceil; the only class that will respect its rate in this setup is 1:5040, because it's got the same rate and ceil. Assuming that 1:5040 was your P2P class, if you set the ceil of this class to 2048Kbit, it will (try to) use 2048Kbit at all times, because the parent (thinks it) is able to offer it. You need a class that knows of your total internet bandwidth somewhere. Assuming that it is 2048Kbit, your tree should maybe look more like this: 1: HTB Qdisc | \--- 1:2 HTB root class (10Kbit:10kbit) | \--- 1:2000 HTB leaf class (5Kbit:10Kbit) | \--- 1:3000 HTB parent class (2048Kbit:2048Kbit) | \--- 1:3010 HTB leaf class (64000bit:256000bit) \--- 1:3020 HTB leaf class (128000bit:768000bit) \--- 1:3030 HTB leaf class (512000bit:2048Kbit) \--- 1:5040 HTB leaf class (386000bit:386000bit) In this setup, the 2048Kbit class is the limiting factor for the leaf classes, except for the 1:2000 class, which should be used for local LAN traffic only. HTH Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB, strange capacity distribution
On Mon, Feb 20, 2006 at 10:59:33PM +0100, Boris Gereg wrote: > I made a screen to help explain my problem. Please, see this picture: > http://elusion.sk/visual_inet_hory.png Nice graph. I assume this is on downstream, and you rely on HTB to drop packets for you. You may have read this in the archives already - it's much harder to shape downstream than upstream, because you can't really influence what the other side is sending you. So no matter what you do it's probably hard to get near-optimal results. > This is my HTB config (using latest htb-init script): I must admit I'm not familiar with htb-init. What are the parent-child relationships here? I'm missing the "internet" parent class that groups all the other traffics (except local) together. Does htb-init generate that on it's own somehow? If not, chances are your HTB tree is just exceeding your line capacity in general, as all classes are allowed to borrow without limit, rendering the prio setting uneffective, leading to random results. Could you post the output of 'tc -d qdisc/class show dev $DEVICE'? Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] calculating burst for TBF
I'm using tc from iproute-2.6.15 with a 2.6.12 kernel. I was testing the effects of the burst parameter in a tbf qdisc. Basically, I was testing this statement from the tc-tbf(8) manpage: "If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket. The minimum buffer size can be calculated by dividing the rate by HZ." So, for a 200kbit rate on intel, this would yeld me a minimum burst of 2000bits, or 250 bytes. I then do this: tc qdisc add dev eth0 handle 1: root tbf latency 50ms burst 250b rate 200kbit but all packets are dropped. I then rise burst to 300b, 400b, even 900b and it is still not working. It only starts working when I raise it to 2000b. Which, besides being the wrong unit (bits versus bytes), is the result of the rate/HZ calculation. The tc(8) manpage says that "b or a bare number = bytes", but it seems this parameter ends up being bits? If not, what is wrong then? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] filter performance/optimization questions
On Wed, Feb 08, 2006 at 07:58:48PM +0200, Imre Gergely wrote: > yepp, hashing is done, for every type C class (/24), there are around 300 of > these, and all are redirected to a more specific table, according to the > documentation. That's weird, then - with proper hashing, the total number of filter rules should not affect CPU load too much, since only very few of the filters actually have to be traversed. Maybe it's caused by something else, or the hashing does not work as expected. > now i have a question about this, too. to me it's not clear how these filters > are looked up. Good question. Actually I can't answer it properly. For my filters, the order either did not really matter or I had few enough of them to use the priority parameter to order them properly. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] filter performance/optimization questions
On Wed, Feb 08, 2006 at 07:29:57PM +0200, Imre Gergely wrote: > i did some tests with esfq (that brought down the classes to around 150), but > the filters remained, and the load was still 100%. and i get some packet loss > because of that. not much, around 1-2%, but it's enough :) > > is there something i could do to bring the load down? Are the filters already hashed? If not, that's the first thing I'd try. There was a section on that on www.lartc.org. (Hmmm, seems to be down.). http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO/lartc.adv-filter.hashing.html HTH Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB prio question
On Mon, Jan 30, 2006 at 02:35:36PM +0200, Anton Glinkov wrote: > Is the prio specification in the htb class global or is it on a per class > basis? A simple example: > > class 1:10 parent 1: > class 1:130 parent 1:10 prio 3 > > class 1:170 parent 1:10 prio 7 > class 1:171 parent 1:170 prio 1 > class 1:172 parent 1:170 prio 2 > > Which class will get excessive bandwidth first? 130 or 171/172? I haven't tested it, but from my understanding, it should be 1:130. Children classes should not be able to borrow from the outside by themselves - they can only tell their parent to borrow for them, so it's 1:130 (prio 3) vs 1:170 (prio 7) here. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] PRIO on non-leaf classes?
On Wed, Jan 25, 2006 at 03:28:14PM +0200, openswan wrote: > I'm using HTB and would like to ask is it correct to put "PRIO" on > non-leaf classes ? I know that on leaf classes it's correct and > determines how the excess bandwidth is distributed among non-leaf classes. Depends on what you mean by "PRIO". If you're talking about the class parameter prio (in lower-case letters), then it's correct, the PRIO QDisc however, can not be attached to anything but the device itself (root qdisc) or a leaf class. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] http gets to user space
ah. missunderstood the question. you meant without squid.. sry :) Quoting lartc <[EMAIL PROTECTED]>: hi all, curious is anyone has successfully sent http get packets to userspace for blacklist filtering ... i'd like to do a live cd that would obviate the neccessity to install squid and squidguard, but rather, have iptables send packets to squidguard (or something else) directly ... cheers charles ___ 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] http gets to user space
You mean transparent proxy? http://www.faqs.org/docs/Linux-mini/TransparentProxy.html Quoting lartc <[EMAIL PROTECTED]>: hi all, curious is anyone has successfully sent http get packets to userspace for blacklist filtering ... i'd like to do a live cd that would obviate the neccessity to install squid and squidguard, but rather, have iptables send packets to squidguard (or something else) directly ... cheers charles ___ 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] classless qdisc and classful qdisc
On Sun, Jan 22, 2006 at 07:07:32PM +0700, Ismail Fahmi wrote: > 1. what is the difference between classless and classful qdisc?? when I made > a qdisc, are I must create both of that qdisc...??? A classful qdisc allows packets to be sorted into different groups, and to handle packets differently depending on the group they belong to. This gives you a lot of control over how packets of a certain type / belonging to a certain user / etc. should be treated. A classless qdisc just takes all incoming packets and treats them essentially all the same (with some exceptions). You can't manually customize or group type of packets in any way. > 2. what is the difference beetween three of the classless qdisc in linux > redhat 2.4, sfq pfifo and tbf if I using the htb classful qdisc ??? because > when I use htb classful qdisc it means I made a qdisc that can rate b/w for > each class, so it's no difference between I used tbf classless qdisc in each > class and I used sfq or pfifo... Not sure if I got this question right. Are you asking what the difference between limiting bandwidth using HTB and TBF is? In that case, TBF is classless, doesn't know anything at all about other traffic, and will just stupidly limit the bandwidth to a certain value. HTB on the other hand knows about its classes and can balance the total available bandwidth between them. HTH Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] guarantee package delivery
On Sun, Jan 15, 2006 at 12:41:31AM +0300, Vladimir S. Petukhov wrote: > Moreover - packets must not be dropped! Sorry for this useless answer, but... How strong is this condition? I mean, even if you don't drop a packet locally, it can still be dropped by the target machine, or by one of the routers in between. You have no influence on that whatsoever, so no matter what you do, your application must be able to handle dropped packets. If you think about it that way, is it still critical when a packet gets dropped locally? If not, you could just do this the usual way. > One of the obviously decisions: Module (kernel) must inform > userspace about current bandwidth or data amout, that programm can be send > this moment. Does the kernel even know about that? Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Per user bandwidth limiting ..for small ISP.using Squid
On Fri, Jan 13, 2006 at 04:58:19PM +0100, Peter Surda wrote: > I hope people won't mind if I mention my project again: > http://www.shurdix.org We're happy to receive any reply at all, really... :-) > Your situation is however special because you have squid. Combining > squid and tc is problematic. I agree; so far I haven't been able to shape squid traffic the way I want it to. However, shouldn't rshaper suffer from the same issues? It should at least be possible to do something similar to rshaper using tc. > However, there were some kind guys who designed the "tproxy" iptables > extension, which can help you. It isn't easy to setup and if you have > NAT you need 2 separate machines (one doing the NAT and one running > the squid), but is doable. This way tc will see squid's traffic with > the IP of the real client. These are about the most interesting lines I've seen on this topic. However, I'm in a small home network situation, so even having just one dedicated linux machine is luxury. So any solution that requires separate machines is not feasible for me. > My recommendation for your situation would be something like this: > - keep your router, let it do NAT and perhaps a minimal firewall > - get a second machine, put it between the router and the LAN, and > install shurdix there > - configure it to use TC and Squid (and optionally IP accounting and/or > firewall if you like). No delay pools necessary. Other possibilities are: - Never touch a running system. (If it works, why not leave as is?) - Find out how exactly rshaper limits and/or distributes up- and download bandwidth for * User <-> Internet * User <-> User * Internet <-> Squid (and other caches, DNS etc.) * Squid (and others?) <-> User and use this information to build a tc class tree. - If you want to keep rshaper, port it to 2.6 by yourself ;-) Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Qos and bandwidth control
On Thu, Jan 12, 2006 at 07:01:57PM +, Beto . wrote: > 1.2.3.1 has 256kbit bandwidth "guaranteed" > clients 1.2.3.2 and 1.2.3.3 has 256kbit bandwith So I guess that means 512kbit in total? > so im marking every packet using layer7 iptables module I have not used layer7 so far, only IPP2P, but the basic idea of classifying and prioritizing should be the same. > iptables -t mangle -A POSTROUTING -m layer7 --l7proto ssh -j MARK > --set-mark 2 No connmark? Does layer7 actually detect every single packet of this protocol, or only the first ones of a connection? In the latter case, you'd have to mark the connection, not just a single packet. > the problem im facing is that i also have to limit client's bandwidth and > im not sure that my solution is the best. i've searched for an example like > this in the web but i have found nothing. I don't know what's best either. My solution was to give every user a separate HTB class, to limit their bandwidth. Further prioritization of packets has then to be done inside this user class. Your setup looks like you're trying to do something similar. > it could have some errors. Basic protocol detection and enqueue was working > fine, but im not sure now, with "bandwidth restrictions" additions. The most common error with HTB classes is that the sum of the children class rates is not equal to the parent class rate. You got it right for the root class 1:1 and it's children 1:2, 1:3 (256+256=512kbit), but it's wrong for the children of 1:2 (200+128+20=348kbit, whereas the parent can only offer 256kbit in total). Also, I don't see where in your setup the classification by user is taking place. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Multiple ISP Links - Gateway Not Getting Restored
Perhaps the ip-up / ip-down scripts of pppd could help you to automatically do this load balancing script job? Manish Kathuria schrieb: I have been successfully implementing load balancing gateways for multiple ISP links at various locations using Julian's patches and as suggested in LARTC HowTo. At one location, one of the ISPs is providing connectivity through a PPOE DSL link which has to be dialled in everytime to connect. The gateway has been configured on a Fedora Core 3 based system and I have recompiled the 2.6.12 kernel after applying Julian's patches. I have configured the DSL modem in bridge mode and connected it to an ethernet interface on the gateway and use the DSL dialer in Fedora Core 3 to connect to the ISP. This creates a ppp0 interface when the connection goes live which is alloted a static Public IP. The dialer has been configured to redial as and when the link goes down. However the problem is that the kernel is not able to detect when this DSL interface (ppp0) comes back and does not restore the gateway through this link. The loadbalancing script has to be run again to make the kernel treat this gateway as LIVE and make the traffic go out through it. Has anyone encountered a similar problem ? I have never come across such an issue wherever the link is terminating on an ethernet interface. This ISP is insisting on dialling and then establishing the a PPOE interface. Any suggestions ? Thanks, Manish ___ 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] class exceeds its ceil
On Tuesday 27 December 2005 23:34, Jody Shumaker wrote: > Also, that email is partially incorrect. Nothing done in that email > will prevent lending from the 1:40 to the 1:2 class and subclasses. The way I see it, the email is correct. A class that has the same rate and ceil will never borrow, simply because it does not have to. As for lending, that will happen only if one of it siblings wants to borrow bandwidth. As for children classes, they are restricted by their parent. They cannot take bandwidth from outsiders, unless their parent borrows it for them. That does not help the original poster in any way, however. Sorry for this useless message. ;-) Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] 2.6.14 - HTB/SFQ QoS broken?
On Tuesday 27 December 2005 21:51, Leo Bogert wrote: > $addclass 1:0 classid $cMAIN htb rate $IFUP mtu 1492 > > $addclass parent $cMAIN classid $cEMULEhtb rate 8kbps ceil $IFUP prio 4 > $addclass parent $cMAIN classid $cAPACHE htb rate 32kbps ceil $IFUP prio 2 > $addclass parent $cMAIN classid $cDEFAULT htb rate $IFUP burst 6k prio 1 So, the parent class offers $IFUP rate, but the children are trying to use 8kbps+32kbps+$IFUP. It's hard to tell what HTB will do in this case. > As you can see, eMule can use all bandwidth as long as nobody is requesting > something from the webserver. If somebody is downloading from the server, he > should receive 32kbps and eMule should be slowed down. Yes, apache should be able to receive 32kbps, emule 8kbps, and everything else the full bandwidth, all together at all times. But since there is not that much bandwidth available (it's just $IFUP in total after all), something has to give way. > BUT now I have checked the speed of my webserver, and when eMule is running > it is only at 4 kb/s instead of 32 kb/s. > > AND I have found the reason for this: If I remove the SFQs, scheduling > seems to work - at least at the "bad precision" of HTB: Apache receives over > 20 kb/s and eMule is limited to 12 kb/s instead of 8. The way I understand HTB, your class structure is simply overallocated, and the results you get from that are random at best. Before continuing, you should make sure that the sum of children class rates is equal to the parent class rate. > Martin Devera told me that it is wrong that the sum of the child-HTB's > rates is larger than my interface speed. Well, I reconfigured to have > the sum equal the available bandwidth and even then QoS did not work. Well, if even the author says so, you should heed his advice. :-) Even if this is not the main problem in your case, keeping this kind of HTB tree around won't make things better. Could you post your reconfigured setup, possibly with proper class names and rates instead of variables that could be anything? Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] class exceeds its ceil
On Tuesday 27 December 2005 13:33, Ratel wrote: > I need to allow other classes to borrow bandwidth from a p2p class, but > I do not want to allow a p2p class to borrow bandwidth from other > classes. Is there a way to achieve it ? maybe I should redesign > something in the above diagram. Uh... huh? Your P2P class has 100kbit rate with a 5600kbit ceil, but you say you don't want it to borrow bandwidth from other classes. However, to go over the 100kbit rate, it _has_ to borrow. So, if you don't want it to borrow like you said, the solution would be to set the ceil of the P2P class to 100kbit as well. The other classes will still be able to borrow from it if the P2P class is not using it's bandwidth. If this does somehow not seem to be what you want, please restate your requirements. :-) Kind regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] routing in the same subnet
Any ugly trick is to active proxy_arp on the interfaces of the router (/proc/sys/net/ipv4/conf/*/proxy_arp). Then the external interface will scream "i have it!" on all of the arp requests for the other ip addresses (as soon as the router has the other machines in his arp-table). if you have ip_forward enabled and your clients using the internal interface address of the router as gateway you have what you want. Adam Gawda schrieb: Hi, I have IP 64.10.12.64/26 (example) and there's gateway 64.10.12.65 and I want doing something like this: -64.10.12.65 GW --- ROUTER--- clients eth0 64.10.12.66 eth1 64.10.12.66 from 64.10.12.67 to 126 255.255.255.192 255.255.255.192 255.255.255.192 GW 64.10.12.65 I want have all clients behind router (traffic shaper, firewall , etc). May I do it other method than subneting ? - because now doesn't work Pamiętaj o wszystkich/ -im w te święta! Zajrzyj na swieta.wp.pl i wygraj aparaty cyfrowe Panasonic! Kliknij: http://klik.wp.pl/?adr=www.swieta.wp.pl&sid=599 ___ 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] tc strange behaviour
On Thursday 15 December 2005 20:21, Alexander Kabanov wrote: > tc qdisc add dev eth0 root handle 1: htb default 15 > tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1mbit > tc class add dev eth0 parent 1:1 classid 1:15 htb rate 512kbit ceil > 1mbit > > what I expect: > limit outgoing traffic to 1mbit, start rate is 512kbit and let it grow > up to 1mbit > (correct me if i'm wrong here) That would be correct, if there were some sibling classes to 1:15 that prevented it from using 1mbit traffic at all times. Right now, there is no one who could prevent 1:15 to borrow bandwidth to reach 1mbit, so most likely it will just ignore the rate setting and use as much bandwidth as it needs, up to 1mbit in total. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] shareaza
I guess it's not possible without knowing the nature of these protocols. It's like the ftp-data channel... without looking into the ftp-cmd channel (ip_conntrack_ftp) iptables wouldn't know that the two connections are related... ncrfgs schrieb: On Sun, Dec 11, 2005 at 06:12:59PM +0100, Andreas Unterkircher wrote: I'm not very familar with all these p2p protocols. But isn't shareaza supporting all the other p2p protocols? Like edonkey and bittorrent... Most of them can be matched with ipp2p (www.ipp2p.org) or l7-filter (l7-filter.sf.net). As far as I know they can but I wondered whether it was possible to accomplish the task using only vanilla iptables and iproute. It looks like it works like this: shareaza ``negotiate'' with the other end listening on port 6346, then they try to ``find an agreement'' about which other port to use and in the end uploads actually occurs on that one. Am I right? Generally speaking, how can I recognize and keep track of edonkey connections? Thanks in advance. Best regards. ___ 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] shareaza
I'm not very familar with all these p2p protocols. But isn't shareaza supporting all the other p2p protocols? Like edonkey and bittorrent... Most of them can be matched with ipp2p (www.ipp2p.org) or l7-filter (l7-filter.sf.net). ncrfgs schrieb: On Sun, Dec 11, 2005 at 05:30:55PM +0200, Georgi Alexandrov wrote: If B uploads a file to C through gnutella everything works like a charm since packets look just like this: 192.168.0.2:6346 > xxx.xxx.xxx.xxx:y With tc I filter packets whose source port is 6346 and everything is fine. You can classify the traffic from B going out trough ppp0 with netfilter/iptables like this: What you wrote is indeed very similar to what I use right now except for the fact that I'm classifying according to the source port, too. The side effect of your configuration is that all of the traffic from B though ppp0 is shaped. The configuration you've suggested is interesting but I'd like to limit the shareaza traffic only. Is there any way to do that? How can I keep track of the traffic generated by shareaza only? Thanks in advance. Best regards. ___ 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] HTB - prio and rate
On Monday 05 December 2005 10:40, Mark Lidstone wrote: > 1) The sum of all HTB classes under a single HTB qdisc should > add up to the maximum rate of the qdisc A HTB qdisc does not have a rate; it's the classes that do. And it's not all classes, but just parent-children relationship. The sum of the children class rates should be the parent class rate. Maximum rate doesn't sound right either; just to avoid misunderstandings, we're talking about rate here, not ceil. Think of rate as 'this much bandwidth is guaranteed at all times for this class (and divided between the children)', then you should get it about right. > 2) HTB's prio is only used when 'borrowing' bandwidth from other > classes under the same HTB qdisc, then classes with a given prio will > only be able to "borrow" bandwidth when classes with a lower prio have > nothing waiting "classes under the same HTB qdisc" is too general. You have to respect parent / child / sibling relationship as well. A class can't just borrow from any other class. For example, if a class has same rate and ceil, it won't borrow anything, simply because it doesn't have to. And if the parent won't borrow, it's children won't borrow from outside classes either, even though they are "under the same qdisc". > Is this correct? Getting there, I think. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Theory test
On Monday 05 December 2005 18:42, Kenneth Kalmer wrote: > -= HTB =- > > Set the parent class for internet traffic to X, with 200 children. > Each child has a rate of Y, their totals equal X. Each child also has > a ceil of Z. This means that Z * 200 > X, hence the over subscription. I'm using pretty much the same with success, although not for 200 users, just 5. However, the bandwidth is considerably slower than what you are likely to have (128kbit), so it may be just as critical. > What happens here is that several people download at Z, but their > speed does not decrease when more people start accessing the internet. > They stay at Z, which is a problem. This is a serious problem which should not happen. So assuming that there is no error in your configuration, it's likely to be a HTB bug which should be fixed. > -= HFSC =- > > Tried playing around with the curves, but a lack of knowledge and > resources has hampered me from figuring out this one. Is there still no documentation for HFSC around? > -= WRR =- Sounds very interesting, unfortunately I didn't have the time to try this one out. So I can't comment on the problems you have with it either. :-( > Can anyone advise me on how to get this done properly, please. > Somewhere I must be missing something small, and I don't want to paste > millions of lines of scripts in here until I know I've got the theory > right. The over subscription is the big problem, pure rate limiting > works like a charm in my other experiments. The theory sounds fine to me. About the sum of ceils being bigger than the rate of the parent class, that's not really over subscription, but the whole point of the ceil parameter. Over subscription to my understanding would be the case if the guaranteed rates of classes would exceed the parent class rate. But since you say that it sums up to X, the theory sounds just fine to me. I'd like to have a look at your HTB setup, since that is the scheduler I'm most familiar with. If the script is too long, you could upload it somewhere and post the URL to it. Or just cut out the repetitive parts if you aren't using functions for that already anyway (I'm assuming that the 200 user classes are all created the same way). Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: IPSec tunnel and routing
ip ro add 192.168.2.0/24 via 10.2.0.1 dev ethx src 192.168.1.1 the spd policies will then match and encrypt the traffic. this is the same solution like you have to do for the freeswan ipsec stack. for me it works... Alexander Kotelnikov ([EMAIL PROTECTED]) schrieb: > > >>>>> On Mon, 05 Dec 2005 06:08:30 +0100 > >>>>> "AU" == Andreas Unterkircher <[EMAIL PROTECTED]> wrote: > AU> > AU> Alexander Kotelnikov schrieb: > >> Ok, I would not ask all this if I have no problem with > >> tunnelling. With configuration like described above, where multihomed > >> maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, > >> 10.2.0.1) tunneling works for all machines, but these two > >> routers. This happenes becase if we send a packet from 10.1.0.1 into > >> 192.168.2/24 this packet does not come to ipsec, but is pushed to > >> default gateway, if it exists. In other words, local generated packets > >> do not come through prerouting or something. > >> > AU> You have to add a route on 10.1.0.1 to make sure packets which belong to > AU> 192.168.2.0/24 have > AU> a src address of 192.168.1.1. > > Very funny, how do you imagine this could be done? > > -- > Alexander Kotelnikov > Saint-Petersburg, Russia > > ___ > 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] ip route doesn't not work with virtual inferfaces
You can specify the source address
ip route add 192.168.66.0/24 via 192.168.1.2 src {The_Source_IP_of_interface}
Radek Vokál ([EMAIL PROTECTED]) schrieb:
>
> I have two IP for eth0 which correspond to eth0 and eth0:1
> I want to create a route
> to 192.168.66.0/24 via 192.168.0.50 from eth0:1
>
> so I add the route with
>
> ip route add 192.168.66.0/24 via 192.168.1.2 dev eth0:1
>
> but when I connect to 192.168.66.0/24 network in connects still using
> the IP of eth0, not the IP of eth0:1 as one would expect.
>
> What's strange to me is that ip route list dev eth0:1 shows same output
> as ip route list dev eth0
>
> is this expected behavior or is there a bug?
>
> Radek
>
>
> --
> Radek Vokál <[EMAIL PROTECTED]>
>
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IPSec tunnel and routing
Alexander Kotelnikov schrieb: Ok, I would not ask all this if I have no problem with tunnelling. With configuration like described above, where multihomed maches have ip-addresses (192.168.1.1, 10.1.0.1) and (192.168.2.1, 10.2.0.1) tunneling works for all machines, but these two routers. This happenes becase if we send a packet from 10.1.0.1 into 192.168.2/24 this packet does not come to ipsec, but is pushed to default gateway, if it exists. In other words, local generated packets do not come through prerouting or something. You have to add a route on 10.1.0.1 to make sure packets which belong to 192.168.2.0/24 have a src address of 192.168.1.1. Then the packet should go through the ipsec tunnel. Similar route in the other direction has to be used on 10.2.0.1. Cheers, Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping per machine
On Sunday 04 December 2005 23:11, Dave Weis wrote: > What should I be doing differently here? > > tc qdisc del dev eth0 root > > tc qdisc add dev eth0 root handle 1: htb default 10 > > tc class add dev eth0 parent 1: classid 1:1 htb rate 100MBit ceil > 100MBit > > tc qdisc add dev eth0 parent 1:10 handle 110: sfq perturb 10 > > tc class add dev eth0 parent 1:1 classid 1:10 htb \ > rate 256kbit ceil 256kbit prio 0 > > tc filter add dev eth0 parent 1:0 protocol ip pref 1 u32 \ > match ip src 10.7.15.0/24 flowid 1:10 You create a class only after you already attached a qdisc to it. Did you mix up the order of the commands or does that actually work? Anyway, you seem to be putting all traffic (local or not) into one 256kbit class, which will result in what you're describing (whole interface limited to 256k). A HTB class always imposes a global limit, not a limit per machine. If you want a per-machine limit, you have to create an extra class for each and every one machine. HTH Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tbf and prio blocking some flows entirely
On Sunday 04 December 2005 19:17, Brian J. Murrell wrote: > > There is no fair treatment in PRIO. > > No, it's priority based. Got that. Exactly what I am looking for in > fact. Sorry, seems that I misunderstood you in your message in the point that you meant SFQ and not PRIO when you were talking about fair treatment. > So to replace that with HTB I tried: > > tc qdisc add dev ppp0 root handle 1: htb default 10 > tc class add dev ppp0 parent 1 classid 1:1 htb rate 120kbit Without additional filter rules, it should be 'default 1', and not 10. Otherwise HTB will try to put the classes in 1:10, which does not exist, and instead send them out directly without any shaping at all. > Well, TBF does not seem to be getting stuck. There is still lots of > traffic moving when these other flows seem to just stop, so TBF can't be > the problem can it? It has to be PRIO, not dequeuing anything for these > particular stalled flows to TBF right? Hmmm. Well, I was just guessing, because I had this 'stuck' problem with TBF before. As I said, I never really solved that problem, so I can't say much about cause and such. The way I understand it, the root qdisc will get the request to dequeue a packet, and it will forward this request to the underlying qdiscs. So when TBF is asked for a packet, it will decide wether to send one or not (depending on wether there is any bandwidth left). If it wants to dequeue one, it will forward this request to the underlying queue(s), PRIO in your case. PRIO will look at it's bands and dequeue a packet from the first band that has packets queued; in your case, it will have to ask the underlying SFQ queue to select a packet. SFQ will look at the packets it has queued and select one based on it's "stochastical fairness" algorithm. SFQ then returns this packet to PRIO which in turn will return this packet to TBF which in turn will send this packet on it's way. Please note that this is all guesswork. I haven't actually looked at the kernel code for all of that. :-) It might actually work in a totally different way. Anyway, if my understanding model is correct, and some packets in your prio bands get sent and others don't, it should be the fault of SFQ, and not PRIO, for selecting the wrong packets. My guess before was that TBF was at fault, allowing too little bandwidth, which would lead to a general stalling, which would be most noticeable on connections that are bandwidth intensive. A completely different reason may be that you've got a bad mixing of flows; for example, "important" traffic like web browsing etc., and P2P don't go well together in the same queue. This is simply because P2P has the habit of opening hundreds of connection, whereas WWW is just one or at least very few connections. So if you've got maybe 5 WWW connections and 200 P2P connections flowing through the same SFQ queue, every connection will be able to send about the same number of packets, resulting in a lot of P2P packets and very few WWW packets, just because there are so many more P2P connections there. For that very reason, in my P2P setups I'm actually using 4 prio bands, putting P2P alone into the 4th band, so that it may starve when there is any traffic other than P2P. > I think I am doing that. I thought that is what: > > iptables -t mangle -I POSTROUTING -o ppp0 -p tcp -m tcp --tcp-flags > SYN,RST,ACK ACK -m length --length :128 -j CLASSIFY --set-class 2:1 I apologize; I'm guilty of not reading your messages carefully enough. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tbf and prio blocking some flows entirely
On Sunday 04 December 2005 17:36, Brian J. Murrell wrote: > Even if they end up in 2:3, they should at least be treated fairly. 2:3 will not be treated at all as long as 2:1 and 2:2 (which have higher priority) are occupied. If the queues in 2:1 and 2:2 resp. never empty, the packets in 2:3 will never be sent. There is no fair treatment in PRIO. That's the whole purpose of this scheduler, to give one band of packets absolute priority over the other. > What have I done wrong? This is just out of personal interest, but could you try using instead of your TBF qdisc, a very simple HTB Qdisc / class with the same bandwidth limitation? If that solves the problem, then you're suffering from a problem that I failed to solve when I last tried to use TBF; for some reason it got stuck on me too. > So maybe for some reason that last ack is not being dequeued? I don't understand what you mean by fair treatment, but do try putting all ACKs into high priority band, then it will have to be dequeued. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - prio and rate
On Sunday 04 December 2005 03:32, Jeffrey B. Ferland wrote: > Quick question I've been trying to figure out myself without success: > can I attach a qdisc to a qdisc instead of a qdisc to a class? Be > nice to chain a few qdiscs together... Dunno. I've always only attached QDiscs to classes. Even QDiscs that don't come with such a class tree structure like HTB do have classes, for example in PRIO qdisc, the prio bands of the QDisc are actually classes that are created automatically and you can attach another QDisc to them. What kind of QDisc chain were you thinking of? Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - prio and rate
On Friday 02 December 2005 23:24, Brian J. Murrell wrote: > Yeah, that is what I want, but why do I need HTB? You need it only if you also want to limit bandwidth somehow. > I guess I am missing the reasoning for partitioning up the bandwidth > with HTB rather than just letting everyone/everything have an > opportunity to use the full bandwidth as long as something/somebody more > important is not using it. Imagine a network where every machine tries to send data at much higher rates than your total bandwidth allows. This may cause packet queues building up at your router, or worse, at your modem or provider. These queues have to empty themselves first before a new packet can be sent, which can cause a lot of additional delay depending on queue size. In that scenario, it's important to take control over this building up queue, which you can do by limiting bandwidth using HTB or similar (so the queue will be in your router, not somewhere else), by making your router the bottleneck. > Surely it will be connection based fairness within the priority class. I haven't looked at the code, but I think it's just a plain fifo queue, unless you attach SFQ or similar to replace it. > Oh? So one ssh could starve another? Why? Are the outbound SSH > packets not just put to the front of the queue in FIFO order? That's what I thought. HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Which option is better
On Friday 02 December 2005 21:16, DervishD wrote: > I find the above a bit overkill, since LAN and ADSL classes won't > NEVER borrow nor lend bandwidth to one another. They won't do that because the classes got the same rate/ceil. So there is no need to borrow/lend ever. HTB is used for bandwidth limiting only here, probably except for "(some children classes)", whatever they are. I'm doing it practically the same way, except I don't like setups with more than one root class, so I actually got a fat root class with the device speed as rate above those two. In my personal opinion, having two root classes in HTB implies that these two are completely independent, which is not the case since they have to share the same interface after all. And I think it's not overkill at all, since this is the only way to ensure that LAN traffic (file transfers and such) leave a bandwidth window open for the more fragile internet traffic. > HTB: quantum of class 10001 is big. Consider r2q change. > > Of course it is big!, it's my LAN class, limited to 90Mbit/s... You can get rid of this message by specifying the quantum for this class directly. > Is there any better alternative to the above, given the great > difference in rates and the fact that I won't NEVER share bandwidth > between 1:1 and 1:2? I don't have any problems at all with this solution, so I never bothered looking for something better. In fact, I think it's a very good solution, and if you're shaping using nothing but HTB, it's probably even the best solution you can get. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - prio and rate
On Friday 02 December 2005 21:31, Brian J. Murrell wrote: > In fact if I were to saturate the upstream with SSH, something like > bittorrent should effectively get no bandwidth at all. That's exactly what the PRIO qdisc does. In combination with HTB and SFQ, it can be quite powerful, as low priority connections will completely starve as long as there are higher priority packets to be sent. However, PRIO does no bandwidth limiting at all (has to be done by HTB or similar), and does not provide connection-based fairness (has to be done by SFQ or similar), if you want to avoid one SSH session taking all the bandwidth from the other. Regards, Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Interesting question
On Friday 02 December 2005 18:23, Robb Bossley wrote: > Would it be necessary to use a separate box to incorporate squid into > the mix, or can I just use separate interfaces (one for VoIP without > squid intervention, and one for all other traffic utilizing squid)? In terms of shaping, if prioritizing the VoIP box is all you want to do, and assuming that squid has nothing to do with VoIP, you can do it all on a single machine with a single interface... after all, your filter rules just have to match the IP of your VoIP box. Using an extra box / interface for that seems unnecessary. About squid, I must admit that I don't have any first hand experience with it. Shaping it properly (on a per-user basis) seems to be a pain, which is why I never bothered with it. Regards Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB - prio and rate
On Friday 02 December 2005 14:57, Mark Lidstone wrote: > As I understand things, when prio values are assigned to an HTB setup, > classes with a given prio value will only be serviced when there are no > packets waiting in classes with a lower prio value. Actually, a class is always able to use it's rate at any time. The prio has only an effect when the class is trying to borrow bandwidth from others - then the high prio classes are allowed to take what they need first. The prio of your understanding is instead implemented by the PRIO qdisc. However, PRIO does not allow limiting of bandwidth. In my opinion, this does make sense, at least I have so far not seen a good solution (implemented or theoretical) for combining hard prio and bandwidth distribution requirements together. What you can do, is adding a PRIO qdisc as a child to a HTB leaf class. Then the HTB class will take care of the bandwidth limiting, and PRIO will take care of the order of the packets inside the HTB class. > Now, does this mean that the rate values for classes with different prio > values should be considered separate? No. > Should rates (a) and (b) add up to the maximum rate (100kbit in this > example), with (c) and (d) adding up to the same, or should the total of > (a), (b), (c) and (d) be the maximum rate? The rate of the children classes should add up to the parent class rate, independent from their prio and ceil (except for the root class, where it does not make sense to set a ceil higher than rate). HTH Andreas Klauer ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Screening packets within tc-classes
Good suggestion to use ulog for this. So I could dump the exactly
traffic which would run through a class (CLASSIFY)
to analyze and extract the necessary data to draw the graphs. So I do
not have to parse my class (IP or MAC) out of a
full tcpdump stream.
Sadly not possible with tc-filter. But perhaps I could do this for tc
with Vincent Perrier's sch_spy module.
Cheers,
Andreas
Patrick McHardy schrieb:
Andreas Unterkircher wrote:
Hello list,
I'm currently a bit planless so perhaps someone here could give me a
point in
the right direction.
History: I wrote a shaper web tool (http://shaper.netshadow.at) and
now got
several feature requests if it would be possible to graph "what's
going on"
(this mean per IP address, tcp/udp ports or protocols) in a specific
chain. A
chain represents a specific tc-class. Packets get into this chains via
tc-filter or iptables MARK.
Currently I'm drawing graphs with data got from the dequeuing
counters via tc
-s class show dev ${IF}. Not the best way - I know - but it was
enough till
yet.
Now the question is - is it possible to get direct access to network
packets
that flow through a specifc tc-class?
I was thinking about iptables and dumping the MARK-value via libpcap.
But I
don't think that this will work because the pcap-filter is attached
to the
device itself before the iptables rules (like the restore-mark) are
acting. So
I guess libpcap will not see this.
No it won't, but its not able to use the netfilter mark anyway. One way
would be to use the ipt action combined with the ULOG target and send
packets to userspace that way.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
