Re: [LARTC] CBQ + Layer7 x Emule
from ipp2p news page
quote
I suggest the following tcp and udp for connection tracking (see docu section)
01# iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark
02# iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT
03# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK
--set-mark 1
04# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j
CONNMARK --save-mark
05# iptables -t mangle -A PREROUTING -p udp -m ipp2p --ipp2p -j MARK
--set-mark 1
detect TCP FIRST, SAVE MARK , and detect udp after you saved the mark !!
You will have now every p2p packet marked, but a dramtic reduce of udp
missmatches.
quote
On 6/8/07, Salatiel Filho [EMAIL PROTECTED] wrote:
On 6/8/07, Saulo Silva [EMAIL PROTECTED] wrote:
HI Marcos ,
I tried your rules, but without success . Thank for that help .
And , how about ip2pp ? Is this application could do that ? Help me to
shape edonkey traffic ???
Best Regards,
Saulo Silva
2007/6/8, Marco Aurelio [EMAIL PROTECTED]:
l7's edonkey filter does not match all edonkey traffic, it does not
match data packets (that you want to shape). It matches however the
signaling packets that can be related to data connections.
I never tried L7 but I think these may help you
iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -mlayer7 --l7proto edonkey -j MARK
--set-mark 2
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 2 -j CONNMARK
--save-mark
On 6/8/07, Saulo Silva [EMAIL PROTECTED] wrote:
Hi All ,
My first message and I have a little problem with my FC6 box trying to
block
emule traffic using layer7 .
Here my network :
Internet - ADSL Router --- FC6 Box
Emule Box
external ADSL : Dynamic
Internal ADSL : 192.168.254.1
external FC6 : 192.168.254.3
internal FC6 : 192.168.253.1
Emule Box : 192.168.253.3
I guess that everything is ok with layer7 . Here my mangle rules .
# iptables -t mangle -A PREROUTING -mlayer7 --l7proto edonkey -j MARK
--set-mark 2
# iptables -t mangle -A PREROUTING -m mark --mark 2 -j LOG
--log-prefix
PREROUTING MARK :
iptables -t mangle -A FORWARD -mlayer7 --l7proto edonkey -j MARK
--set-mark
2
iptables -t mangle -A FORWARD -m mark --mark 2 -j LOG --log-prefix
FORWARD
MARK :
The output from log is :
Jun 8 14:18:46 fs-linux kernel: FORWARD MARK : IN=eth0 OUT=eth1
SRC= 203.91.83.127 DST=192.168.253.3 LEN=180 TOS=0x00 PREC=0x00
TTL=105
ID=18725 PROTO=TCP SPT=51674 DPT=4662 WINDOW=16944 RES=0x00 ACK PSH
URGP=0
Jun 8 14:18:48 fs-linux kernel: PREROUTING MARK : IN=eth0 OUT=
MAC=00:06:4f:47:ad:e0:00:0f:3d:cc:29:e0:08:00
SRC=200.209.170.138 DST= 192.168.254.3 LEN=139 TOS=0x00 PREC=0x00
TTL=115
ID=18002 DF PROTO=TCP SPT=1476 DPT=4662 WINDOW=65535 RES=0x00 ACK PSH
URGP=0
Jun 8 14:18:48 fs-linux kernel: FORWARD MARK : IN=eth0 OUT=eth1 SRC=
200.209.170.138 DST= 192.168.253.3 LEN=139 TOS=0x00 PREC=0x00 TTL=114
ID=18002 DF PROTO=TCP SPT=1476 DPT=4662 WINDOW=65535 RES=0x00 ACK PSH
URGP=0
Jun 8 14:18:51 fs-linux kernel: PREROUTING MARK : IN=eth0 OUT=
MAC=00:06:4f:47:ad:e0:00:0f:3d:cc:29:e0:08:00 SRC=
200.244.104.10 DST= 192.168.254.3 LEN=40 TOS=0x00 PREC=0x00 TTL=117
ID=7042
PROTO=TCP SPT=50675 DPT=4662 WINDOW=64952 RES=0x00 ACK FIN URGP=0
Jun 8 14:18:51 fs-linux kernel: FORWARD MARK : IN=eth0 OUT=eth1 SRC=
200.244.104.10 DST= 192.168.253.3 LEN=40 TOS=0x00 PREC=0x00 TTL=116
ID=7042
PROTO=TCP SPT=50675 DPT=4662 WINDOW=64952 RES=0x00 ACK FIN URGP=0
So it's look like mark is working .
So now I use the cbq.init script with that configuration :
cat /etc/sysconfig/cbq/cbq- 0002.emule_in
DEVICE=eth0,100Mbit,10Mbit
RATE=3Kbit
WEIGHT=1Kbit
PRIO=5
BOUNDED=yes
ISOLATED=yes
MARK=2
cat /etc/sysconfig/cbq/cbq-0002.emule_out
DEVICE=eth1,100Mbit,10Mbit
RATE=3Kbit
WEIGHT=1Kbit
PRIO=5
BOUNDED=yes
ISOLATED=yes
MARK=2
that generate this tc codes .
/sbin/tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt
3000
cell 8
/sbin/tc class change dev eth0 root cbq weight 10Mbit allot 1514
/sbin/tc qdisc del dev eth1 root
/sbin/tc qdisc add dev eth1 root handle 1 cbq bandwidth 100Mbit avpkt
3000
cell 8
/sbin/tc class change dev eth1 root cbq weight 10Mbit allot 1514
/sbin/tc class add dev eth0 parent 1: classid 1:2 cbq bandwidth
100Mbit rate
3Kbit weight 1Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 3000
bounded
isolated
/sbin/tc qdisc add dev eth0 parent 1:2 handle 2 tbf rate 3Kbit buffer
10Kb/8
limit 15Kb mtu 1500
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 200 handle 2
fw
classid 1:2
/sbin/tc class add dev eth1 parent 1: classid 1:2
Re: [LARTC] how hierarchical is HTB?
What exactly happens if the sum of the children classes rate is bigger than the parent's? What if the majority of these classes are using less than the minimum rate established (eg. 0kbps)? On 6/6/07, Flechsenhaar, Jon J [EMAIL PROTECTED] wrote: Few quick comments: HTB parent rate should never be less than the sum of its children. This is referring to the rate parameter not the ceil. Class 1:20 needs to equal 1:200+1:201. You will get strange results if you try and test with any configuration where the the sum of all childeren rates are greater than their parent. Borrowing occurs from the parent and from classes at the same level. So if you have 3 leaf classes. 1:1, 1:2, and 1:3 they will get their assigned rate and borrow up their ceil if there is extra bandwidth. If there is no traffic in one of the classes then it can give its assured bandwidth to the other 2 classes with traffic. Borrowing is based on the priority assigned to the class. Jon Flechsenhaar Boeing WNW Team Network Services (714)-762-1231 202-E7 -Original Message- From: Claudio Greco [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 06, 2007 7:58 AM To: Ethy H. Brito Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] how hierarchical is HTB? root class 1: (rate=100, ceil=100) 1: children classes 1:10 (30,100) and 1:20 (70,100) 1:10 children classes 1:100 (10,100) and 1:101 (20,100) 1:20 children classes 1:200 (30,100) and 1:201 (70,100) I managed to have the root rate equals to the sum of its children. Well, it is still true that total assured rate for classes 1:200 and 1:201 is greater than assured rate for class 1:20. Still, I don't think this is a big deal. But how must the rates of the leaves be signed? What do you mean with 'signed'? And how the bandwidth of these leaves will be distributed when borrowing/lending is necessary? As far as I know, when a leaf is 'yellow', i.e. its rate is greater than its assured rate and lesser than its ceil rate, it can borrow from its parent providing there's a yellow-path to the root and the root is green (root can't be yellow, only green or red). If there's more than one child borrowing from the same class, they're served according to their priority (argument prio in *tc class add*). If there's more than one child having the same priority, then they're served in DRR order (Deficit Round Robin). You can tune DRR behaviour with arguments r2q in *tc qdisc add* and quantum in *tc class add*. classs 1:10 will/may lend/borrow from class 1:20. I know that. No it can not. A class can only borrow from its parent, never from its siblings. But how about 1:1XX and classes 1:2XX? will the borrow/lend from each others? ibidem. Any docs about this? You may see: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Marco Casaroli SapucaiNet Telecom +55 35 34712377 ext 5 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] vlan interfaces and tc
Hello I have few questions regarding tc functionality (qdiscs, classes, etc.) when vlans are in use. For example, consider interface eth0, for which I create and extra vlan with vconfig, let's say eth0.11. Then using tc I can add usual things - qdiscs, filters, ... - to both eth0 and eth0.11. The questions are: - on which interface - virtual or real, should I actually use tc ? Or are either of them allowed, depending on what I need ? If so: - what happens if both interfaces - virtual and real have disciplines / filters ? Does packet traverse both (I'd assume, first through eth0.11 than through eth0) ? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
