All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] QoS upstream bandwidth sharing
Date: Fri, 25 Apr 2003 16:50:58 +0000	[thread overview]
Message-ID: <marc-lartc-105128950917647@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105128399707588@msgid-missing>

On Friday 25 April 2003 17:06, D de Boer wrote:
> My situation is as follows:
>
> pc1     pc2
>    \   /
>     \ /
>     hub (LAN) -----eth0_firewall_eth1-----modem-----internet
>     / \            |
>    /   \           192.168.0.1
> pc3     pc4
>
> pc1: 192.168.0.2
> pc2: 192.168.0.3
> pc3: 192.168.0.4
> pc4: 192.168.0.5
>
> I want to divide my upload speed (512kbps) evenly amongst pc1, pc2, pc3 and
> pc4. It should be possible for them to borrow bandwidth from the others
> when they don't use their share fully. I've done quite some reading, and my
> kernel is properly compiled. For instance the SFQ class does work. I have
> been playing around with HTB, but I can't get it to work properly.
>
> What basic HTB setup would I need? Which eth device (1 or 2) should I do
> the shaping on, if I want to shape the outgoing traffic (I want to divide
> upload stream from LAN to internet after all)?
If you add a htb qdisc to eth0, it will shape all traffic leaving eth0.

> What I came up with myself is to have 4 classes (apart from the root
> class): one for every pc, and then use tc filters to match the packets
> coming from 192.168.0.2 to class 1, those from 192.168.0.3 to class 2, etc.
> How should I do this? Or is there an easier way?
Indeed, you need 4 classes.

> Could the ip masquerading in my firewall pose a problem? At the moment the
> firewall configuration is very simple and looks like this:
> iptables --table nat --append POSTROUTING --out-interface eth0 -j
> MASQUERADE iptables --append FORWARD --in-interface eth1 -j ACCEPT
It will cause problems if you want to shape upload traffic.  Upload traffic 
leaves eth1 so the source address is rewritten to that of the firewall.  You 
can solve this by marking the packets when they are entering the firewall and 
use that mark when they leave the firewall.  You need the fw filter for this.

I have some extra information about shaping on www.docum.org.  

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

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

      reply	other threads:[~2003-04-25 16:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-25 15:06 [LARTC] QoS upstream bandwidth sharing D de Boer
2003-04-25 16:50 ` Stef Coene [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-105128950917647@msgid-missing \
    --to=stef.coene@docum.org \
    --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 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.