On Fri, 14 Jul 2000, Ian C.Sison wrote:
> CBQ is great for shaping bandwidth, but not conserving it. For HTTP traffic
> shaping and caching, you've got to go with squid's delay_pools. With this you
> actually have that same amount of control which is much more configurable IMHO,
> and scalable. However, you're only doing limits to HTTP/FTP traffic with this.
> For the napster enabled networks, policies have to be enforced with CBQ.
You'd probably also need to employ transproxy and ipchains with port
redirection for ports 80 and 20/21, to make sure that hosts don't
circumvent squid by simply not using it.
In my experience, cbq will not help conserve bandwidth if you have
unshaped traffic still passing through your network. For example, host A
has it's traffic shaped down to 128 kbps, while host B's traffic is
unmanaged. Host B can still hog all 10 or 100 mbps available with a
massive download. In this case, the cbq.init script works well as a
traffic limiter, but not as a traffic guarantor. If you want to implement
bandwidth management so that a host is assured of a certain maximum amount
of bandwidth at any given time, then traffic from all possible hosts on
the Lan must be shaped.
But if anyone who doesn't have a high end cisco router wants to give
bandwidth management a try, I still recommend cbq.init and iproute2.
Forget shapecfg and the shaper kernel module.. it only works up to 64
kbps...
Cito Maramba, M.D.
Asst. Prof, Univ. of the Phil. College of Medicine <[EMAIL PROTECTED]>
-
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
