Dear all, I want to shape both incoming and outgoing traffic with HTB. Since the first time i applied HTB, i only limit incoming traffic from internet, while the outgoing traffic is unlimited and now these days my outgoing traffic really getting higher. INTERNET ----- eth0 | BW.MANAGER | eth1 --- LAN #!/bin/sh tc qdisc del dev eth0 root tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1 htb default 0 r2q 50 tc class add dev eth1 parent 1: classid 1:2 htb rate 120Kbit ceil 120Kbit tc qdisc add dev eth1 parent 1:2 handle 2 sfq perturb 10 quantum 1500 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip src 0.0.0.0/0 match ip dst 192.168.0.0/19 classid 1:2 tc qdisc add dev eth0 root handle 2 htb default 0 r2q 50 tc qdisc add dev eth0 parent 2:10 handle 10 sfq perturb 10 quantum 1500 tc class add dev eth0 parent 2: classid 2:10 htb rate 20Kbit ceil 20Kbit tc filter add dev eth0 parent 2:0 protocol ip prio 100 u32 match ip src 192.168.0.0/19 match ip dst 0.0.0.0/0 classid 2:10 #End of script I applied, but none of outgoing traffic match class 2:10 I need help about this, Regards, Rio Martin. - "When in doubt, tell the truth." -- Mark Twain _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Martin A. Brown
2003-Jul-22 02:41 UTC
Re: Shape both incoming and outgoing traffic with HTB ?
Hello Rio Martin, : I want to shape both incoming and outgoing traffic with HTB. Since the : first time i applied HTB, i only limit incoming traffic from internet, : while the outgoing traffic is unlimited and now these days my outgoing : traffic really getting higher. : : INTERNET ----- eth0 | BW.MANAGER | eth1 --- LAN This is not an uncommon problem for masquerading or SNATting hosts. In short, your upload traffic has already been masqueraded/SNATted, so you no longer have a source IP of 192.168.0.0/19. The best thing to do is to use fwmark to mark the traffic with iptables/ipchains (whichever you are using) and classify the outbound traffic according to the fwmark. See the LARTC documentation on this topic [1]. -Martin [1] http://lartc.org/howto/lartc.qdisc.filters.html#LARTC.FILTERING.SIMPLE -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tuesday 22 July 2003 09:41, Martin A. Brown wrote:> Hello Rio Martin, > : I want to shape both incoming and outgoing traffic with HTB. Since the > : first time i applied HTB, i only limit incoming traffic from internet, > : while the outgoing traffic is unlimited and now these days my outgoing > : traffic really getting higher. > : INTERNET ----- eth0 | BW.MANAGER | eth1 --- LAN > This is not an uncommon problem for masquerading or SNATting hosts. In > short, your upload traffic has already been masqueraded/SNATted, so you no > longer have a source IP of 192.168.0.0/19.Yes, you re right. I tried entering my public ip for the match ip src, and it goes smoothly shaped.> The best thing to do is to use fwmark to mark the traffic with > iptables/ipchains (whichever you are using) and classify the outbound > traffic according to the fwmark. See the LARTC documentation on this > topic [1].Yes i realized that if i didnt use fwmark, it will be hard to manage outgoing traffic from all different network i managed down here. Thanks .. Regards, Rio Martin. -- 43rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I can''t find any documentation on the paramaters for the ingress qdisc. Can someone help me? I have a number of filters feeding into my ingress qdisc, all of which are rate limited, but I want to place a limit on the aggregate flow as well. I don''t want to monitor the sum of the flow rates - I want to place a hard ceiling on the total possible flow that overrides everything else. Any further details about the internal workings of the ingress qdisc would also be very helpful. I''ve seen some stuff that suggests its really a TBF in disguise, but I''m not sure. In particular, I''d like to understand if the flows into the ingress qdisc can borrow from the root and/or each other. Also, since the ingress qdisc is classless, how does it work that each of the incoming flows are separately metered? (As I understand it, filters only serve to guide packets into classes) I know that the IMQ device offers a more sophisticated way to do this but, for now, that device is not available to me. I need answers to these specific questions, but I very much appreciate any other information anyone would like to volunteer. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tuesday 05 August 2003 22:59, Patrick Turley wrote:> I can''t find any documentation on the paramaters for the ingress qdisc. > Can someone help me? > > I have a number of filters feeding into my ingress qdisc, all of which > are rate limited, but I want to place a limit on the aggregate flow as > well. I don''t want to monitor the sum of the flow rates - I want to > place a hard ceiling on the total possible flow that overrides > everything else. > > Any further details about the internal workings of the ingress qdisc > would also be very helpful. I''ve seen some stuff that suggests its > really a TBF in disguise, but I''m not sure. In particular, I''d like to > understand if the flows into the ingress qdisc can borrow from the root > and/or each other. Also, since the ingress qdisc is classless, how does > it work that each of the incoming flows are separately metered? (As I > understand it, filters only serve to guide packets into classes) > > I know that the IMQ device offers a more sophisticated way to do this > but, for now, that device is not available to me. > > I need answers to these specific questions, but I very much appreciate > any other information anyone would like to volunteer.The ingress qdisc itself has no parameters. The only thing you can do is using the policers. I have a link with a patch to extend this : http://www.cyberus.ca/~hadi/patches/action/ Maybe this can help. I have some more info about ingress in my mail files, but I have to sort it out and put it somewhere on docum.org. But I still didn''t found the the time to do so. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Thank you very much for the link. That information was very helpful and has given me a lot of insight. Of course, the more I know, the more questions occur... I try not to be a nuisance, so I''ve been doing a lot of research and I thought I''d already found all the important web sites for Linux traffic control. I looked again, and I still can''t find anything about "filter policers" anywhere. I didn''t find any description of a command line that even suggested such a thing was possible. Can you please point me to some more info about this, if any exists? The fact that the filters are metering traffic flows implies that they have are stateful. When using filters with egress queue hierarchies, it was my understanding that no state was needed since all they do is direct packets into classes. It sounds like my current understanding is quite wrong. BTW, we are working with a stock RedHat 7.3 2.4.20-18.7 kernel, and we are VERY reluctant to apply patches of any kind, so we''re just going to work with whatever is available in the bits we download. We''re considering moving up to 2.4.21 to get IMQ, but that doesn''t appear to be available for RedHat 7.3 yet - in fact, this may force us to RedHat 9.0 (not a bad thing, really). On Tue, 2003-08-05 at 16:15, Stef Coene wrote:> On Tuesday 05 August 2003 22:59, Patrick Turley wrote: > > I can''t find any documentation on the paramaters for the ingress qdisc. > > Can someone help me? > > > > ... > The ingress qdisc itself has no parameters. The only thing you can do is > using the policers. I have a link with a patch to extend this : > http://www.cyberus.ca/~hadi/patches/action/ > Maybe this can help. > > I have some more info about ingress in my mail files, but I have to sort it > out and put it somewhere on docum.org. But I still didn''t found the the time > to do so. > > Stef_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Wednesday 06 August 2003 00:11, Patrick Turley wrote:> Thank you very much for the link. That information was very helpful and > has given me a lot of insight. > > Of course, the more I know, the more questions occur... > > I try not to be a nuisance, so I''ve been doing a lot of research and I > thought I''d already found all the important web sites for Linux traffic > control. I looked again, and I still can''t find anything about "filter > policers" anywhere. I didn''t find any description of a command line that > even suggested such a thing was possible. Can you please point me to > some more info about this, if any exists?There also some limited example scripts in the iproute2 source.> The fact that the filters are metering traffic flows implies that they > have are stateful. When using filters with egress queue hierarchies, it > was my understanding that no state was needed since all they do is > direct packets into classes. It sounds like my current understanding is > quite wrong.I don''t think the filters are statefull. If you use policers, you only rate limit the filters. The filters itself have no idea about the traffic flows.> BTW, we are working with a stock RedHat 7.3 2.4.20-18.7 kernel, and we > are VERY reluctant to apply patches of any kind, so we''re just going to > work with whatever is available in the bits we download. We''re > considering moving up to 2.4.21 to get IMQ, but that doesn''t appear to > be available for RedHat 7.3 yet - in fact, this may force us to RedHat > 9.0 (not a bad thing, really).Why don''t you download the kernel source 7.3 2.4.20-18.7 from RH and the config file? So you have the same source as the kernel you trust. If you trust that source, you can pacth it with what ever you want. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> > I still can''t find anything about "filter > > policers" anywhere. I didn''t find any description of a command line that > > even suggested such a thing was possible. Can you please point me to > > some more info about this, if any exists? > There also some limited example scripts in the iproute2 source.OK - I''ll have a look at those scripts to see how one can associate policers with filters.> > The fact that the filters are metering traffic flows implies that they > > have are stateful. When using filters with egress queue hierarchies, it > > was my understanding that no state was needed since all they do is > > direct packets into classes. It sounds like my current understanding is > > quite wrong. > I don''t think the filters are statefull. If you use policers, you only rate > limit the filters. The filters itself have no idea about the traffic flows.Then there are two further questions (the first of which I actually should have asked before): 1) When working with egress traffic control, filters are attached to classes. The documents I''ve read so far tell me that the ingress qdisc is classless so, on the face of it, filters shouldn''t be useable at all. Please tell me which part of this I have badly misunderstood. 2) Since the filters themselves are, as you say, stateless, then it sounds like a "policer" is a separate object that''s being created at the same time as the filter. Is there any other way to create a "policer" object, or do they only exist when attached to filters? When working with egress traffic control, can you attach policers to filters, and how would they interact with the classes?> > BTW, we are working with a stock RedHat 7.3 2.4.20-18.7 kernel, and we > > are VERY reluctant to apply patches of any kind, so we''re just going to > > work with whatever is available in the bits we download. We''re > > considering moving up to 2.4.21 to get IMQ, but that doesn''t appear to > > be available for RedHat 7.3 yet - in fact, this may force us to RedHat > > 9.0 (not a bad thing, really). > Why don''t you download the kernel source 7.3 2.4.20-18.7 from RH and the > config file? So you have the same source as the kernel you trust. If you > trust that source, you can pacth it with what ever you want.Our problem is not really with "trust". Our problem is that we have very limited staff, and we don''t want to open up a whole new area of effort. Using "stock" kernels and not having to compile them means that none of us have to go through the effort of managing all that. We have the expertise, we just don''t have the time. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Wednesday 06 August 2003 20:41, Patrick Turley wrote:> > > The fact that the filters are metering traffic flows implies that they > > > have are stateful. When using filters with egress queue hierarchies, it > > > was my understanding that no state was needed since all they do is > > > direct packets into classes. It sounds like my current understanding is > > > quite wrong. > > > > I don''t think the filters are statefull. If you use policers, you only > > rate limit the filters. The filters itself have no idea about the > > traffic flows. > > Then there are two further questions (the first of which I actually > should have asked before): > > 1) When working with egress traffic control, filters are attached to > classes. The documents I''ve read so far tell me that the ingress qdisc > is classless so, on the face of it, filters shouldn''t be useable at all. > Please tell me which part of this I have badly misunderstood.Ingress is indeed classless, but you can filters on it. It''s not important where the filters point to because there are no classes. But you can add policers to the filters.> 2) Since the filters themselves are, as you say, stateless, then it > sounds like a "policer" is a separate object that''s being created at the > same time as the filter. Is there any other way to create a "policer" > object, or do they only exist when attached to filters? When working > with egress traffic control, can you attach policers to filters, and how > would they interact with the classes?You have to see the policer as a small tbf qdisc that exists on his own. If you add the policer to a filter, all packets are "queued" in the policer and throttled. You can also use the same policer on different filters. So the packets from different filters are "queued" in the same policer. To do so, you need the tcindex option. I will dig in my mail archive and put online on www.docum.org what I can find. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Wednesday 06 August 2003 21:23, Stef Coene wrote:> I will dig in my mail archive and put online on www.docum.org what I can > find.The only thing I found was : http://www.docum.org/stef.coene/qos/faq/cache/69.html Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Patrick Turley
2003-Aug-06 21:14 UTC
HTB : quantum of class <class ID> is small. Consider r2q change.
I have a number of classes with HTB qdiscs feeding into a root HTB qdisc. Whenever I set the rate on any of the subordinate qdiscs to 78 kpbs or less, I get the following message: HTB : quantum of class <class ID> is small. Consider r2q change. I have no clue what this means or how I might fix it. Can anyone help? _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Patrick Turley
2003-Aug-06 21:26 UTC
Re: HTB : quantum of class <class ID> is small. Consider r2q change.
Oops - I just discovered Stef''s FAQ search capability and found the answer for myself. For those who are interested: http://qos.dyndns.org:3389/cgi-bin/fom?&file=31 On Wed, 2003-08-06 at 16:14, Patrick Turley wrote:> I have a number of classes with HTB qdiscs feeding into a root HTB > qdisc. Whenever I set the rate on any of the subordinate qdiscs to 78 > kpbs or less, I get the following message: > > HTB : quantum of class <class ID> is small. Consider r2q change. > > I have no clue what this means or how I might fix it. Can anyone help? > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Patrick Turley
2003-Aug-06 21:52 UTC
Re: HTB : quantum of class <class ID> is small. Consider r2q change.
Oops again. While the note I indicated below is VERY informative, it''s not at all clear why HTB would complain if the rate is 78Kbit - that corresponds to a quantum of 7800 bytes, which is plenty large. Yes, I know I said I mispelled "kpbs" below, and I also know that the correct way to say "kilobits per second" to HTB is to say "Kbit". On Wed, 2003-08-06 at 16:26, Patrick Turley wrote:> Oops - I just discovered Stef''s FAQ search capability and found the > answer for myself. For those who are interested: > > http://qos.dyndns.org:3389/cgi-bin/fom?&file=31 > > On Wed, 2003-08-06 at 16:14, Patrick Turley wrote: > > I have a number of classes with HTB qdiscs feeding into a root HTB > > qdisc. Whenever I set the rate on any of the subordinate qdiscs to 78 > > kpbs or less, I get the following message: > > > > HTB : quantum of class <class ID> is small. Consider r2q change. > > > > I have no clue what this means or how I might fix it. Can anyone help? > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello all,
I played a bit with the ingress qdisc after seeing Patrick and Stef
talking about it and came up with a few notes and a few questions.
: The ingress qdisc itself has no parameters. The only thing you can do
: is using the policers. I have a link with a patch to extend this :
: http://www.cyberus.ca/~hadi/patches/action/ Maybe this can help.
:
: I have some more info about ingress in my mail files, but I have to
: sort it out and put it somewhere on docum.org. But I still didn''t
: found the the time to do so.
Regarding policers and the ingress qdisc. I have never used them before
today, but have the following understanding.
About the ingress qdisc:
- ingress qdisc (known as "ffff:") can''t have any children
classes
(hence the existence of IMQ)
- the only thing you can do with the ingress qdisc is attach filters
About filtering on the ingress qdisc:
- since there are no classes to which to direct the packets, the only
reasonable option (reasonable, indeed!) is to drop the packets
- with clever use of filtering, you can limit particular traffic
signatures to particular uses of your bandwidth
Here''s an example of using an ingress policer to limit inbound traffic
from a particular set of IPs on a per IP basis. In this case, traffic
from each of these source IPs is limited to a T1''s worth of bandwidth.
Note that this means that this host can receive up to 1536kbit (768kbit +
768kbit) worth of bandwidth from these two source IPs alone.
# -- start of script
#! /bin/ash
#
# -- simulate a much smaller amount of bandwidth than the 100MBit interface
#
RATE=1536kbit
DEV=eth0
SOURCES="10.168.53.2/32 10.168.73.10/32 10.168.28.20/32"
# -- attach our ingress qdisc
#
tc qdisc add dev $DEV ingress
# -- cap bandwidth from particular source IPs
#
for SOURCE in $SOURCES ; do
tc filter add dev $DEV parent ffff: protocol ip \
u32 match ip src $SOURCE flowid :1 \
police rate $RATE mtu 12k burst 10k drop
done
# -- end of script
Now, if you are using multiple public IPs on your masquerading/SNAT host,
you can use "u32 match ip dst $PER_IP" with a drop action to force a
particular rate on inbound traffic to that IP.
My entirely unquantified impression is that latency suffers as a result,
but traffic is indeed bandwidth limited.
Just a few notes of dissection:
tc filter add dev $DEV # -- the usual beginnings
parent ffff: # -- the ingress qdisc itself
protocol ip # -- more preamble | make sure to visit
u32 match ip # -- u32 classifier | http://lartc.org/howto/
src $SOURCE # -- could also be "dst $SOME_LOCAL_IP"
flowid :1 # -- ??? (but it doesn''t work without this)
police rate $RATE # -- put a policer here
mtu 12k burst 10k # -- ???
drop # -- drop packets exceeding our police params
Maybe a guru or two out there (Stef?, Bert?, Jamal?, Werner?) can explain
why mtu needs to be larger than 1k (didn''t work for me anyway) and also
how these other parameters should be used.
I''ll add a few questions:
Why does policing fail entirely without "flowid :1"?
(There''s no flow!)
Why does the policer drop all traffic if mtu is small?
How are mtu and burst used?
Oh yes, and "Ah, that''s linux!"
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Patrick, As far as I''m concerned, these are two very good questions. : 1) When working with egress traffic control, filters are attached to : classes. The documents I''ve read so far tell me that the ingress : qdisc is classless so, on the face of it, filters shouldn''t be : useable at all. Please tell me which part of this I have badly : misunderstood. Agreed....it doesn''t make sense, to me, except as code reuse. Any takers care to explain why this is? : 2) Since the filters themselves are, as you say, stateless, then it : sounds like a "policer" is a separate object that''s being created at : the same time as the filter. Is there any other way to create a : "policer" object, or do they only exist when attached to filters? My understand is that the policers only exist attached to filters. They are separate, but not able to be generated without a filter. I think Stef''s description isn''t so bad....a policer is similar to a token bucket filter (TBF) which is attached to a filter. I don''t know what it looks like inside the policing code, so I''ll have to assume that this is correct. From the outside of the black box, they are pretty much rate limiters which you can attach to any "tc filter" command. : When working with egress traffic control, can you attach policers : to filters, Yes. : and how would they interact with the classes? When a new packet arrives on an output queue prior to outbound traffic control (but after netfilter POSTROUTING), the packet will first traverse the filters attached to qdisc 1:0 to learn of its destination flowid. Here, you could have a number of different filters which classify and/or reclassify the packet into different output classes/qdiscs. You could optionally drop packets with a filter here, just as you could drop packets with filters on the ingress qdisc. These policers will be VERB (executed? obeyed?) before the packet ever enters the classes and sub-classes. -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
First of all, thank you Martin - this is fabulously helpful. On Wed, 2003-08-06 at 20:18, Martin A. Brown wrote:> Hello all, > > I played a bit with the ingress qdisc after seeing Patrick and Stef > talking about it and came up with a few notes and a few questions. > > ... > > About filtering on the ingress qdisc: > > - since there are no classes to which to direct the packets, the only > reasonable option (reasonable, indeed!) is to drop the packets > > - with clever use of filtering, you can limit particular traffic > signatures to particular uses of your bandwidthThat sounds like a correct statement about the filters themselves. But it appears that we don''t have to just drop the packets, because the policers we attach to the filters CAN queue packets. The following quote is from one of Stef''s earlier replies:> You have to see the policer as a small tbf qdisc that exists on his own. If > you add the policer to a filter, all packets are "queued" in the policer and > throttled.Martin continues...> Here''s an example of using an ingress policer to limit inbound traffic > from a particular set of IPs on a per IP basis. In this case, traffic > from each of these source IPs is limited to a T1''s worth of bandwidth. > Note that this means that this host can receive up to 1536kbit (768kbit + > 768kbit) worth of bandwidth from these two source IPs alone. > > # -- start of script > #! /bin/ash > # > # -- simulate a much smaller amount of bandwidth than the 100MBit interface > # > RATE=1536kbit > DEV=eth0 > SOURCES="10.168.53.2/32 10.168.73.10/32 10.168.28.20/32" > > # -- attach our ingress qdisc > # > tc qdisc add dev $DEV ingressI don''t see a handle argument here. I presume that, since the ingress handle for an interface MUST be ffff, that the handle argument is optional. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Wed, 2003-08-06 at 20:37, Martin A. Brown wrote:> : 2) Since the filters themselves are, as you say, stateless, then it > : sounds like a "policer" is a separate object that''s being created at > : the same time as the filter. Is there any other way to create a > : "policer" object, or do they only exist when attached to filters? > > My understand is that the policers only exist attached to filters. They > are separate, but not able to be generated without a filter. I think > Stef''s description isn''t so bad....a policer is similar to a token bucket > filter (TBF) which is attached to a filter. I don''t know what it looks > like inside the policing code, so I''ll have to assume that this is > correct. From the outside of the black box, they are pretty much rate > limiters which you can attach to any "tc filter" command.>From what Stef says, the documentation on the TC_INDEX qdisc illuminatesthe use and structure of policers. I''ve looked TC_INDEX only very briefly. I mention this here only so that anyone else who is interested will have the pointer.> : When working with egress traffic control, can you attach policers > : to filters, > > Yes. > > : and how would they interact with the classes? > > When a new packet arrives on an output queue prior to outbound traffic > control (but after netfilter POSTROUTING), the packet will first traverse > the filters attached to qdisc 1:0 to learn of its destination flowid. > Here, you could have a number of different filters which classify and/or > reclassify the packet into different output classes/qdiscs. You could > optionally drop packets with a filter here, just as you could drop packets > with filters on the ingress qdisc. > > These policers will be VERB (executed? obeyed?) before the packet ever > enters the classes and sub-classes.OK - This is very interesting to me. I understand the mechanism whereby filters guide packets to the classes for which they are destined. That all makes sense. Based on what I''ve read here, it sounds like you can interpose a policer between the filter itself and the class to which it is directing packets. Given that classes already have access to the full range of qdiscs, with all their marvelous dials and knobs, interposing a policer seems superfluous. Have I misunderstood? _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
(This is a re-statement of a question I asked earlier)
I have a number of HTB classes feeding into a root HTB qdisc. Whenever I
set the rate on any of the subordinate classes to 78 kpbs or less, I get
the following message:
HTB : quantum of class <class ID> is small. Consider r2q change.
I''ve done some reading about the meaning of r2q, and I understand it
now:
quantum = rate/r2q
where:
rate is expressed in kilobits per second
quantum is expressed in bytes
r2q has the appropriate units and is 10 by default
Based on what I''ve read, it''s not at all clear why HTB would
complain
about a rate of 78Kbit. That corresponds to a quantum of 7800 bytes,
which is much larger than the maximum Ethernet packet size (1500).
Anyone have a clue?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Friday 08 August 2003 00:20, Patrick Turley wrote:> (This is a re-statement of a question I asked earlier) > > I have a number of HTB classes feeding into a root HTB qdisc. Whenever I > set the rate on any of the subordinate classes to 78 kpbs or less, I get > the following message: > > > HTB : quantum of class <class ID> is small. Consider r2q change. > > > I''ve done some reading about the meaning of r2q, and I understand it > now: > > quantum = rate/r2q > > where: > > rate is expressed in kilobits per second > quantum is expressed in bytes > r2q has the appropriate units and is 10 by default > > Based on what I''ve read, it''s not at all clear why HTB would complain > about a rate of 78Kbit. That corresponds to a quantum of 7800 bytes, > which is much larger than the maximum Ethernet packet size (1500). > > Anyone have a clue?Yes. 78kbit = 9.75kbyte. So quantum = 9.75kilobyte/10 = 975byte. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Fri, 2003-08-08 at 00:51, Stef Coene wrote:> On Friday 08 August 2003 00:20, Patrick Turley wrote: > > (This is a re-statement of a question I asked earlier) > > > > I have a number of HTB classes feeding into a root HTB qdisc. Whenever I > > set the rate on any of the subordinate classes to 78 kpbs or less, I get > > the following message: > > > > > > HTB : quantum of class <class ID> is small. Consider r2q change. > > > > > > I''ve done some reading about the meaning of r2q, and I understand it > > now: > > > > quantum = rate/r2q > > > > where: > > > > rate is expressed in kilobits per second > > quantum is expressed in bytes > > r2q has the appropriate units and is 10 by default > > > > Based on what I''ve read, it''s not at all clear why HTB would complain > > about a rate of 78Kbit. That corresponds to a quantum of 7800 bytes, > > which is much larger than the maximum Ethernet packet size (1500). > > > > Anyone have a clue? > Yes. 78kbit = 9.75kbyte. So quantum = 9.75kilobyte/10 = 975byte. > > Stef<blush> OK, I wish I hadn''t made that silly mistake. 79Kbit = 80896 bits/sec = 10112 bytes/sec 10112 bytes/sec / 10 r2q => quantum > 1000 bytes I conclude, then, that HTB will spit out a warning when the quantum implied by the subclass drops below 1000 bytes. This is useful information. As I said before, I have a number of classes feeding into the root. These classes can have widely varying rate limits, and they can change dynamically. Therefore, to avoid encountering the problem that this message indicates, I need to estimate the lowest reasonable rate limit and select an r2q that will just barely keep this rate''s quantum above 1000. A lower rate limit of 50Kbit seems reasonable for my application: 50Kbit = 51200 bits/sec = 6400 bytes/sec 6400 bytes/sec / 1000 bytes = 6 r2q According to Stef''s FAQ at http://qos.dyndns.org:3389/cgi-bin/fom?_highlightWords=r2q&file=31, the buit-in limit for the quantum is 60000 bytes. Even though I''ve reduced the value of r2q, I still won''t hit this limit until the rate exceeds: 60000 bytes * 6 r2q = 360000 bytes/sec => 2.74Mbit This is acceptable. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
: OK - This is very interesting to me. I understand the mechanism whereby : filters guide packets to the classes for which they are destined. That : all makes sense. : : Based on what I''ve read here, it sounds like you can interpose a : policer between the filter itself and the class to which it is : directing packets. Given that classes already have access to the full : range of qdiscs, with all their marvelous dials and knobs, interposing : a policer seems superfluous. Have I misunderstood? Well, I wouldn''t say superfluous.....and I don''t think you have misunderstood, but perhaps you don''t yet see the rationale for a policer. Let me suggest a scenario. You have users who send mail.* You wish to guarantee a certain small percentage of your 2Mbit to only the SMTP traffic, so that at least 256kbit is reserved for mail at any time. Additionally, you want to put any SMTP flows above this 256kbit into a general consumption class. Well, your policer reclassifies any traffic above a given rate into the general consumption class. That''s just one way of using a policer. My understanding is that policers are more commonly used for DiffServ domains and limiting inbound traffic, although there''s nothing preventing them from being used in ingress traffic situations. -Martin * I know it sounds incredible for me to suggest that a network admin might have users, but suspend your disbelief for now, if you can. -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/