On Friday 29 March 2002 09:41, Marco Adamo Fadl wrote: > Hello Stef, > > Do you have some links related to this ? > I am interested in knowing more about on this subject. Oeps. it's the IMQ qdisc. And all info can be found on http://luxik.cdi.cz/~devik/qos/imq.htm I never tried it, but it's so easy, that it works. It creates a new devi= ce=20 (don't forget to do ifconfig imq up) that contains all data before it's=20 sended out. Stef > > 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 a= ll > > 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 f= or > >> 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 wi= th > >> a dynamic IP to the internet, eth1 being a DMZ, eth2 connected to th= e > >> 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 i= n > >> 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 th= e > >> 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 tri= ed > >> 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 bo= th > >> 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 > > =B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF= `=B7 > > making waves in a wireless world > > .=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF= ` > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
