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], which is not in the stock kernels, but for which
i made a custom 2.4.18 kernel with the HTB patch -- this much works,
but see my related post (to be posted after this) for a question on
HTB support in Debian woody's iproute package.
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.
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:
pgpR9aeXCy7kx.pgp
Description: PGP signature