Re: [LARTC] HTB & BDW Guarantee

2004-07-09 Thread Rio Martin
On Saturday 10 July 2004 05:54, toto toto wrote:
> Hello,
> I have problems setting up HTB.
> This is my setup :
> NET
> 1024/256 ADSL
> eth1
> Linux Firewall
> eth0
> LAN 10.a.a.a
> I want to GUARANTEE for an IP (10.x.y.z) a 800kbit
> bandwidth for HTTP download.
> But When 10.x.y.z does no HTTP download, other trafic
> must get the whole bandwidth, of course.
> The script I use (see below) is quite the same as
> presented at (the grat page) :
> http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm,
> the only difference is that I use only 2 classes (HTTP
> trafic vs other)
> BUT :-((
> When I
> [EMAIL PROTECTED] wget ftp.fr.debian.org/debian/ls-lR
> (...)
> 21% [==>] 4,984,704106.39K/s
> [EMAIL PROTECTED]
> It goes at ~100 Ko, as expected when no other trafic
> is generated.
> But if I
> [EMAIL PROTECTED] wget ftp://ftp.fr.debian.org/debian/ls-lR

I completely disagree with the way you performed the test.
Debian.Org is not on your local network isnt it ?? How far from your host 
until it reach Debian.Org as destination host ? Are you sure your ISP or 
Debian.Org ISP or perhaps Debian.Org itself doesnt perform traffic per 
session management, or any QoS ?
My suggestion is to test the performance of your HTB using your own local 
network. Because you know completely your network condition and you can 
analyze it perfectly.

Regards,
Rio Martin.
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] HTB & Bdw Guarantee

2004-07-09 Thread Ow Mun Heng
Referencing:
http://mailman.ds9a.nl/pipermail/lartc/2004q3/013076.html
(the bullet'ed items are what he wrote)

  * NET 
  * 1024/256 ADSL 
  * ||eth1
  * Linux Firewall 
  * eth0 
  * ||LAN 10.a.a.a
  * 
  * I want to GUARANTEE for an IP (10.x.y.z) a 800kbit
  * bandwidth for HTTP download.
  * But When 10.x.y.z does no HTTP download, other trafic
  * must get the whole bandwidth, of course.


OK.
  * BUT :-(( 
  * When I 
  * [EMAIL PROTECTED] wget ftp.fr.debian.org/debian/ls-lR
  * (...)
  * 21% [==>] 4,984,704106.39K/s
  * [EMAIL PROTECTED]
  * 
  * It goes at ~100 Ko, as expected when no other trafic
  * is generated.
  * But if I 
  * [EMAIL PROTECTED] wget ftp://ftp.fr.debian.org/debian/ls-lR
  * 
  * after the beginning of the HTTP download, the latter
  * goes dooown, and if I run a second wget ftp://...,
  * the HTTP download goes UNDER (really under) the 800
  * kbits...??!!
  * It seems like there's no difference whether the
  * shaping is done or not.

Dude.. If you want to shape HTTP traffic, why the heck are you going for
ftp download??

If you look at your connections (eg: tcptrack -i eth0, you'll see you're
initiating port 20/21 and not port 80 as you wanted.)

  * Is this only because one can't shape incoming trafic ?

Yes. That is true. but in your case, since you're pushing out to eth0
(from eth1) you theoretically is allready introducing outgoing traffic
(from eth1 to eth0)

So you can shape on that.

  * Could Ingress solve my pb ? I don't think so, as
  * Ingress seems to limit the WHOLE bandwidth...

You can use an ingress filter and then use a filter against the FWmarks
or in your case sport . (Though I've never did that successfully. I
prefer fwmarks)

  * Is it a "prio" question ?
Not sure.

Check this out. See if it helps you.
http://www.redhat.com/archives/fedora-list/2004-July/msg01764.html
http://my-opensource.org/howto/qostrafficshaping-shorewall-wondershaper-howto.html

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 16:55:59 up 8:02, 5 users, load average: 1.38, 1.00, 1.02 
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] Re: layer 7 netfilter not working

2004-07-09 Thread FB
I wouldn't bet the layer7 match works in table filter. You could try
$IPTABLES -t mangle -A POSTROUTING -m layer7 --l7dir /etc/l7-protocols
--l7proto ftp -j LOG --log-prefix 'marked: '
and watch your logs. Um, and /etc/l7-protocols does contain your pattern
definitions, right?
Yes there are my definition. And your idea with the logging was great, I 
did it and guess what, the packets showed up in /var/log/syslog, so I 
guess the layer7 classifier is working, but now I wonder why it still 
doesn't shape (and remember DROP didn't work either, but there I am not 
sure if it wasn't a configure mistake by me).

I changed the line back to:
$IPTABLES -t mangle -A POSTROUTING -m layer7 --l7dir /etc/l7-protocols 
--l7proto ftp -j MARK --set-mark 322

But the shaping still doesn't work. I didn't want to terrorize you all 
by posting my whole shapingskript here, so I uploaded it here:

http://www.flintz.de/shaping.txt
Would be really nice if someone could search the script for any mistakes!
-FB
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] HTB & BDW Guarantee

2004-07-09 Thread toto toto
Hello,

I have problems setting up HTB.
This is my setup :

NET 
1024/256 ADSL 
||
eth1
Linux Firewall 
eth0 
||
LAN 10.a.a.a

I want to GUARANTEE for an IP (10.x.y.z) a 800kbit
bandwidth for HTTP download.
But When 10.x.y.z does no HTTP download, other trafic
must get the whole bandwidth, of course.

The script I use (see below) is quite the same as
presented at (the grat page) :
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm,
the only difference is that I use only 2 classes (HTTP
trafic vs other)

BUT :-(( 
When I 
[EMAIL PROTECTED] wget ftp.fr.debian.org/debian/ls-lR
(...)
21% [==>] 4,984,704106.39K/s
[EMAIL PROTECTED]

It goes at ~100 Ko, as expected when no other trafic
is generated.
But if I 
[EMAIL PROTECTED] wget ftp://ftp.fr.debian.org/debian/ls-lR

after the beginning of the HTTP download, the latter
goes dooown, and if I run a second wget ftp://...,
the HTTP download goes UNDER (really under) the 800
kbits...??!!
It seems like there's no difference whether the
shaping is done or not.

Trafic seems to be classified (tc -s -d class show dev
eth0 / eth1), but...

Actually my goal is more complicated than HTTP
downloads (I need to guarantee bandwidth for
H323 -> Netmeeting & co, so both down&up-loads), but
I'm just testing for now, and if I can't shape such a
simple trafic as HTTP download...

Could anyone tell me what I did wrong, or didn't
understand...
Is this only because one can't shape incoming trafic ?

Could Ingress solve my pb ? I don't think so, as
Ingress seems to limit the WHOLE bandwidth...
Is it a "prio" question ?

Thanks for your help

PSes : 
- has anyone experienced H323 trafic shaping ?? if so,
scripts are welcome !!!
- If CBQ can do better, then I'll turn to CBQ, but
it's just like chinese for me...
HTB is more simple



Here's the script :
#!/bin/bash

OUT=eth1
IN=eth0

IP=10.x.y.z 

BDW_IN=1024kbit
BDW_OUT=256kbit

BDW_WEB_IN=800kbit
BDW_OTHER_IN=224kbit
BDW_WEB_OUT=176kbit
BDW_OTHER_OUT=80kbit

#---#

function start_out () {

tc qdisc add dev $OUT root handle 1: htb default 11

tc class add dev $OUT parent 1: classid 1:1 htb rate
$BDW_OUT ceil $BDW_OUT
tc class add dev $OUT parent 1:1 classid 1:10 htb rate
$BDW_WEB_OUT ceil $BDW_OUT
tc class add dev $OUT parent 1:1 classid 1:11 htb rate
$BDW_OTHER_OUT ceil $BDW_OUT

tc qdisc add dev $OUT parent 1:10 handle 20: pfifo
limit 5
tc qdisc add dev $OUT parent 1:11 handle 40: sfq
perturb 10

tc filter add dev $OUT protocol ip parent 1:0 prio 1
u32 \
match ip src $IP match ip dport 80 0x
flowid 1:10
}

function start_in () {

tc qdisc add dev $IN root handle 1: htb default 11

tc class add dev $IN parent 1: classid 1:1 htb rate
$BDW_IN ceil $BDW_IN
tc class add dev $IN parent 1:1 classid 1:10 htb rate
$BDW_WEB_IN ceil $BDW_IN
tc class add dev $IN parent 1:1 classid 1:11 htb rate
$BDW_OTHER_IN ceil $BDW_IN

tc qdisc add dev $IN parent 1:10 handle 20: pfifo
limit 5
tc qdisc add dev $IN parent 1:11 handle 40: sfq
perturb 10

tc filter add dev $IN protocol ip parent 1:0 prio 1
u32 \
match ip dst $IP match ip sport 80 0x
flowid 1:10
}

#---#

function stop_out () {

tc filter del dev $OUT protocol ip parent 1:0 prio 1
u32

tc class del dev $OUT parent 1:1 classid 1:11
tc class del dev $OUT parent 1:1 classid 1:10

tc class del dev $OUT parent 1: classid 1:1
tc qdisc del dev $OUT root handle 1: htb
}

function stop_in() {

tc filter del dev $IN protocol ip parent 1:0 prio 1
u32

tc class del dev $IN parent 1:1 classid 1:11
tc class del dev $IN parent 1:1 classid 1:10

tc class del dev $IN parent 1: classid 1:1
tc qdisc del dev $IN root handle 1: htb
}

case $1 in
start)
echo
start_out
start_in
echo
;;
stop)
echo
stop_out
stop_in
echo
;;
*)
echo "Usage : $0 {start|stop|restart}"
;;
esac








Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! 
Messenger sur http://fr.messenger.yahoo.com
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] HTB & Bdw Guarantee

2004-07-09 Thread toto toto
Hello,

I have problems setting up HTB.
This is my setup :

NET 1024/256 ADSL 
||
eth1
Linux Firewall 
eth0 
||
LAN 10.a.a.a

I want to GUARANTEE for an IP (10.x.y.z) a 800kbit
bandwidth for HTTP download.
But When 10.x.y.z does no HTTP download, other trafic
must get the whole bandwidth, of course.

The script I use (see below) is quite the same as
presented at (the grat page) :
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm,
the only difference is that I use only 2 classes (HTTP
trafic vs other)

BUT ( :-(( )
When I 
[EMAIL PROTECTED] wget ftp.fr.debian.org/debian/ls-lR
(...)
21% [==>  ] 4,984,704106.39K/s   
[EMAIL PROTECTED]

It goes at ~110 Ko, as expected when no other trafic
is generated.
But if I 
[EMAIL PROTECTED] wget ftp://ftp.fr.debian.org/debian/ls-lR

after the beginning of the HTTP download, the latter
goes dooown, and if I run a second wget ftp://...,
the HTTP download goes UNDER (really under) the 800
kbits...??!!
It seems like there's no difference whether the
shaping is done or not.

Trafic seems to be classified (tc -s -d class show dev
eth0 / eth1), but...

Actually my goal is more complicated than HTTP
downloads (I need to guarantee bandwidth for
H323 -> Netmeeting & co, so both down&up-loads), but
I'm just testing for now, and if I can't shape such a
simple trafic as HTTP download...

Could anyone tell me what I did wrong, or didn't
understand...
Is this only because one can't shape incoming trafic ?

Could Ingress solve my pb ? I don't think so, as
Ingress seems to limit the WHOLE bandwidth...
Is it a "prio" question ?

Thanks for your help

PSes : 
- has anyone experienced H323 trafic shaping ?? if so,
scripts are welcome !!!
- If CBQ can do better, then I'll turn to CBQ, but
it's just like chinese for me...
HTB is more simple



Here's the script :
#!/bin/bash

OUT=eth1
IN=eth0

IP=10.x.y.z 

BDW_IN=1024kbit
BDW_OUT=256kbit

BDW_WEB_IN=800kbit
BDW_OTHER_IN=224kbit
BDW_WEB_OUT=176kbit
BDW_OTHER_OUT=80kbit

#---#

function start_out () {

tc qdisc add dev $OUT root handle 1: htb default 11

tc class add dev $OUT parent 1: classid 1:1 htb rate
$BDW_OUT ceil $BDW_OUT
tc class add dev $OUT parent 1:1 classid 1:10 htb rate
$BDW_WEB_OUT ceil $BDW_OUT
tc class add dev $OUT parent 1:1 classid 1:11 htb rate
$BDW_OTHER_OUT ceil $BDW_OUT

tc qdisc add dev $OUT parent 1:10 handle 20: pfifo
limit 5
tc qdisc add dev $OUT parent 1:11 handle 40: sfq
perturb 10

tc filter add dev $OUT protocol ip parent 1:0 prio 1
u32 \
match ip src $IP match ip dport 80 0x
flowid 1:10
}

function start_in () {

tc qdisc add dev $IN root handle 1: htb default 11

tc class add dev $IN parent 1: classid 1:1 htb rate
$BDW_IN ceil $BDW_IN
tc class add dev $IN parent 1:1 classid 1:10 htb rate
$BDW_WEB_IN ceil $BDW_IN
tc class add dev $IN parent 1:1 classid 1:11 htb rate
$BDW_OTHER_IN ceil $BDW_IN

tc qdisc add dev $IN parent 1:10 handle 20: pfifo
limit 5
tc qdisc add dev $IN parent 1:11 handle 40: sfq
perturb 10

tc filter add dev $IN protocol ip parent 1:0 prio 1
u32 \
match ip dst $IP match ip sport 80 0x
flowid 1:10
}

#---#

function stop_out () {

tc filter del dev $OUT protocol ip parent 1:0 prio 1
u32

tc class del dev $OUT parent 1:1 classid 1:11
tc class del dev $OUT parent 1:1 classid 1:10

tc class del dev $OUT parent 1: classid 1:1
tc qdisc del dev $OUT root handle 1: htb
}

function stop_in() {

tc filter del dev $IN protocol ip parent 1:0 prio 1
u32

tc class del dev $IN parent 1:1 classid 1:11
tc class del dev $IN parent 1:1 classid 1:10

tc class del dev $IN parent 1: classid 1:1
tc qdisc del dev $IN root handle 1: htb
}

case $1 in
start)
echo
start_out
start_in
echo
;;
stop)
echo
stop_out
stop_in
echo
;;
*)
echo "Usage : $0 {start|stop|restart}"
;;
esac








Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! 
Messenger sur http://fr.messenger.yahoo.com
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Layer 7 netfilter not working

2004-07-09 Thread FB
`man iptables`
"REJECT
This is used to send back an error packet in response to the matched packet:  
otherwise it is equivalent to DROP so it is a terminating TARGET, ending rule 
traversal.  This target is only valid in the INPUT, FORWARD and OUTPUT 
chains, and userdefined chains which are only called from those chains.  The 
following option controls the nature of the error packet returned:"
I kinda expectet that, but I just did whats on the Netfilter HOWTO 
page...there ist says:
"Blocking packets when they are identified is easy. Simply use "-j DROP" 
(or REJECT) at the ends of the lines in the above section."

But this is still not my problem, the problem is that the Layer7 
classifier don't recognize the packets!

(Thanks anyway)
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Layer 7 netfilter not working

2004-07-09 Thread Jason Boxman
On Friday 09 July 2004 16:51, Ed Wildgoose wrote:

> Can you REJECT in the mangle table?
>

It seems not.

rebecca:~# iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j 
REJECT
iptables: Invalid argument
rebecca:~# iptables -A INPUT -m layer7 --l7proto http -j REJECT
rebecca:~# iptables -D INPUT -m layer7 --l7proto http -j REJECT

`man iptables`
"REJECT
This is used to send back an error packet in response to the matched packet:  
otherwise it is equivalent to DROP so it is a terminating TARGET, ending rule 
traversal.  This target is only valid in the INPUT, FORWARD and OUTPUT 
chains, and userdefined chains which are only called from those chains.  The 
following option controls the nature of the error packet returned:"

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] Re: Problem with HTB queuing discipline

2004-07-09 Thread Ow Mun Heng
This will surely break threads. (i don't know why but I'm not receiving
any mails from lartc. My post got submitted but I'm not getting any
posts back) I wonder if it's cause of my email server blocking it.

Anyway, 

Aravind,

The problem which I see here is that what you're trying to perform is
limit download(or inbound) traffic. This is unfortunately, not feasible.
The HTB/QoS stuffs is usually only controllable upstream.

However, there _are_ workarounds for it. One such solution is to put in
additional network cards such that "in a way" you create an upstream
traffic.

Refer to this thread in which I've posted a solution for a
multi-interface
http://www.redhat.com/archives/fedora-list/2004-July/msg01764.html

And BTW, I'm not sure about others, but I've never gotten much luck
trying to perform u32 classifications. I got better luck using fwmarks.


Referencing:
http://mailman.ds9a.nl/pipermail/lartc/2004q3/013064.html
Hi ,
 

I have the problem with HTB queuing discipline.I am giving my setup below.
 

  172.30.179.206   172.30.180.55
 
  LAN |  |   WAN
-| LINUX WITH|--
172.30.179.140   | HTB   |  172.30.180.72
FTP SERVER   FTP CLIENT
 
On the LAN side i put FTP server(172.30.179.140) and on WAN side i put FTP 
client(172.30.180.72).
 
FTP client and FTP server will communicate through the middle linux box.
 
Middle linux box has two interfaces.eth0 is 172.30.179.206 and 
eth1 is 172.30.180.55
 
In the middle linux box i configured HTB using following commands.
 
./tc qdisc add dev eth0 root handle 1:0 htb
 
./tc class add dev eth0 parent 1:0 classid 1:1  htb rate 30kbps  ceil 30kbps 
 
./tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps  ceil 30kbps
 
./tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.30.180.72 
match ip sport 21 0x flowid 1:10

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.30.180.72 
match ip sport 20 0x flowid 1:10
 

When i downloaded one file of size 10.7MB from FTP server(i.e from 
172.30.179.140) to client(i.e. 172.30.180.72) , download speed is coming as 
362.19kbytes/sec instead of 30kbps which i ceil.What may be the problem? Any 
configuration issue?Any idea?
 

Thanks in advance,
Aravind.
-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 (Tettnang) on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 13:46:30 up 4:53, 4 users, load average: 1.64, 1.64, 1.50 
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Layer 7 netfilter not working

2004-07-09 Thread Ed Wildgoose
Jason Boxman wrote:
On Friday 09 July 2004 14:58, FB wrote:

 

Doesn't change anything :-(
BTW, when I use the setting from the NETFILTER HOWTO page:
iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK
--set-mark 1
and change it (as written in the howto under "blocking") to:
iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j REJECT
I get an "iptables: Invalid Argument" when executing the script, how
that? (I must admit that I am not that iptable expert, so excuse some
lack of knowledge of all the chains and structures ;) )
   

More of a question for the netfilter list, but it sounds like you may not have 
compiled in support for the REJECT target.  You should have ipt_REJECT in the 
output when you do an `lsmod` if you compiled it as a module.
 

Can you REJECT in the mangle table?
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Layer 7 netfilter not working

2004-07-09 Thread Jason Boxman
On Friday 09 July 2004 14:58, FB wrote:

> Doesn't change anything :-(
> BTW, when I use the setting from the NETFILTER HOWTO page:
>
> iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK
> --set-mark 1
>
> and change it (as written in the howto under "blocking") to:
> iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j REJECT
>
> I get an "iptables: Invalid Argument" when executing the script, how
> that? (I must admit that I am not that iptable expert, so excuse some
> lack of knowledge of all the chains and structures ;) )

More of a question for the netfilter list, but it sounds like you may not have 
compiled in support for the REJECT target.  You should have ipt_REJECT in the 
output when you do an `lsmod` if you compiled it as a module.

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Layer 7 netfilter not working

2004-07-09 Thread FB
Jason Boxman wrote:
That's not necessary.  You might be creating more work for yourself.  I just 
recycled the Debian iptables package, which is still 1.2.9 I believe.  You'll 
need to patch it and create the appropriate dot file for the build to 
succeed, but after that I just rebuild the package with 'debuild -uc -us' and 
copied it to my compiler-less router.  I'm using 2.6.6, but I'm sure 2.6.7 
should work fine.
Ok, it may not be necessary, but shouldn't be the source of the problem, or?
Should work with iptables 1.2.11 all the same or are there some issues 
there?


I believe the documentation mentions that layer7 works best when it can see 
both 'sides' of the connection.  If you're filtering through INPUT or OUTPUT 
you're missing half.  Check the ftp protocol match.  Does it rely on seeing 
both sides of the connection to match up?

Try matching in FORWARD, PREROUTING, or POSTROUTING.  I believe these see all 
sides of the connection.
Doesn't change anything :-(
BTW, when I use the setting from the NETFILTER HOWTO page:
iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j MARK 
--set-mark 1

and change it (as written in the howto under "blocking") to:
iptables -t mangle -A POSTROUTING -m layer7 --l7proto http -j REJECT
I get an "iptables: Invalid Argument" when executing the script, how 
that? (I must admit that I am not that iptable expert, so excuse some 
lack of knowledge of all the chains and structures ;) )

-FB
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] RED/GRED implementation for InBound Traffic Control (from ISP)

2004-07-09 Thread Ow Mun Heng
Hi all,

Can anyone show me pointers on how to get this implemented on a Linux
box with tc rules?

I also want to know, just how efficient is this Algorithm. AFAIK,
inbound traffic control can't really be achieved without losing
bandwidth.
In some of the howtos' I've read, one guy had to limit his downspeed to
1/2 his bandwidth to actually control it. And he was saying that the
only way to actually efficiently control inbound traffic control is to
use TCP windowshaping which there is not an oss implementation of it.

Can anyone please shed light on this?

FWIW, this discussion was in 
http://my-opensource.org/lists/myoss/2004-07/msg00051.html
http://my-opensource.org/lists/myoss/2004-06/msg00167.html
http://www.redhat.com/archives/fedora-list/2004-July/msg01492.html

Thanks

-- 
Ow Mun Heng
Fedora GNU/Linux Core 2 (Tettnang) on D600 1.4Ghz CPU kernel
2.6.7-2.jul1-interactive 
Neuromancer 12:06:38 up 3:13, 3 users, load average: 1.80, 1.23, 1.41 
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] Layer 7 netfilter not working

2004-07-09 Thread Jason Boxman
On Friday 09 July 2004 13:10, FB wrote:
> Hello there!
>
> I am trying to get traffic shaping working on my Linux router (debian
> woody 3r02) and for some things I wanted to use the layer 7 packet
> classifier, but I can't get it to work.
> Here is what I did:
>
> -downloaded the patches from http://l7-filter.sourceforge.net
> -downloaded the kernel 2.6.7 source
> -downloaded the iptables 1.2.11 source

That's not necessary.  You might be creating more work for yourself.  I just 
recycled the Debian iptables package, which is still 1.2.9 I believe.  You'll 
need to patch it and create the appropriate dot file for the build to 
succeed, but after that I just rebuild the package with 'debuild -uc -us' and 
copied it to my compiler-less router.  I'm using 2.6.6, but I'm sure 2.6.7 
should work fine.

> -patched kernel (layer7 patch and some patch to get iptables 1.2.11
> working with kernel 2.6.7)
> -patched iptables
> -compiled iptables
> -activated layer 7 support in kernel-config (and a lot of other packet
> classifing options)
> -compiled and installed kernel
>
> Now I tried to mark some packets with layer 7 so that I can shape them
> with tc afterwards. But nothing changed, outgoing connection still
> didn't changed. So I changed the line in the iptables-script to this:
>
>   $IPTABLES -t filter -A OUTPUT -m layer7 --l7dir /etc/l7-protocols
> --l7proto ftp -j DROP

I believe the documentation mentions that layer7 works best when it can see 
both 'sides' of the connection.  If you're filtering through INPUT or OUTPUT 
you're missing half.  Check the ftp protocol match.  Does it rely on seeing 
both sides of the connection to match up?

Try matching in FORWARD, PREROUTING, or POSTROUTING.  I believe these see all 
sides of the connection.

From docs[1]:

"Some patterns need to be able to observe both sides of a connection in order 
to match. This is pretty easy to achieve with Netfilter. By default, rules in 
the POSTROUTING chain of the mangle table will apply to both directions. 
However, the OUTPUT chain (for example) only sees locally generated packets, 
so it's not a good choice."

[1] http://l7-filter.sourceforge.net/L7-HOWTO-Netfilter

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] LARTC related talks at Swiss Unix Conference 2004

2004-07-09 Thread Thomas Graf

Might be of interest for some of you, especially:

  o HTB - detailed look into new QoS shaper - Martin Devera
  o Linux Packet Classification Performance - Jamal Hadi Salim
  o Status of IPv6 Implementations - Peter Bieringer
  o High Availability using Keepalived - Alexandre Cassen
  o Application Layer Fingerprinting - Hendrik Scholz


~~~
 SUCON'04 - 2nd Swiss Unix Conference

~~~

  2nd Swiss Unix Conference
September  2-4, 2004
 Technopark, Zurich
http://www.sucon.ch/


Early bird discount available until Monday, 9th August.


Provisional Conference Programme
~~~

Operating Systems:
  o Keynote: History of Linux - Theodore Ts'o
  o Documentation / CodingStyle and Beyond - Greg-KH
  o Linux Power Management - Patrick Mochel
  o NetBSD Status Report Fall 2004 - Hubert Feyrer
  o Old mistakes repeated (but you do get the source code now)
   - Poul-Henning Kamp
  o Resource Management in Linux using CKRM - Rik van Riel
  o The Linux Standard Base: Solving the Cross-Distribution
   Compatibility Challenge - Theodore Ts'o
  o The sysfs Filesystem - Patrick Mochel
  o udev, a way to manage /dev from userspace - Greg-KH

Free Software:
  o Keynote: Quality Issues in Free Software Projects
   - Martin Michlmayr
  o The Legal 101 for Open Source Contributors and Users
   - David Rosenthal
  o Debian - Contributing to the Project - Martin Michlmayr
  o Writing Portable Multimedia Applications - Samuel Hocevar
  o Google in Zurich - Narayanan Shivakumar, Google

Networking:
  o A secure BGP Implemementation - Henning Brauer
  o ADSL Provider Issues - Fredy Kuenzler
  o Application Layer Fingerprinting - Hendrik Scholz
  o FreeBSD Network Enhancements - Andre Oppermann
  o High Availability using Keepalived - Alexandre Cassen
  o HTB - detailed look into new QoS shaper - Martin Devera
  o Installing IPv6 - Peter Bieringer (Hands-On)
  o Linux Packet Classification Performance - Jamal Hadi Salim
  o Performance and Enhancement Response Team (PERT)
   - Chris Welti, SWITCH
  o PF - Extended Introduction - Max Laier
  o Status of IPv6 Implementations - Peter Bieringer

System Management:
  o FreeBSD network performance tunig - Hendrik Scholz
  o Fully automatic Linux installations - Thomas Lange
  o Performance bottleneck detection and removal - Hendrik Scholz
  o Spamikaze - a distributed anti-spam technology - Rik van Riel
  o System Admin Training in the Virtual Unix Lab - Hubert Feyrer

Security:
  o GBDE -- Spook strength disk encryption - Poul-Henning Kamp
  o Rule Set Based Access Control (RSBAC) - Securing Linux from
   the inside - Amon Ott

Multimedia:
  o All About MPLayer - Alex Beregszaszi
  o Multimedia On Unix: Past, Present, and Future - Mike Melanson
  o Multimedia Trash And The Evolution of Full Motion Video
   - Mike Melanson


Training Programme
~~~
Half-Day:
  o How to Recover From Hard Disk Disasters - Theodore Ts'o
  o How to Use LDAP for User Management - Lukas Beeler
  
Full-Day:
  o Contributing to Eclipse: understanding and writing plug-ins
 - Kai-Uwe Maetzel


Exhibition
~~~
The exhibition will take place on all days and is open for
commercial and non-profit organizations. Contact [EMAIL PROTECTED]
if you are interested in exhibiting.


Services
~~~
  o Free internet access via conference network for wired and
wireless clients.
  o Rooms open to the public for spontaneous meetings, coding
sessions and discussions.
  o Bulletin Boards with latest programme schedules and
job offers.


Conference Fees
~~~

Early Bird Registrations (Before August 9):
 Regular Association*  Student/Unemployed
1 Day CHF  50/EUR 33CHF  40/EUR 26CHF 30/EUR 20
3 DaysCHF  90/EUR 59CHF  70/EUR 46CHF 50/EUR 33

Regular Registrations (After August 9):
 Regular Association*  Student/Unemployed
1 Day CHF  80/EUR 53CHF  60/EUR 39CHF 50/EUR 33
3 DaysCHF 150/EUR 99CHF 100/EUR 66CHF 80/EUR 53

* All members of SUUG or any other national Unix User Group
  receive a discount. Ask your user group leaders for the
  authorization code.


Thanks to our sponsor
~~~

Hewlett Packard
   http://www.hp.com/


We are still looking for sponsors: contact [EMAIL PROTECTED] for
details.


  SUCON'04 Committee
  http://www.sucon.ch/
  [EMAIL PROTECTED]
~~

[LARTC] Layer 7 netfilter not working

2004-07-09 Thread FB
Hello there!
I am trying to get traffic shaping working on my Linux router (debian 
woody 3r02) and for some things I wanted to use the layer 7 packet 
classifier, but I can't get it to work.
Here is what I did:

-downloaded the patches from http://l7-filter.sourceforge.net
-downloaded the kernel 2.6.7 source
-downloaded the iptables 1.2.11 source
-patched kernel (layer7 patch and some patch to get iptables 1.2.11 
working with kernel 2.6.7)
-patched iptables
-compiled iptables
-activated layer 7 support in kernel-config (and a lot of other packet 
classifing options)
-compiled and installed kernel

Now I tried to mark some packets with layer 7 so that I can shape them 
with tc afterwards. But nothing changed, outgoing connection still 
didn't changed. So I changed the line in the iptables-script to this:

 $IPTABLES -t filter -A OUTPUT -m layer7 --l7dir /etc/l7-protocols 
--l7proto ftp -j DROP

before it was:
$IPTABLES -t mangle -A POSTROUTING -m layer7 --l7proto ftp -j MARK 
--set-mark 322

but nothing of them worked (I could still connect over ftp). The 
/proc/net/layer7_numpackets is 08 (don't know which 8 packets got 
identified there, but the number is not going any higher).

Any help is really appreciated!
-FB
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] Problem with HTB queuing discipline

2004-07-09 Thread Aravind babu
Hi ,
 
 
    I have the problem with HTB queuing discipline.I am giving my setup below.
 
 
  172.30.179.206   172.30.180.55
 
  LAN |  |   WAN
-| LINUX WITH    |--
172.30.179.140   | HTB   |  172.30.180.72
FTP SERVER   FTP CLIENT
 
On the LAN side i put FTP server(172.30.179.140) and on WAN side i put FTP client(172.30.180.72).
 
FTP client and FTP server will communicate through the middle linux box.
 
Middle linux box has two interfaces.eth0 is 172.30.179.206 and 
eth1 is 172.30.180.55
 
In the middle linux box i configured HTB using following commands.
 
./tc qdisc add dev eth0 root handle 1:0 htb
 
./tc class add dev eth0 parent 1:0 classid 1:1  htb rate 30kbps  ceil 30kbps 
 
./tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps  ceil 30kbps
 
./tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.30.180.72 match ip sport 21 0x flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.30.180.72 match ip sport 20 0x flowid 1:10
 
 
When i downloaded one file of size 10.7MB from FTP server(i.e from 
172.30.179.140) to client(i.e. 172.30.180.72) , download speed is coming as 362.19kbytes/sec instead of 30kbps which i ceil.What may be the problem? Any configuration issue?Any idea?
 
 
Thanks in advance,
Aravind.
 

Yahoo! India Careers: Over 50,000 jobs
online.

[LARTC] Re: the "cisco vs. Linux" thread (two answers (I have digest, sorry), Nick Erkert, Joshua Snyder)

2004-07-09 Thread José Ildefonso Camargo Tolosa
Message: 5
Date: Thu, 08 Jul 2004 14:44:26 -0700
From: Nicholas Erkert <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [LARTC] the "cisco vs. Linux" thread
Glen Mabey wrote:
On Thu, Jul 08, 2004 at 12:07:57PM -0400, Jos? Ildefonso Camargo Tolosa wrote:

you can use an Athlon 
64 with DDR RAM and very good network hardware (that is very, very 
important)


Regarding NICs, are there any recommendations out there for which
manufacturers to go with?  I don't need anything faster than 100baseT.

Thank you--
Glen Mabey
I have had some good luck with Intel cards using either drivers. I 
haven't noticed much difference between them but I haen't done a lot of 
stress testing on them.

On a side note has anyone built a linux router with dual/quad port 
ethernet cards (ie Intel PRO/1000 MT Quad Port Server Adapter)?
I used a dlink one: not fully tested, but seem to work fine.

--Nick Erkert

Message: 8
Date: Thu, 8 Jul 2004 17:31:06 -0500 (EST)
From: Joshua Snyder <[EMAIL PROTECTED]>
To: Sudheer Divakaran <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: [LARTC] Is Linux based Router feasible
Let me start out by saying that I work for a company that makes Linux
based routers.   Checkout www.imagestream.com   Anyway, any
Linux box will perform just fine at the data rates your talking about.
Some realtek cards (and even some 3com) report: Too much work at 
interrupt, and REALLY slows down things, even at 256kbps.  There are 
workarounds, but it just raises the CPU load A LOT (altough things 
starts working faster).

You don't even have to worry about what type of hardware your using as
long as it not more than 5 years old.  Now to answer some of the points
that other people have brought up.  You can make a pc that has a large
number of interfaces.  I have seen Linux boxes with 100 t-1's and 2 ds-3's
plugged into them... 8 port t-1 cards are common and dual port ds-3 cards
are easy to get.  You just have to get mainboards that have enough pci
slots.  In general as long as you stay inside of what the hardware can do
you should be able to route at line rate.  Currently most pc hardware is
limited to about a max of 1Gbit/sec but server hardware can be used to
build routers that will route 4Gbit/sec.  Not as good as some of the
highest end cisco routers... but ten's of thousands of dollars cheaper.
One thing I have seen doing testing of many routers vs Linux routers most
cisco routers tend to get badly boughed down when running many access
lists.  This is not a big problem with a Linux box or even other non-cisco
routers.  If you don't believe me checkout...
http://www.nwfusion.com/reviews/2003/0714rev.html
Just as I said: cisco use very *small* cpus.
You should have no problems doing what you want to do.
josh
p.s. alot of the packet per sec numbers that cisco talks about are only
valid when routing from Ethernet to Ethernet interfaces and with packets
that stay in the fast switching path on the cisco.  If you start talking
about other interfaces all of those numbers are out of the window.  This
leads many people to end-up with cisco's that are way under powered for
the application.  I am not saying that cisco's can't route at wire-speed
but that most people don't have the right router for the job.

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


Re: [LARTC] the "cisco vs. Linux" thread

2004-07-09 Thread Alfie Viechweg
Regarding building your own router/switch. You might want to check out 
www.routerboard.com for a
really reasonably priced 4 port NIC.

 --Alfie Viechweg
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/


[LARTC] iptables MARK with msn messenger

2004-07-09 Thread Nuno Miguel Pais Fernandes
Hello,


I've setup a router with linux 2.4.26 with h323 conntrack patch from
pom-ng. The network schema is:


ADSL
internal  ||-
--| Linux  |
  ||-
   Frame-Relay

Default gw is frame relay and i'm using netfilter mark to send traffic
to adsl.

# ip rule ls
0:  from all lookup local
32765:  from all fwmark 0x2 lookup 200
32766:  from all lookup main
32767:  from all lookup 253

How can i send msn netmeeting trafic to ADSL? Is it port based? Which
ports should be marked with netfilter?

Thanks
Nuno Fernandes

-- 
Nuno Miguel Pais Fernandes <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part


RE: [LARTC] the "cisco vs. Linux" thread

2004-07-09 Thread Jeff Green

FYI this topic has been covered on the Zebra and Quagga lists

 - hardware processors, memory, NICs, etc
 - software OS (Linux, *BSD), drivers, etc

I've been running a couple of Linux routers for about 2 years now, I'm
using
them as core routers so I bought a couple of rackmount "server" boxes
with
redundant PSUs and h/w RAID (1) for hotswap disks.

I'm using a couple of Adaptec Quartet66 NICs in each, that gives me
2 x 1GbE (on mobo) and 8 x 10/100 Mb ports per box.


Regards,


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Nicholas Erkert
Sent: 08 July 2004 22:44
To: [EMAIL PROTECTED]
Subject: Re: [LARTC] the "cisco vs. Linux" thread

Glen Mabey wrote:
> On Thu, Jul 08, 2004 at 12:07:57PM -0400, Jos? Ildefonso Camargo
Tolosa wrote:
>
>>you can use an Athlon
>>64 with DDR RAM and very good network hardware (that is very, very
>>important)
>
>
> Regarding NICs, are there any recommendations out there for which
> manufacturers to go with?  I don't need anything faster than 100baseT.
>
> I would think that Intel and 3Com would be in the "reliable" category,

> and RTL-based cards in the "forget it" category.
>
> On the Intel note, I wonder what experience y'all have had with the
> two different drivers for the EtherExpressPro/100 card.  That is,
> eepro100 versus e100.  I would think that noone would take the time to

> rewrite a driver if there wasn't anything wrong with the original one.
>
> Thank you--
> Glen Mabey
>
I have had some good luck with Intel cards using either drivers. I
haven't noticed much difference between them but I haen't done a lot of
stress testing on them.

On a side note has anyone built a linux router with dual/quad port
ethernet cards (ie Intel PRO/1000 MT Quad Port Server Adapter)?


--Nick Erkert
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/



Confidentiality Note: The information contained in this email and
document(s) attached are for the exclusive use of the addressee and may contain 
confidential, privileged and non-disclosable information. If the recipient of this 
email is not the addressee, such recipient is strictly prohibited from reading, 
photocopying, distribution or otherwise using this email or its contents in any way. 
Please notify the Sapiens (UK) Ltd. Systems Administrator via e-mail immediately at 
[EMAIL PROTECTED], if you have received this email in error.

Disclaimer: The views, opinions and guidelines contained in this confidential e-mail 
are those of the originating author and may not be representative of Sapiens (UK) Ltd.

___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/