From: "lartc@manchotnetworks.net" <lartc@manchotnetworks.net>
To: lartc@vger.kernel.org
Subject: [LARTC] advice for bandwidth control & traffic accounting
Date: Mon, 07 Jul 2003 12:43:02 +0000 [thread overview]
Message-ID: <marc-lartc-105758200602018@msgid-missing> (raw)
hello gentle readers,
a somewhat complicated situation to explain, but I am most curious to
hear any advice or comments that you may be kind enough to offer.
I have the following situation:
[ multiple ]
[ client ----- BW-Linux-1 ] --------- BW-Linux-2 ----- Internet
[ networks ]
(A) (B) (C) (D)
[ [X] ]
metrics:
[X] multiple, mututally exclusive [X]'s will exist
(A) private rfc-1918 address spaces that do not conflict with other
client networks in the same (A) -- we hope! we are limited to 14 client
nets behind (B) if we nat each one with a seperate address.
(B) -NAT's each client network in (A) with its own address from (C)
-large squid to hopefully economize (C) bandwidth
(C) an expensive link out of our administrative control. we get a
rfc-1918 /28 for each [X]. 2^4-2\x14 usable addresses.
(D) -large parent squid cache for BW-Linux-1
-iptables passes pkt hdrs to ulogd and we save portions to mysql
-summary traffic accounting for each (A) -- how much and where for
http, ftp, etc.
questions:
it would be desirable if (D) could collect all traffic data for
bandwidth usage graphs, etc., however, due to natting and squid,
ascertaining what a specfic host did in (A) seems unlikely.
does anyone know of a connection tracking mechnism (x-forwarded-for, or
other) such that (D) could know what a specific host in (A) did?
when a network in (A) exceeds its bandwidth quota, it will require (or
would be best) that both BW-Linux-1 and BW-Linux-2 acted in a
cooperative manner limiting its bandwidth. is there an existing
mechinism to have tc perform changes cooperatively on (B) and (D)?
does anyone have experience with the quota patch in iptables and jumped
to a userspace target to instigate tc commands? i'm thinking about
trying to develop a program that would allow (B) and (D) to syncronize
their tc policy simultaneously ...
Many, Many Sincere Thanks
Charles Shick
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
reply other threads:[~2003-07-07 12:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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-105758200602018@msgid-missing \
--to=lartc@manchotnetworks.net \
--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.