From: Andrew Beverley <andy@andybev.com>
To: Lloyd Standish <lloyd@crnatural.net>
Cc: netfilter@vger.kernel.org
Subject: Re: bandwidth-limiting on LAN interface egress (2)
Date: Wed, 16 Nov 2011 22:00:03 +0000 [thread overview]
Message-ID: <1321480803.2382.62.camel@andybev-desktop> (raw)
In-Reply-To: <op.v41qaj2hx1lyi3@debiandesk2.net>
On Wed, 2011-11-16 at 09:50 -0600, Lloyd Standish wrote:
> I have improved my previous post in hope of some advice, or at least a
> suggestion on where to ask this sort of question.
Yep, I am planning on reading your other post when I get round to it,
but it was quite long...
> Suppose one is building a netfilter router, LAN to Internet, with
> multiple outward-facing interfaces (eth1, eth2, and eth3). There needs
> to be load-balancing over the outward interfaces.
Have you got this part working okay?
> There needs to be
> bandwidth-limiting for users on the LAN. Users are typical Internet
> users (primarily http download with some important interactive traffic
> such as VOIP.)
>
> Theoretically, can per-user bandwidth-limiting be done on egress of the
> LAN using htb+prio+sfq without encountering insurmountable latency
> problems due to queuing of incoming packets in the router?
If you are limiting per-user, then depending on the number of users, you
may run into problems. There was a similar discussion here a while ago:
http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/41664
The upshot of that thread was to switch to u32 hashing filters if you
can.
> Should
> traffic shaping (prioritizing of packets for interactive traffic)
> probably be an adequate solution to any latency problems?
I do it reasonably successfully with a lot of users on a small link.
http://andybev.com has some of the details.
> Is there a way to use a policing queuing discipline in a case like
> this?
My personal opinion is that you shouldn't limit per user. You should
instead prioritise traffic properly. This way you'll have a lot less
classes and a lot less overhead. The traffic of heavy users over-using
the link will get less priority than low-bandwidth applications, so you
will achieve the same effect.
> (I assume it would have to be on egress of the LAN interface,
> since I cannot see how to police on ingress of the Internet-facing
> interfaces due to the per-user bandwidth-limiting.)
Correct, you need to stick with egress shaping, so your inbound links
from the internet will need to be shaped on the internal LAN interface.
Andy
next prev parent reply other threads:[~2011-11-16 22:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 15:50 bandwidth-limiting on LAN interface egress (2) Lloyd Standish
2011-11-16 22:00 ` Andrew Beverley [this message]
2011-11-16 22:56 ` Lloyd Standish
2011-11-17 5:06 ` Lloyd Standish
2011-11-20 13:46 ` Andrew Beverley
2011-11-20 13:38 ` Andrew Beverley
2011-11-20 14:25 ` Lloyd Standish
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=1321480803.2382.62.camel@andybev-desktop \
--to=andy@andybev.com \
--cc=lloyd@crnatural.net \
--cc=netfilter@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