Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: "Edmund Turner" <eturner@monash.edu.my>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] New member
Date: Tue, 04 Nov 2003 03:54:34 +0000	[thread overview]
Message-ID: <marc-lartc-106791907104251@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106784862220876@msgid-missing>

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/

      parent reply	other threads:[~2003-11-04  3:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-106791907104251@msgid-missing \
    --to=eturner@monash.edu.my \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox