--SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck =20 the micro$oft hoover: finally, a product that's supposed to suck! --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjyjyCMACgkQIgvIgzMMSnXOPACg7f4Rf1rWm9301nxf2OCFLbDk QMgAoNYhyCoYtVk2D+QmTnFUgmDrCLAF =omUl -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--
