Linux Netfilter discussions
 help / color / mirror / Atom feed
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



  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