All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Grant <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Spill over
Date: Sat, 23 Apr 2005 22:11:23 +0000	[thread overview]
Message-ID: <426AC80B.6000009@riverviewtech.net> (raw)
In-Reply-To: <fad9d484050423143460593cb9@mail.gmail.com>

> List
> 
> I need some help, advice or just a starting point on the following 
> situation:
> 
> Link A - 64kbps leased line
> Link B - 512kbps ADSL line
> 
> Is it possible to have Link A saturated constantly and have the excess 
> traffic "spill over" onto Link B? I know it's possible to have packets 
> sent down links in a round-robin fashion and I've read in the howto on 
> load sharing over multiple interfaces 
> (http://lartc.org/howto/lartc.loadshare.html), but I do not have control 
> over the termination of the link at the ISP's (two different one as 
> well). Also note that splitting different protocols over each of these 
> links are not possible in our case.
> 
> Reason being, Link A is a more reliable and more expensive link, so I 
> need to over-use it's capacity if it we're, and use the cheaper ADSL 
> (link B) offering to keep al services running when the leased line (A) 
> is saturated.
> 
> Any tips, suggestions and comments would be welcomed.
> 
> Regards

Off hand the thing that comes to mind would be to use an IPTables rule to estimate the rate of flow (I'm not sure what match this is (limit?) but I do think there is one.) and reset the route or mark traffic and have the routing table reroute traffic that is marked.  Keep in mind that this will only roughly saturate your 64 kbps link on your outbound traffic.  It will do nothing to control the % utilization on the traffic that comes back in to you.

Can I ask why you are wanting to saturate tech 64 kbps leased line?  Are you trying to encourage management that you need a faster leased line by going to them with graphs stating that the ADSL they purchased did not really solve the problem like they were wanting it to?  ;)

Another not so nice trick that you could do is just send bogus traffic, via packet gen, out the 64k at a lower priority than the rest of your legitimate traffic thus insurring that the 64 kbps line is full all the time even if you don't have that much legitimate traffic on it.  Yes I should probably be thumped or at least pelted with Nerf Darts for this idea, but it is an answer if you are just trying to saturate the 64 kbps line.  (Time to run and hide as I hear the Nerf guns being pumped up!)



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  reply	other threads:[~2005-04-23 22:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-23 21:34 [LARTC] Spill over Kenneth Kalmer
2005-04-23 22:11 ` Taylor Grant [this message]
2005-04-23 23:18 ` Chris Bennett
2005-04-25  7:48 ` Kenneth Kalmer
2005-04-25 15:43 ` Taylor, Grant
2005-04-25 21:56 ` Chris Bennett
2005-05-04 11:11 ` Kenneth Kalmer
2005-05-04 21:12 ` Kenneth Kalmer

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=426AC80B.6000009@riverviewtech.net \
    --to=gtaylor@riverviewtech.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.