Short answer on a long, but excellent mail :) : You can try to use UMQ (can be found on the htb web-site). It will captu= re=20 all data before it's sended out so you can shape dynamic on all interface= s. Stef On Friday 29 March 2002 02:49, martin f krafft wrote: > hi all, > > at a small office, a customer employs a four-legged router/firewall > combination, running linux-2.4.18 + iptables. there is a dire need for > traffic shaping, and i am the poor soul that has to do it. > > my research concluded that i really want the classful HTB queuing > discipline [1]. i hope you guys don't see this question everyday, > i had no time for the archives. > > 1. http://luxik.cdi.cz/~devik/qos/htb/ > > anyway, so the router has four legs, ppp0/eth0 being a pppoe pair with > a dynamic IP to the internet, eth1 being a DMZ, eth2 connected to the > production and development LAN, and eth3 connected to the LAN shared > by "regular employees" (like secretaries etc.). > > the solution wanted by the IT team here is a classic case of dynamic > traffic shaping. they want the following division of the bandwidth in > both direction: > > upstream downstream > DMZ 70% 20% > LAN1 20% 50% > LAN2 10% 30% > > the way that QoS works on linux is that the queueing discipline acts > on the "far side" of the router, i.e. on the interface that sends the > data to the destination. > > this makes the "upstream" implementation quite easy because all > upstream traffic goes via ppp0/eth0, so i can simply create > u32 IP-subnet-based classifications and divide the 100% bandwidth > according the the above ratios. > > but downstream is a problem, because the company also requests that > the above percentages are "guarantees" but not upper limits, which > means that if LAN1 and the DMZ do not use any bandwidth at a given > moment, then LAN2 shall have 100%. > > realizing this in the upstream direction is one of the strengths of > HTB - it can do that and it's easy to do! but the downstream side > effectively distributes over three interfaces eth1-eth3, which means > that this kind of "borrowing" of bandwidth doesn't really work -- > a root qdisc is attached to a single interface, and bandwidth > borrowing only works within the hierarchy rooted at such a qdisc. > > are you aware of a means to make the qdisc at eth1 tell the qdisc's at > eth2 and eth3 if it has bandwidth to spare? > > and if this doesn't work, here's another thought: if i can put the > downstream traffic shaping *before* the routing decision within the > router, then this shouldn't be a problem. to do so, i need a virtual > interface that sits beetwen eth0 and the IP stack, like so: > > > ------------------------eth1------- > > > > > -------------- | routing | > > | internet |---eth0-----veth0------------ X -----eth2 > > -------------- | decision | > > > > > ------------------------eth3------- > > veth0 denotes a virtual interface, so the above is effectively two > systems in one, a two-legged router (eth0:veth0) and a four-legged > router (veth0:eth{1,2,3}). > > however, is it possible to create such a virtual interface? i've tried > a GRE tunnel, but couldn't get that to work. and if it were possible, > would veth0 suffice to be usable with a qdisc to shape traffic in both > directions? > > any thoughts appreciated... --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
