Re: [LARTC] Limiting Bandwidth of an ppp interfaces
Florian Taeger wrote: Hi. If the traffic from all the ppps leave by one interface then you could mark packets by incoming interface and set up egress shaping with say HTB on that interface. There is only one eth0 interface to the internet and many ppp for the users. So ... I have to shape every traffic from the ppp interfaces to eth0 (internet) and the same way around, don't I ?? I think you should think about what Eric says - I don't have experience with many ppps and I guess you will need to use scripts per ppp. For Egress you can add a TBF per ppp. For ingress you could add a policer to each or you could use IMQ, but you would need one device per ppp. To this you could then add a TBF to ratelimit. This will not involve iptables. Iptables plus HTB on eth is still a non IMQ option for doing ingress - depends on detail though :-) I am assuming that you don't want to do any sort of QOS for the customers. How would it be done with htb ?? The problem ist - 50% of all the traffic on eth0 is to establish the ppp session through a l2tp tunnel and the other 50% are for the real traffic to the internet. So i only want to shape down the traffic from or to the ppp interfaces. But I can't shape the whole traffic on eth0. So ... will there be any problems regarding this ? I think it would be OK. HTB has a default class for traffic it can't classify AFAIK the default for this is no limits. Or you could just make a class with a big limit. Of course i read the docs, but I just don't know how exactly to generate the shape-filter for this. I know i have to establish a root entry and make another entry for every ppp device. but how do i connect the interfaces an the traffic ?!? How would I generate this "hard limit" for the traffic ? Exactly how you do things depends on whether you can get your scripts to set a mark for a new ppp that relates it to a specific customer. If you can do this and inserting the rules into running iptables works OK then you could have an HTB class already setup on eth0 for each customers rates. Andy. Many thanks for the help. Regards F.Taeger ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] hfsc scheduler
yoyo wrote: i remember on this list someone tried hfsc (he had some nice comparison graphs between hfsc&htb) but i can't seem to find the message in the archives.. :( This one. Andy. Vincent Perrier wrote: > HTB versus HFSC, both qdisc offer the same kind of service, > if you want to see comparative test results, go to > http://www.rawsoft.org > at the line "TEST RESULTS" you will find the results for > a sharing test and a burst test. > You will see that both qdisc are good. Nice comparision, very interesting. Note that you have a small misconfiguration in your HFSC setup. On page 8 you say "The shaping is impacted by real time bursts". This is only because your real-time classes are not part of the link-sharing hierarchy. If you add link-share curves to the real-time classes which are equal to the real-time curves shaping won't be impacted. Regards Patrick ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] hfsc scheduler
i remember on this list someone tried hfsc (he had some nice comparison graphs between hfsc&htb) but i can't seem to find the message in the archives.. :( On Fri, 29 Oct 2004 23:33:25 +, yoyo <[EMAIL PROTECTED]> wrote: > me too :) > > > > > On Fri, 29 Oct 2004 19:20:35 -0400, Jason Boxman <[EMAIL PROTECTED]> wrote: > > On Friday 29 October 2004 19:06, yoyo wrote: > > > hi all, > > > > > > long time since i posted on the list. > > > just wondering if anybody has played around with hfsc and if so could > > > he/she share their info on it > > > > http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/hzhang/WWW/HFSC/ > > http://www.tik.ee.ethz.ch/~crossbow/rp/plugins/hfsc.html > > http://trash.net/~kaber/hfsc/ > > > > I'd be curious to see actual examples of usage, though. > > > > -- > > > > Jason Boxman > > Perl Programmer / *NIX Systems Administrator > > Shimberg Center for Affordable Housing | University of Florida > > http://edseek.com/ - Linux and FOSS stuff > > > > ___ > > LARTC mailing list / [EMAIL PROTECTED] > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > -- > To mess up a Linux box, you need to work at it; to mess up your Windows > box, you just need to work on it. > -- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: Problem with excess bandwidth distribution
Andy Furniss wrote: 1 $TC class add dev imq0 parent 1:1 classid 1:32 htb rate 133kbit ceil 400kbit prio 1 I meant to delete the prio 1 - I don't know if it matters - I tested with the other two. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] hfsc scheduler
On Friday 29 October 2004 19:06, yoyo wrote: > hi all, > > long time since i posted on the list. > just wondering if anybody has played around with hfsc and if so could > he/she share their info on it http://www-2.cs.cmu.edu/afs/cs.cmu.edu/user/hzhang/WWW/HFSC/ http://www.tik.ee.ethz.ch/~crossbow/rp/plugins/hfsc.html http://trash.net/~kaber/hfsc/ I'd be curious to see actual examples of usage, though. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] hfsc scheduler
hi all, long time since i posted on the list. just wondering if anybody has played around with hfsc and if so could he/she share their info on it thanks adrian -- To mess up a Linux box, you need to work at it; to mess up your Windows box, you just need to work on it. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: Problem with excess bandwidth distribution
Leslie Patrick Polzer wrote: Still problems :( I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after NAT, called it from prerouting, used u32 (matching works), set the root class to a rate of 800kBit (which is 200 less than my link speed) - and the behavior gets even worse :( Unfortunately, I cannot shape on the outgoing interfaces either, because there are two. I really don't know what to do now... I haven't dug deep into CBQ yet - should I try it? Hmm - this should work. I just cobbled together a test - It's not very elegant because it's based on a slightly different setup, but it works for me. I use default as my local traffic has a dynamic IP - you don't need to . Note the U32 filters are attached to 1:0 if I attached them to 1:1 than I would need a rule to send traffic to 1:1. I wouldn't trust the output of apps for bandwidth tests - their averaging can be confusing - also if it weren't just a test I would add queues to the classes. Saying that I did notice that HTB was dropping - maybe the default queue length is shorter now? It does seem a bit strange though, I see drops where I expect the queue to be long enough for my rwin and a class with two tcps on the go had less drops than one with one - strange. It did work though use tc -s class ls dev imq0 to see rates (which for me using the new TC seem to be shown in the wrong units). You may need to unwrap the lines if you copy n paste this: set -x IPTABLES=/usr/local/sbin/iptables MODPROBE=/sbin/modprobe IP=/sbin/ip TC=/sbin/tc $IPTABLES -t mangle -D PREROUTING -i ppp0 -j IMQ --todev 0 &> /dev/null $IP link set imq0 down &> /dev/null $MODPROBE -r imq &> /dev/null if [ "$1" = "stop" ] then echo "stopping" exit fi $MODPROBE imq numdevs=1 $IPTABLES -t mangle -I PREROUTING -i ppp0 -j IMQ --todev 0 $IP link set imq0 up $TC qdisc add dev imq0 root handle 1:0 htb default 34 $TC class add dev imq0 parent 1:0 classid 1:1 htb rate 400kbit ceil 400kbit burst 6k 1 $TC class add dev imq0 parent 1:1 classid 1:32 htb rate 133kbit ceil 400kbit prio 1 $TC filter add dev imq0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.2 flowid 1:32 2 $TC class add dev imq0 parent 1:1 classid 1:33 htb rate 133kbit ceil 400kbit $TC filter add dev imq0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.3 flowid 1:33 Default = traffic for local process $TC class add dev imq0 parent 1:1 classid 1:34 htb rate 133kbit ceil 400kbit Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: Problem with excess bandwidth distribution
Quoting Leslie Patrick Polzer <[EMAIL PROTECTED]>: > Still problems :( > > I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after > NAT, called it > from prerouting, used u32 (matching works), set the root class to a rate > of 800kBit > (which is 200 less than my link speed) - and the behavior gets even worse :( > > Unfortunately, I cannot shape on the outgoing interfaces either, because > there are two. Have you tried putting another machine as a bridge? (You dont need the IMQ in this case) - Elecciones Nacionales 2004 Consulte en el Portal donde votar http://www.montevideo.com.uy/elecciones2004 - ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] CBQ: sibling isolated-classes lend out bandwidth
How can it be, that class 1:3 in my case borrows, when all sibling classes are isolated ? nessus:~# tc -s -d class show dev eth1 class cbq 1: root rate 100Mbit cell 8b (bounded,isolated) prio no-transmit/8 weight 100Mbit allot 1514b level 2 ewma 5 avpkt 1000b maxidle 1us Sent 484 bytes 7 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 77 undertime 0 class cbq 1:1 parent 1: rate 768Kbit cell 8b (bounded,isolated) prio no-transmit/8 allot 1500b level 1 ewma 5 avpkt 1000b maxidle 3772us Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 47589 overactions 0 avgidle 123622 undertime 0 class cbq 1:2 parent 1:1 leaf 20: rate 702Kbit cell 8b (isolated) prio no-transmit/8 weight 8985bps allot 1500b level 0 ewma 5 avpkt 1000b maxidle 4129us Sent 0 bytes 0 pkts (dropped 0, overlimits 0) borrowed 0 overactions 0 avgidle 135332 undertime 0 class cbq 1:3 parent 1:1 leaf 30: rate 64Kbit cell 8b (isolated) prio no-transmit/8 weight 819bps allot 1500b level 0 ewma 5 avpkt 1000b maxidle 45584us Sent 68718965 bytes 47597 pkts (dropped 0, overlimits 0) borrowed 47589 overactions 0 avgidle -5.67627e+06 undertime 5.57184e+06 Greets Sebastian Spies <[EMAIL PROTECTED]>
Re: [LARTC] HTB: Problem with excess bandwidth distribution
On Friday 29 October 2004 11:36, Leslie Patrick Polzer wrote: > Still problems :( > > I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after > NAT, called it > from prerouting, used u32 (matching works), set the root class to a rate > of 800kBit > (which is 200 less than my link speed) - and the behavior gets even worse > :( Define worse? What metric are you using to measure the behavior? > Unfortunately, I cannot shape on the outgoing interfaces either, because > there are two. Wouldn't IMQ work for this too? > I really don't know what to do now... I haven't dug deep into CBQ yet - > should I try it? CBQ won't magically work over multiple interfaces without something like IMQ, just like HTB. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: Problem with excess bandwidth distribution
Still problems :( I upgraded to kernel 2.6.9 now, configured IMQ to hook itself up after NAT, called it from prerouting, used u32 (matching works), set the root class to a rate of 800kBit (which is 200 less than my link speed) - and the behavior gets even worse :( Unfortunately, I cannot shape on the outgoing interfaces either, because there are two. I really don't know what to do now... I haven't dug deep into CBQ yet - should I try it? Leslie ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: Problem with excess bandwidth distribution
Leslie Patrick Polzer wrote: Andy Furniss wrote: Leslie Patrick Polzer wrote: Hello, I have a serious problem with HTB which I wasn't able to solve myself. I run a masquerading router with ppp0 as interface to the Internet. Three clients need to share a downstream of 1 MBit, which I want to divide with tc. When I see a packet being forwarded to one of these clients, I give it the appropriate unique mark: iptables -t mangle -A FORWARD -d 192.168.34.141 -j MARK --set-mark 1 iptables -t mangle -A FORWARD -d 192.168.34.140 -j MARK --set-mark 2 iptables -t mangle -A FORWARD -d 192.168.1.2 -j MARK --set-mark 3 Because it might be of interest: 192.168.34.0/24 is on network A with 10 MBit, 192.168.1.0/24 is on network B with 100 MBit. I then attach an IMQ device imq0 to the FORWARD table: You can't use IMQ in forward AFAIK, see http://www.docum.org/docum.org/kptd/ Hmmm, really? I mean, all intended packets are going through it, no errors whatsoever. They are being marked correctly by iptables and tc filter classifies according to mark. The only problem seems to be the excess bandwidth distribution, which leaves me to the question: How could the hooks of IMQ and the excess bandwidth distribution of HTB relate in this setup? I hope you are understanding that I do not question your knowledge. I'm just not fully persuaded of this yet, so I'd like to discuss it a bit more. You are right to question me :-) - I was thinking a bit too much about my setup (At least I know that works). I use IMQ on ppp so I can shape traffic headed for local processes as well as forwarded. If you don't need to do this then you don't need to do it in prerouting anyway. I am guessing that calling IMQ from forward uses postrouting which is OK for your needs. I know from a test I did in prerouting that IMQ doesn't respect where in a table it gets called from. You could test by seeing if you can shape locally generated traffic marked in output I suppose. Wherever it hooks you need to set a rate less than link speed and if you use an old kernel, patch HTB. I said shaping from the wrong end of the bottleneck is a kludge because if I shape from the fat end then I control exactly what happens - I can arrange for my latency never to be increased by more than the time it takes for a packet my MTU long to be sent at my bitrate. As long as I tweak for link overheads I can use nearly 100% bandwidth. Incoming traffic from my ISP has already been through a 600ms fifo - it's never going to arrive at more than my link speed, so I need to set the ceils/rate totals to less than link speed - how much less will determine how fast the queue fills. The behavior of various types of queues is probably not the same as if they were at the other end of the bottleneck. There are also factors out of my control - TCP can get bursty when acks get buffered elsewhere. There may be packets in long buffers (mainly P2P) headed for me which are unstoppable, and my queue may not have any packets from active connections at any given time. The queue also reacts too late when the bandwidth changes - A new connection will be in TCP slowstart, which quite quickly will increase rate causing a temporary filling of ISP buffer - which hurts latency. It doesn't fill enough to cause drops, though, so as far as bandwidth allocation goes it's OK. My queues also drop a bit too much when this happens - causing TCP to resync which can be bursty. Andy. And thanks a lot for the additional information you gave me! Kind regards, Leslie ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Limiting Bandwidth of an ppp interfaces
On Fri, 2004-10-29 at 10:51 +0200, Leslie Patrick Polzer wrote: > Florian Taeger wrote: > Mark each incoming packets on pppn so you know where it is coming from. > Then attach n HTB classes below eth0's root and stuff each packet in its > class. Maybe not the best way to do. Script can be run when a ppp connection come up. Username (ppp login) is at this moment available as a variable environnement. Knowing that, you can then set up the correct QOS policy on the link. BR, -- Eric Leblond <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: Problem with excess bandwidth distribution
Andy Furniss wrote: Shaping from the narrow end of the bottleneck is a bit of a kludge, you have to set your rates/ceils lower than link speed or you won't have a queue to shape with. Could you also elaborate this a bit further? Many thanks so far! Leslie ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Limiting Bandwidth of an ppp interfaces
Florian Taeger wrote: Of course i read the docs, but I just don't know how exactly to generate the shape-filter for this. I know i have to establish a root entry and make another entry for every ppp device. but how do i connect the interfaces an the traffic ?!? How would I generate this "hard limit" for the traffic ? Like Andy Furniss wrote: Mark each incoming packets on pppn so you know where it is coming from. Then attach n HTB classes below eth0's root and stuff each packet in its class. Kind regards, Leslie ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Limiting Bandwidth of an ppp interfaces
Hi. > If the traffic from all the ppps leave by one interface then you could > mark packets by incoming interface and set up egress shaping with say > HTB on that interface. There is only one eth0 interface to the internet and many ppp for the users. So ... I have to shape every traffic from the ppp interfaces to eth0 (internet) and the same way around, don't I ?? How would it be done with htb ?? The problem ist - 50% of all the traffic on eth0 is to establish the ppp session through a l2tp tunnel and the other 50% are for the real traffic to the internet. So i only want to shape down the traffic from or to the ppp interfaces. But I can't shape the whole traffic on eth0. So ... will there be any problems regarding this ? Of course i read the docs, but I just don't know how exactly to generate the shape-filter for this. I know i have to establish a root entry and make another entry for every ppp device. but how do i connect the interfaces an the traffic ?!? How would I generate this "hard limit" for the traffic ? Many thanks for the help. Regards F.Taeger ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
