Re: Spill over

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris, Taylor and the list

Sorry for the late reply, had a much needed holiday and did some
research on the topic.

I'm willing to test Taylor's suggestion using some ugly route hacking
to balance traffic over the links but I need an application that I can
call to get the current throughput on any link, then match this with
the links known max and then working on the 95th percentile start
changing routes to try and keep each link maxed at around 95%. I know
this will not be easy to achieve, but if nothing else it will be a
great learning experience.

Another thing I stumbled upon is the TEQL scheduling algorithm,
http://www.docum.org/docum.org/docs/kernel/teql.php, and it seems to
do just what I need. Considering all my connections (except the
64kbps) is PPP connections I can easily use ip-down and ip-up to
enslave,deslave devices from the qdisc that does the traffic. I can
also easily adjust all the iptables rules from here as well to make
sure the source natting is correct.

I also understand that in this situation I need to turn off return
path filtering in the kernel to avoid the kernel rejecting the packets
as martian packets, or is this only the case when I have control over
both ends of the link and do channel trunking?

Another project that came up is balance,
http://balance.sourceforge.net, but this is only a TCP proxy that
performs round-robin loads balancing with failover. BalanceNG, the
commercial version does have weighted averages and least-used paths
and I don't know what else. A few commercial alternatives, one from
Sangoma called Wanpipe uses the TEQL as it's backed and it only
provides the fail-over and alternative configurations and monitoring
IIRC.

In reply to Chris, yes, South African bandwidth prices has long been a
topic that brings fear into the heart of the average South African.
Read more on http://www.hellkom.com.co.za, I have nothing to do with
this site but they do tell it like it is...

Also, all the users are already shaped behind the box so they won't
know when they are using the faster links. We don't only have these
two connections, we have plenty more including wireless links with
seperate providers, multiple ADSL and leased line combinations. The
64kbps and 512kbps where only examples, but thanks, I appreciate your
opinions on this!

As usual, any comments, suggestions, even insults are welcomed and appreciated!

On 4/25/05, Chris Bennett <chris@xxxxxxxxxx> wrote:
>
> A little googling tells me 250 ZAR ~  42 USD.  Is this correct?  If so, ouch.. that's pricey.
>
> 3GB (assuming B in this case is BYTE) comes  out to about 9kbit / second over a month, if I did my math  correctly.  Ouch again.
>
> Does the 3GB apply to the total of up and  down traffic, or just down?  Because you can't control traffic coming to  you very well.  You can try to control TCP traffic with policing, but UDP  traffic does its own thing.  Not to mention jokers who decide to flood the  link for the hell of it.
>
> Given this new info, it sounds more like  you shouldn't try to use the 512kbit link at all unless the 64kbit link goes  down.  If you do try to push "excess" traffic onto it, all that does  is encourage the use of applications that will consume the entire bandwidth  available.  If that is really beyond your budget, it doesn't seem  like something you'd want to do.  Better to set the expectations at 64kbit  so the users don't get the idea of tuning into Internet radio or  something.  In fact, if the 64kbit link does go down, it could be a good  idea to police the 512kbit link down to 64kbit, just so the users don't  jump for joy when the 64kbit link goes down... (keeping in mind that policing is  no guarantee that you'll actually stay below 64kbit usage, especially if a lot  of the traffic is UDP).
>
> ----- Original Message -----
> From:    Kenneth Kalmer
> To: Chris Bennett ; Taylor    Grant
> Cc: lartc
> Sent: Monday, April 25, 2005 2:48  AM
> Subject: Re:  Spill over
>
> Taylor &    Chris (and the list)
>
> The arguments behind my choice here is cost    driven, the 64kbps line is a fixed monthly rate for unlimited use, the 512kbps    line costs us roughly ZAR250 per 3GB of usage. This can get quite expensive as    the lines in question is for a college and we all know what students do to    bandwidth :)
>
> Taken the amount we pay every month for the 64kbps line    it's more economical to over utilize the link as a primary connection than to    have it lying around as a backup. South Africa and data connections don't go    well in the same sentence...
>
> As Chris suggested, I need something that    can detect when Link A is saturated and then redirect the traffic over Link B    until there is available bandwidth on Link A again. The rate limit trick of    Taylor might work once I get to understand the usage patterns of these    students. But for at least the first 3 months I won't have proper data at my    disposal.
>
> Thanks for your replies!
>
> _______________________________________________
> LARTC mailing list
> LARTC@xxxxxxxxxxxxxxx
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
>

--

Kenneth Kalmer
kenneth.kalmer@xxxxxxxxx
http://opensourcery.blogspot.com
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux