Hi Nikolay,
Thanks very much for your help - the script is now working. The downlink
shaping works as expected, but the uplink shaping seems to give 4 times
more bandwidth than it ought to - so I've just divided the number by 4
and it is satisfactory.
However, I've now discovered that pings
Hello,
You need to recompile your kernel and include the appropriate modules
for htb to work.
The other idea I have is to use policer to filter how much traffic PCs
in the LAN upload. This is done on the LAN interface. Eliminates the
need to mark packets, etc.
You just drop all the packets that
Hi Nikolay,
Thanks for your help - this looks useful. Is it possible to apply a
police filter invidiually to each IP behind the NAT?
Thanks,
Jonathan
Nikolay Kichukov wrote:
Hello,
You need to recompile your kernel and include the appropriate modules
for htb to work.
The other idea I have
Hello Jonathan,
Indeed. I have tested with limited number of IPs though. Not sure how
that scheme will behave if you apply it to a huge network.
Cheers,
-Nikolay
Jonathan Gazeley wrote:
Hi Nikolay,
Thanks for your help - this looks useful. Is it possible to apply a
police filter invidiually
Hi Nikolay,
How might this be implemented? I have used a shell script that loops
around with a new IP address each time, and then my police line looks
like this:
tc filter add dev $LAN parent 1: protocol ip prio 50 u32 match ip src
137.222.$j.$i police rate ${UPLINK}kbit burst 10k drop
Hello,
The policer is not 1: but :, not engress(root) but ingress.
Let me give you an example:
tc qdisc add dev eth0 ingress handle :
TC_FILTER=tc filter add dev eth0 parent : protocol ip
$TC_FILTER prio 2 u32 match ip src 192.168.0.6/32 police rate 32kbit
burst 16kb drop flowid
Hello Jonathan,
The scenario works perfectly well on a NAT router. See, you drop excess
of bits on the interface where the packets arrive. Which is before
nating. Maybe we speak about different scenarios here?
What I describe limits the maximum upload speed for ip in the LAN.
Let me know the
Hello Jonathan.
At 2007-07-30 12:40:00 +0100, [EMAIL PROTECTED] wrote:
So far I have managed to get the download limits working. However I
need to shape on both interfaces so I recycled the same code to apply
to uploads but it didn't work and I can't figure out why
That's not really enough
Hi Abhijit,
Thanks a lot for your advice - I didn't realise that the source IP was
re-written before the traffic was shaped.
I have attached the script I wrote. As I said before, the download limit
does successfully work and each client (I am using 2 test clients) gets
512kbit each. However
At 2007-07-30 14:16:22 +0100, [EMAIL PROTECTED] wrote:
I don't really understand that error - especially as the identical
code does work for the download limits.
I think it's only that you define $WAN and later use $wAN, so tc thinks
it's missing an argument, and gets confused.
-- ams
Eck, how embarrassing. Thanks for that - now fixed. I still get errors
though:
137.222.235.125
Error: Qdisc tbf is classless.
Error: Qdisc tbf is classless.
Any ideas what's broken? I'm not so hot on classful queueing disciplines!
Cheers,
Jonathan
Jonathan Gazeley
At 2007-07-30 14:36:03 +0100, [EMAIL PROTECTED] wrote:
137.222.235.125
Error: Qdisc tbf is classless.
Error: Qdisc tbf is classless.
One of these is from the $LAN line, and one from the $WAN one, right?
Any ideas what's broken? I'm not so hot on classful queueing
disciplines!
It's not
As far as I'm concerned, it doesn't matter what I use, so long as I get
the result - I just need to have each user alloted a certain upload and
download speed. Nothing too fancy.
I tried switching to HTB. I amended my commands but I don't know if my
kernel supports it. I've got CentOS 5.0
On Mon, Jul 30, 2007 at 02:58:00PM +0100, Jonathan Gazeley wrote:
[...]
137.222.235.125
RTNETLINK answers: No such file or directory
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
RTNETLINK answers: No such file or directory
RTNETLINK answers: Invalid argument
We
14 matches
Mail list logo
