headers
Andy Furniss | 1 Jun 2007 01:53

Re: IFB & 802.1q

Afshin Tajvidi wrote:

> So more precisely my question is which commands are to be used to
> redirect flows outgoing from eth0.10 and eth0.20 to ifb0 ? (I don't want
> to create separate QoS trees for eth0.10 and eth0.20 because the
> borrowing feature of HTB interests me).
> 
> I've used :
> 
> tc filter add dev eth0.10 parent root protocol ip priority 10 u32 match
> u32 0 0 flowid 1: action mirred egress redirect dev ifb0
> tc filter add dev eth0.20 parent root protocol ip priority 10 u32 match
> u32 0 0 flowid 1: action mirred egress redirect dev ifb0
> 
> But this do not work! (the ifb0 is always empty) Maybe I miss something
> or simply IFB does not allow to do global limitation as IMQ does.

You need a classfull qdisc on the egress interface to get the redirect 
to work. If you redirect from eth0.X then protocol ip should be OK.
Try -

tc qdisc add dev eth0.10 root handle 1:0 prio

tc filter add dev eth0.10 parent 1:0 protocol ip priority 10 u32 match 
u32 0 0 flowid 1: action mirred egress redirect dev ifb0

Andy.
Permalink | Reply | 0 comments |
headers
Luciano Ruete | 1 Jun 2007 04:43
Picon
Favicon

Re: big problem with HTB/CBQ and CPU for more than 1.700 customers

On Monday 28 May 2007 10:39:11 VladSun wrote:
> Alexandru Dragoi написа:
> > u32 hash filters is the key, as somebody pointed. You can also tune your
> > iptables setup, like this
> >
> > #192.168.1.0/24
> > iptables -t mangle -N 192-168-1-0-24
> > iptables -t mangle -A FORWARD -s 192.168.1.0/24 -j 192-168-1-0-24
> > iptables -t mangle -N 192-168-1-0-25
> > iptables -t mangle -N 192-168-1-128-25
> > iptables -t mangle -A 192-168-1-0-24 -s 192.168.1.0/25 -j 192-168-1-0-25
> > iptables -t mangle -A 192-168-1-0-24 -s 192.168.128.0/25 -j
> > 192-168-1-128-25 .
> > .
> > and so on, until (ip 192.168.1.11, which is called in chain created for
> > 192.168.1.10/31)
> >
> > iptables -t mangle -A 192-168-1-10-31 -s 192.168.1.10 -j CLASSIFY
> > --set-class 1:10
> > iptables -t mangle -A 192-168-1-10-31 -s 192.168.1.11 -j CLASSIFY
> > --set-class 1:11
> >
> > .. I guess you got the ideea, it requires some RAM, which i belive is
> > not such a big problem. Similar rules should be made for download.
>
> Or you can use my patch - IPCLASSIFY. Then the rules above would be
> substituted by a signle rule per direction:
>
>
> iptables -t mangle -A FORWARD -s 192.168.1.0/24 -j IPCLASSIFY --addr=src
(Continue reading)

Permalink | Reply | 3 comments |
headers
Luciano Ruete | 1 Jun 2007 06:46
Picon
Favicon

htb-gen 9.0beta (htb frontend with web-frontend for home/small/medium ISPs)

original at: http://www.praga.org.ar/wacko/DevPraga/htbgen

Htb-gen has evolved a lot since it release in feb/2006, but i have no 
time to make a public decent documented and generalized release.
But right now i think that is better to put the stuff here, so others can
enjoy the notorious improvements (and maybe someone whants to help out)

Lets go to the hacks:
I have made 2 flavors of htb-gen (actually these are two real setups each one 
with diferent needs)
config files where touched and some documentation udpate was made in place.

 * First flavor (htb-gen evolution)
 – htb-gen-9.0b.tar.gz Source tarball
 – Multiples ifaces support, you can have now mult. LAN and mult. ISPs.
 – Per host p2p percent of rate assignation
 – Named ISP/LAN and clients in the web-frontend
 – Code simplification
 – htb-init support removed (no one find this usefull)
 – pfifo_fast for prio class
 – Compatibility with bash v2
 – tc batch mode support, now both iptables and tc are batched,
 huge speed impact on large setups and yet tc and iptables
 command in the source are transparent readables

 * Second flavor (htb-gen advanced)
 – htb-gen-9.0b-advanced.tar.gz Source tarball
 – All features of htb-gen-9.0b 
 – Grained prio/non_prio per host definition, you can setup per client:
 – prio_tcp_ports
(Continue reading)

Permalink | Reply | 0 comments |
headers
Afshin Tajvidi | 1 Jun 2007 11:12
Picon
Favicon

Re: IFB & 802.1q

Thank you for you response Saioa
I've tried "protocol 802.1q" but this solution does not work...

Regards
Afshîn

On Thu, 2007-05-31 at 16:59 +0200, Saioa Arrizabalaga wrote:
> Hi,
> >
> > ip link set up dev ifb0
> >
> > tc qdisc add dev ifb0 root handle 1: htb default 3
> > tc class add dev ifb0 parent 1: classid 1:1 htb rate 2000kbit quantum
> > 1514
> > tc class add dev ifb0 parent 1:1 classid 1:2 htb rate 1000kbit ceil
> > 2000kbit quantum 1514
> > tc class add dev ifb0 parent 1:1 classid 1:3 htb rate 1000kbit ceil
> > 2000kbit quantum 1514
> >
> > tc filter add dev ifb0 parent 1: protocol ip priority 10 u32 match ip
> > sport 80 0xffff flowid 1:2
> 
> Try with "protocol 802.1q" instead of "protocol ip" in the filter:
> 
> tc filter add dev ifb0 parent 1: protocol 802.1q priority 10 u32 match
> ip sport 80 0xffff flowid 1:2
> 
> I had a similar problem and that worked for me. These posts may be useful:
> http://www.mail-archive.com/lartc <at> mailman.ds9a.nl/msg10132.html
> http://www.mail-archive.com/lartc <at> mailman.ds9a.nl/msg15219.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Afshin Tajvidi | 1 Jun 2007 11:32
Picon
Favicon

Re: LARTC] IFB & 802.1q

Thank you so much Marek and Andy
Your solutions work great!

Now my complete configuration is setup by the following commands:

ip link set up dev ifb0

tc qdisc add dev ifb0 root handle 1: htb default 3
tc class add dev ifb0 parent 1: classid 1:1 htb rate 2000kbit quantum
1514
tc class add dev ifb0 parent 1:1 classid 1:2 htb rate 1000kbit
ceil2000kbit quantum 1514
tc class add dev ifb0 parent 1:1 classid 1:3 htb rate 1000kbit ceil
2000kbit quantum 1514

tc filter add dev ifb0 parent 1: protocol ip priority 10 u32 match
ipsport 80 0xffff flowid 1:2

qdisc add dev eth0.10 root handle 1: htb
qdisc add dev eth0.20 root handle 1: htb

tc filter add dev eth0.10 parent 1: protocol ip priority 10 u32 match
u32 0 0 flowid 1: action mirred egress redirect dev ifb0
tc filter add dev eth0.20 parent 1: protocol ip priority 10 u32 match
u32 0 0 flowid 1: action mirred egress redirect dev ifb0

On Thu, 2007-05-31 at 16:41 +0200, Marek Kierdelewicz wrote:
> Hi,
> 
> >tc filter add dev eth0.10 parent root protocol ip priority 10 u32 match
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michal Soltys | 1 Jun 2007 13:24

tc offset & subheader matching clarification / question

Hello

TC's syntax, particulary u32 filter, is far more rich than what man, 
howto or command's help provides. I've been looking for information 
about the uses of 'offset' parameter, or more detailed explanation of a 
few other/relevan options, but what I've found is very brief to say the 
least.

So I checked the sources of cls_u32.c and f_u32.c. According to that, 
the separate 'offset' parameter controls the offset to the subheader 
(i.e. tcp from the beginning of ip), and it must be supplied 
explicitely. So for example, doing something like:

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
	match tcp dst 1234 0xffff flowid 1:5

or its equivalent

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
	match u32 0x00001234 0x0000ffff at nexthdr+0 flowid 1:5

is not enough. Looking at f_u32.c, the only thing that nexthdr+ will 
cause, is setting offset mask (key->offmask), used in the following line 
of net/sched/cls_u32.c:

