>>> No, attaching to the input is just as easy as to the output. The >>> reason that isn't implemented is that it wouldn't really be useful. >> You are full of it. > > If "it"=="knowledge", then you're probably right. No, I was aiming more for BS. > Since you only talk about dropping packets and never about queues, Well, naturally the way to decide what packets to drop is to have it go though various queues, but in the end it's all about dropping packets. > the following has been available for years in mainline kernels: > http://lartc.org/howto/lartc.adv-filter.policing.html Yes, but that doesn't change the fact that it's useless, there is no way to set up a HTB tree and assign SFQ's to each leaf like you can on the outbound traffic. On my network I have 41 subnets, each a /24 and each subnet needs to get a fair share of both inboud and outbound bandwidth. The 41 subnets are accessed from the gateway via 3 different network interfaces. Outbound shaping is easy and correct, there is just one HTB tree with an SFQ for each subnet. Inbound shaping is ugly and incorrect, because I have to have 3 different HTB trees (one for each internal interface) that each has to get 1/3 (actually weighted by number of subnets behind each interface) of the total bandwidth. That means that max downstream is 800kb/s for the users where it ought to be 1600kb/s, which sucks because most traffic to the users is very bursty. It would have been a much nicer design to be able to put the 3 inbound HTB trees into one inbound tree on the external interface, just like the outbound tree. Ingress shaping *is* very useful and it's a pity that Linux has taken this long to gain support for it. -- Flemming Frandsen, NrVissing.Net administrator. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc