Hi,
I have a router with 192.168.20.0/24 and 62.16.159.0/24 on eth0 and the
link ip 62.16.150.242 to the outside on eth1. (2 mbit)
a lot of ipchains rules create a firewall for everything, letting a few
services through to a few nodes, routes the 62.16.159.0 network 1:1 and
masqs the 192.168.20.0 nodes.
recently i tried settung up tc to limit the masqed traffic to 512k with
the following script:
(the original script and comments are taken from an example on the web,
the active lines are what i inserted to try to implement my needs)
---start---
#/bin/sh
# We have configured the ''queueing discipline'' of eth0. With
''root'' we
denote that this is the
# root discipline. We have
# given it the handle ''10:''. We want to do CBQ, so we mention
that on
the command line as well.
# We tell the kernel that it can allocate 10Mbit and that the average
# packet size is somewhere around 1000 octets.
#tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000
tc qdisc add dev eth1 root handle 2: cbq bandwidth 2Mbit avpkt 1000
# Now we need to generate our root class, from which all others descend:
# Even more numbers to worry about - the Linux CBQ implementation is
very generic.
# With ''parent 10:0'' we indicate that this class descends from
the root
of qdisc
# handle ''10:'' we generated earlier. With ''classid
10:1'' we name this
class.
# We really don''t tell the kernel a lot more, we just generate a class
that completely fills
# the available device. We also specify that the MTU (plus some
overhead) is 1514 octets.
# We also ''weigh'' this class with 1Mbit - a tuning parameter.
#tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 10Mbit
rate \
# 10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000
tc class add dev eth1 parent 2:0 classid 2:1 cbq bandwidth 2Mbit rate \
2Mbit allot 1514 weight 2Mbit prio 8 maxburst 20 avpkt 1000
# We now generate our ISP class:
# We allocate 8Mbit, and indicate that this class must not exceed this
by adding the ''bounded''
# parameter. Otherwise this class would have started borrowing bandwidth
from other classes,
# something we will discuss later on.
#tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 10Mbit
rate \
# 8Mbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 1000
bounded
#premium
tc class add dev eth1 parent 2:1 classid 2:100 cbq bandwidth 2Mbit rate
\
2Mbit allot 1514 weight 1500Kbit prio 5 maxburst 20 avpkt 1000
bounded
# To top it off, we generate the root Office class:
#tc class add dev eth0 parent 10:1 classid 10:200 cbq bandwidth 10Mbit
rate \
# 2Mbit allot 1514 weight 200Kbit prio 5 maxburst 20 avpkt 1000
bounded
#standard
tc class add dev eth1 parent 2:1 classid 2:200 cbq bandwidth 2Mbit rate
\
2Mbit allot 1514 weight 500Kbit prio 5 maxburst 20 avpkt 1000 bounded
# Ok, now we have told the kernel what our classes are, but not yet how
to manage the queues.
# We do this presently, in one fell swoop for both classes.
# In this case we install the Stochastic Fairness Queueing discipline
(sfq), which is not quite
# fair, but works well up to high bandwidths without burning up CPU
cycles.
# There are other queueing disciplines available which are better,
# but need more CPU. The Token Bucket Filter is often used.
#tc qdisc add dev eth0 parent 10:100 sfq quantum 1514b perturb 15
#tc qdisc add dev eth0 parent 10:200 sfq quantum 1514b perturb 15
#premium
tc qdisc add dev eth1 parent 2:100 sfq quantum 1514b perturb 15
#standard
tc qdisc add dev eth1 parent 2:200 sfq quantum 1514b perturb 15
# Now there is only one thing left to do and that is to explain to the
kernel which packets
# belong to which class. Initially we will do this natively with
iproute2, but more
# interesting applications are possible in combination with netfilter.
# Here it is assumed that our office hides behind a firewall with IP
address 150.151.23.24
# and that all our other IP addresses should be considered to be part of
the ISP.
# The u32 match is a very simple one - more sophisticated matching rules
are possible
# when using netfilter to mark our packets, which we can than match on
in tc.
#tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
dst \
# 150.151.23.24 flowid 10:200
#tc filter add dev eth0 parent 10:0 protocol ip prio 25 u32 match ip dst
\
# 150.151.0.0/16 flowid 10:100
#standard
tc filter add dev eth1 parent 2:0 protocol ip prio 100 u32 match ip dst
\
192.168.20.0/24 flowid 2:200
#premium
tc filter add dev eth1 parent 2:0 protocol ip prio 25 u32 match ip dst \
62.16.159.0/24 flowid 2:100
# Now we have fairly divided the downstream bandwidth, we need to do the
same for
# the upstream. For brevity''s sake, all in one go:
#tc qdisc add dev eth1 root handle 20: cbq bandwidth 10Mbit avpkt 1000
#tc class add dev eth1 parent 20:0 classid 20:1 cbq bandwidth 10Mbit
rate \
# 10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000
#tc class add dev eth1 parent 20:1 classid 20:100 cbq bandwidth 10Mbit
rate \
# 8Mbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 1000 \
# bounded
#tc class add dev eth1 parent 20:1 classid 20:200 cbq bandwidth 10Mbit
rate \
# 2Mbit allot 1514 weight 200Kbit prio 5 maxburst 20 avpkt 1000 \
# bounded
#tc qdisc add dev eth1 parent 20:100 sfq quantum 1514b perturb 15
#tc qdisc add dev eth1 parent 20:200 sfq quantum 1514b perturb 15
#tc filter add dev eth1 parent 20:0 protocol ip prio 100 u32 match ip
src \
# 150.151.23.24 flowid 20:200
#tc filter add dev eth1 parent 20:0 protocol ip prio 25 u32 match ip src
\
# 150.151.0.0/16 flowid 20:100
# By removing the ''bounded'' statements, classes will be able
to borrow
bandwidth from each other.
# Some classes may not wish to borrow their bandwidth to other classes.
Two rival ISPs
# on a single link may not want to offer each other freebees. In such a
case, you
# can add the keyword ''isolated'' at the end of your
''tc class add''
lines.
---end---
well, it doesnt work *g* no bandwidth limiting can be detected, works
like before.
can anybody tell me why? does it have to do with the fact that the
machine is masqing?
(I''m only limiting the download for now)
also, please give me a hint as to how to undo all these rules and
reverse the procedure.
thanks,
ethan
--
------------------------------------------------------------------------
Certified Microsoft MCSE, Cisco CCNA 2.0, Novell CNA 3.x
Arnold Datentechnik * Generaloberst-Beck-Str. 3/213 * D-55129 Mainz
+49(0)6131-5749-05/Fax -25 * Homepage: http://www.arnold-datentechnik.de