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@xxxxxxxxxxxxxx
