RE: [LARTC] Lots amounts of classes to solve the DAP problem

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there stef, since it does not work with the set up i sent you, i am thinking in changing the qdiscs to esfq. I will try that today and see what happens. Another question.. With the scripts i sent to the mailing list, there is an enormous amount of rules in the PREROUTING mangle section. Since each user has 1 class and those classes 2 marks to distinguish between interactive and noninteractive traffic. Thats more than 500 entries. I am not sure if thats a bit "too mutch" so i thought adding filters on eth0 and eth2 in the root qdisc and then based on the src address send it to the class, and there have tc filtres based on marks, that way i would have 250 filters on the root chain to a their class, and then 2 more filters in each class, having only 2 -J MARK entries in the mangle chain to mark pachets. The problem is i am doing SNAT and the EGRESS QDISC is applied after the SNAT so the tc filter based on src address do not work at all. Any idea how to solve that?

- -----Mensaje original-----
De: Stef Coene [mailto:stef.coene@xxxxxxxxx] 
Enviado el: miércoles, 23 de abril de 2003 22:29
Para: GoMi
CC: lartc@xxxxxxxxxxxxxxx
Asunto: Re: [LARTC] Lots amounts of classes to solve the DAP problem


On Wednesday 23 April 2003 14:45, GoMi wrote:
> I have finally worked a solution for egress traffic, but now i am a 
> bit troubled with ingress with IMQ due to SNAT Here is my script, i 
> have tried lots of combinations but with IMQ, the filters do not 
> filter to the classes at all. I am pretty sure its because of the SNAT 
> i am doing. Any one nows how to work around this problem?
So the filters for the eth2 device are working?
Mhh.  You put all packets leaving eth3 in the imq1 device?  Why not shaping on 
the eth3 device???

I have some other remarks.  You will get some warnings in your kernel log 
about quantum too low.  That's because you have 1kbit rate.  You can solve 
this by specifying a quantum if you add the htb class.  The minimum quantum 
is MTU bytes.
Also the pfifo.  I'm not sure how and if this will work.  It's possbile that 
the default size of the pfifo is too small.

I snipped your almost perfect script to save some bandwidth :)

> ip link set ${IDEV} up
> ip link set ${DEV} txqueue 30
I'm not sure if this is going to change anything.  As fas as I can remember, 
you replaced the default queue with something else so the inital depth of 
that queue doesn't mather anymore.

Stef

- -- 

stef.coene@xxxxxxxxx
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPqfwy37diNnrrZKsEQK8VgCeMeBT6yB4P7yRzXjPNxJOtelmLX8AnAmP
W2MMkuC/CU2KeqiK+dHx8MSG
=Hy+u
-----END PGP SIGNATURE-----


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux