All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] New member
@ 2003-11-03  8:37 ph4ke
  2003-11-03 10:29 ` ph4ke
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: ph4ke @ 2003-11-03  8:37 UTC (permalink / raw)
  To: lartc


Hi All,


I'm new one the list and thought it somewhat appropriate to 
divulge a little info about myself 

Name: Cilliè
Country : South-Africa 

I work for a ISP and we have been playing with tc/iptables/iproute
snort and a whole load of other stuff on and off for the past view months. 

I have a small problem with tc that I struggle to find a solution for and was 
wondering if someone would be so kind as to help with it. 

I have successfully set up some queuing chains, classfull and some 
tbf's and sfq's but felt limited with the extent of tc's packet classifier. 

So i thought that the FWMARK thing would be a great solution to the problem, 
but unfortunately I can not get this to work. 

Marking of the packets appears to be successfull but tc's classifier 
[ rule something like "fw handle 6" ] fails to pick up the marked packets 
( if its all right if i explain this so crudely ) 

I have tried several different kernels, with the patches applied, and yet it 
still seems to fail in this. 

First was a patched RH 7.3 kernel ( 2.5.18-3 ) 
A redhat 9 kernel and a 
gentoo linux kernel that had already been patched with [filter on fwmark] 
and all the other relevant stuff. 

All the relevant options are compiled in. 

As i'm writing this a stock 2.4.20 kernel is also being compiled. 

Could anyone please try and clarify for me why this does not work ( or what I 
am 10 to 1 doing wrong ?) 

I would really appreciate this 


Best Regards, 
Ciiliè 





-- 
evil is the r00t of all windows boxes
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] New member
  2003-11-03  8:37 [LARTC] New member ph4ke
@ 2003-11-03 10:29 ` ph4ke
  2003-11-03 10:35 ` Edmund Turner
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: ph4ke @ 2003-11-03 10:29 UTC (permalink / raw)
  To: lartc


Hi Edmund 

Thanks for responding so soon. 

That works fine for shaping traffic that likes to talk on fixed ports, like 
smtp of pop3, but really do much when you want to start limiting things like 
outbound http or ftp traffic. 

regards,
cilliè


On Monday 03 November 2003 09:04, you wrote:
> Cillie,
>  I too have experience similar problems. I have since resorted to mark
> the IP addresses for the respective tc classifiers as such :
>
> Tc filter add dev eth0 parent 1:0 protocol ip prio 7 u32 match ip src
> (IP address) classid 1:10
>
> This seem to work for me. By the way, im using a patched RH9 2.4.20-18.
> Iptables 1.2.8-9.
>
> Regards
> edmund

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [LARTC] New member
  2003-11-03  8:37 [LARTC] New member ph4ke
  2003-11-03 10:29 ` ph4ke