if ((*(u32*)(ptr+key->off+(off2&key->offmask))^key->val)&key->mask) {

If I understand it correctly, then i.e. lartc howto's 12.1.1 examples 
wouldn't work as intended. off2 would have to be set by the means of 
'offset' option on the command line.
(Continue reading)

Permalink | Reply | 2 comments |
headers
VladSun | 1 Jun 2007 14:00

Re: big problem with HTB/CBQ and CPU for more than 1.700 customers

Luciano Ruete написа:
>> Or you can use my patch - IPCLASSIFY. Then the rules above would be
>> substituted by a signle rule per direction:
>>
>>
>> iptables -t mangle -A FORWARD -s 192.168.1.0/24 -j IPCLASSIFY --addr=src
>> --and-mask=0xff --or-mask=0x11000
>> iptables -t mangle -A FORWARD -d 192.168.1.0/24 -j IPCLASSIFY --addr=dst
>> --and-mask=0xff --or-mask=0x12000
>>     
>
> Wow! now i get it, this patch is amazing, now i have a pendient hack that is 
> to merge this with htb-gen. Any chances that this get into mainline, have you 
> mailed netfilter-dev list?
>
>   

:)

Thank you! You should thank Grzegorz Janoszka also - he wrote the 
original IPMARK patch. My patch is just a slight modification of it.

As far as I know netfilter team refused to include the IPMARK in the 
official P-o-M. So I don't think IPCLASSIFY would be accepted either.

Regards, Vladimir Mirchev.
Permalink | Reply | 0 comments |
headers
Russell Stuart | 2 Jun 2007 01:21
Picon

Re: tc offset & subheader matching clarification / question

On Fri, 2007-06-01 at 13:24 +0200, Michal Soltys wrote:
> TC's syntax, particulary u32 filter, is far more rich than what man, 
> howto or command's help provides. I've been looking for information 
> about the uses of 'offset' parameter, or more detailed explanation of a 
> few other/relevan options, but what I've found is very brief to say the 
> least.

Look here: http://www.stuart.id.au/russell/files/tc/doc/tc/cls_u32.txt
Permalink | Reply | 1 comment |
headers
Luciano Ruete | 2 Jun 2007 05:27
Picon
Favicon

Re: Multihome load balancing - kernel vs netfilter

On Thursday 31 May 2007 02:02:16 Salim S I wrote:
> Before we get into the "Top-posting" stuff, it would be nice if you
> follow the normal way of replying (or atleast marking a copy) to the
> list. I think that is the basic idea behind mailing list.

Shure! :-), my fault, not looking at headers, my wish was always to write to 
the list.

> If you had done that, I wouldn't have had to do the "Top-Posting". Take
> a look at the archives please.

There is no reason to do Top-Posting, if i've missed the cc to the list, you 
still can do a normal innline reply. But all this is getting OT in this list.

> On Wednesday 30 May 2007 00:58:18 you wrote:
[snip]
> Yessir. 3 bags full.
> If you had read my post c l e a r l y, before you felt obliged to show
> off your knowledge, you might have understood that I was talking about
> the so-called 'special-protocols'.

You mention online gaming and IM protocols, and there is nothing special about 
that. What im triyng to say is that CONNTRACK+CONNMARK solves that problem 
for you. You can have IM(msn,jabber,yahoo,aol) connected all day long without 
problems, or you can do online gamming too, or have an ssh session for weeks. 
CONNTRACK has the avility to track tcp(ammong others) flows and to remember 
an ESTABLISHED connection. Then you can use CONNMARK to MARK an ESTABLISHED 
connection with an unique tag based on the provider that it use. 
Then, every time you see the same MARK on that ESTABLISHED connection you 
assure that it will be routed over the same original provider.
(Continue reading)

Permalink | Reply | 3 comments |
headers
terraja-based | 2 Jun 2007 11:19
Picon

u32 classifier

Hi folks...!!!
 
 
I´ve a problem that i did not solve it.
i want to limit the DOWNLOAD to my hosts (upstream traffic for the firewall) using IMQ, 
 
If i classify by PORT (source or destination) all seems to be fine, but...BUT...if i want to restrict by IP addresss (internal IP address) i can´t do it, because my hosts go to Internet toward the firewall using NAT, so after NAT my IP address in Internet is not my internal address, because the NAT acction change my source and internal IP address.
 
So...so...so...how can i limit the traffic by IP address using TC, IMQ, U32..etc...?????
 
Can i modify some field in the TCP header with u32 filter?, i did read the TCP RFC and nothing, i can´t guess how can solve it...
Please, HELPPPPPPP ME...!!!


--
terraja-based 
_______________________________________________
LARTC mailing list
LARTC <at> mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Permalink | Reply | 5 comments |

Gmane