[LARTC] shaping traffic on four-legged router

* [LARTC] shaping traffic on four-legged router
@ 2002-03-29  1:49 martin f krafft
  2002-03-29  8:06 ` Stef Coene
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: martin f krafft @ 2002-03-29  1:49 UTC (permalink / raw)
  To: lartc

[-- Attachment #1: Type: text/plain, Size: 3821 bytes --]

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...

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck

the micro$oft hoover: finally, a product that's supposed to suck!

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread