Hello Stef, Do you have some links related to this ? I am interested in knowing more about on this subject. kind regards, Marco At 09:06 AM 29/03/2002 +0100, you wrote: >Short answer on a long, but excellent mail :) : >You can try to use UMQ (can be found on the htb web-site). It will capture >all data before it's sended out so you can shape dynamic on all interfaces. > >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... > >-- > >stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.openprojects.net >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > Marco Adamo Fadl mailto:marco@avispa.net ·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`· making waves in a wireless world .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`