@ 2003-11-03 10:35 ` Edmund Turner
  2003-11-03 11:17 ` ph4ke
  2003-11-04  3:54 ` Edmund Turner
  3 siblings, 0 replies; 5+ messages in thread
From: Edmund Turner @ 2003-11-03 10:35 UTC (permalink / raw)
  To: lartc


Cillie,
I might be missing something here, but I do use this filter setup for
limiting outbound http and ftp traffic.


Regards
edmund

-----Original Message-----
From: ph4ke [mailto:deff@sadomain.co.za] 
Sent: Monday, November 03, 2003 8:27 PM
To: eturner@monash.edu.my
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] New member


Hi Edmund 

Thanks for responding so soon. 

That works fine for shaping traffic that likes to talk on fixed ports,
like 
smtp of pop3, but really do much when you want to start limiting things
like 
outbound http or ftp traffic. 

regards,
cilliè


On Monday 03 November 2003 09:04, you wrote:
> Cillie,
>  I too have experience similar problems. I have since resorted to mark
> the IP addresses for the respective tc classifiers as such :
>
> Tc filter add dev eth0 parent 1:0 protocol ip prio 7 u32 match ip src
> (IP address) classid 1:10
>
> This seem to work for me. By the way, im using a patched RH9
2.4.20-18.
> Iptables 1.2.8-9.
>
> Regards
> edmund

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LARTC] New member
  2003-11-03  8:37 [LARTC] New member ph4ke
  2003-11-03 10:29 ` ph4ke
  2003-11-03 10:35 ` Edmund Turner
@ 2003-11-03 11:17 ` ph4ke
  2003-11-04  3:54 ` Edmund Turner
  3 siblings, 0 replies; 5+ messages in thread
From: ph4ke @ 2003-11-03 11:17 UTC (permalink / raw)
  To: lartc

Hi Edmund 

OK, sorry 'bout that. 

Say for example that I have a webserver and I only want that thing to push 
512kbit out. The only way that I see that I would be able to limit this kind 
of outbound traffic with the tc classifier is if I knew which ip's will be 
visiting web-pages.  If this was the situation I would be able to have a long 
list of rules that all look something like 
	.. u32 match ip src xxx.xxx.xxx.xx flowid 1:1 
or something 

Unfortunately there is about a few million possible ipv4 addresses that can 
access the box if they really felt like it. 

This could problem could possibly be solved by having a rule like this : 

	.. u32 match ip sport 80 match ip src (webserver) flowid whatever

But the real problem lies in limiting ftp, since ftp (at least the way i 
thought it works. could be wrong. probably am) 
just does the whole auth section on sport 20/21 and 
the data transfer actually take place on a random 1024+ source port 
and a random 1024+ destination port. 

This would be perfectly solved with iptables marking because one 
should be able to do something like 
	
--append PREROUTING -m state --state ESTABLISHED, RELATED --jump MARK 
--set mark 1   { please excuse the line wrapping } 

thanks a lot for your time 
cilliè 


On Monday 03 November 2003 10:35, you wrote:
> Cillie,
> I might be missing something here, but I do use this filter setup for
> limiting outbound http and ftp traffic.
>
>
> Regards
> edmund


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [LARTC] New member
  2003-11-03  8:37 [LARTC] New member ph4ke
                   ` (2 preceding siblings ...)
  2003-11-03 11:17 ` ph4ke
@ 2003-11-04  3:54 ` Edmund Turner
  3 siblings, 0 replies; 5+ messages in thread
From: Edmund Turner @ 2003-11-04  3:54 UTC (permalink / raw)
  To: lartc

Cillie, take this setup for example:
Web server IP = 192.168.1.2
1MB access to the internet.

Etho -LAN
Eth2 - External --1MB access to the internet.

tc qdisc add dev eth2 root handle 3: htb default 10
tc class add dev eth2 parent 3: classid 3:1 htb rate 1mbit
tc class add dev eth2 parent 3:1 classid 3:12 htb rate 400kbit ceil
400kbit prio 4
tc filter add dev eth2 parent 3:0 protocol ip prio 4 u32 match ip src
192.168.1.2 classid 3:12


I manage to limit all outbound traffic from 192.168.1.2 by putting a
filter for the src address of the web server on the external NIC. This
seems to work for me.


Regards

edmund


-----Original Message-----
From: ph4ke [mailto:deff@sadomain.co.za] 
Sent: Monday, November 03, 2003 9:14 PM
To: eturner@monash.edu.my
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] New member

Hi Edmund 

OK, sorry 'bout that. 

Say for example that I have a webserver and I only want that thing to
push 
512kbit out. The only way that I see that I would be able to limit this
kind 
of outbound traffic with the tc classifier is if I knew which ip's will
be 
visiting web-pages.  If this was the situation I would be able to have a
long 
list of rules that all look something like 
	.. u32 match ip src xxx.xxx.xxx.xx flowid 1:1 
or something 

Unfortunately there is about a few million possible ipv4 addresses that
can 
access the box if they really felt like it. 

This could problem could possibly be solved by having a rule like this :


	.. u32 match ip sport 80 match ip src (webserver) flowid
whatever

But the real problem lies in limiting ftp, since ftp (at least the way i

thought it works. could be wrong. probably am) 
just does the whole auth section on sport 20/21 and 
the data transfer actually take place on a random 1024+ source port 
and a random 1024+ destination port. 

This would be perfectly solved with iptables marking because one 
should be able to do something like 
	
--append PREROUTING -m state --state ESTABLISHED, RELATED --jump MARK 
--set mark 1   { please excuse the line wrapping } 

thanks a lot for your time 
cilliè 


On Monday 03 November 2003 10:35, you wrote:
> Cillie,
> I might be missing something here, but I do use this filter setup for
> limiting outbound http and ftp traffic.
>
>
> Regards
> edmund

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-11-04  3:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-03  8:37 [LARTC] New member ph4ke
2003-11-03 10:29 ` ph4ke
2003-11-03 10:35 ` Edmund Turner
2003-11-03 11:17 ` ph4ke
2003-11-04  3:54 ` Edmund Turner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.