'Re: [LARTC] shaping traffic on four-legged router'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lartc
Subject:    Re: [LARTC] shaping traffic on four-legged router
From:       Stef Coene <stef.coene () docum ! org>
Date:       2002-03-29 10:20:45
[Download RAW message or body]

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 device 
(don't forget to do ifconfig imq up) that contains all data before it's 
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 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
>
> .ЗДЏ`З.ИИ.ЗДЏ`З.ИИ.ЗДЏ`З.ИИ.ЗДЏ`
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

-- 

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/
[prev in list] [next in list] [prev in thread] [next in thread] 