From: Bob Gustafson <bobgus@mcs.net>
To: lartc@vger.kernel.org
Subject: [LARTC] Per-connection routing for multiple uplinks/providers ??
Date: Mon, 15 Apr 2002 20:08:42 +0000 [thread overview]
Message-ID: <marc-lartc-101890143014670@msgid-missing> (raw)
Hi - I'm a new subscriber to this list.
I have been digging through the Lartc documentation as well as Netfilter,
etc. and haven't found much on per-connection routing for multiple
uplinks/providers.
What I would like to do is cleanly move packets out to the Internet over
two (maybe 3) separate interfaces, utilizing all of the bandwidth, and
avoiding snags.
I could use a round-robin scheduler, which would put consecutive packets on
different interfaces. I think this will run into problems when the reply
packets come back. Maybe not ??
I read through Arthur Leeuwen's documentation
(http://lartc.org/HOWTO//cvs/2.4routing/html/x247.html )
on a scheme for dividing the outgoing packets on a per-route basis. Packets
going to the same destination will go through the same interface. This gets
around the round-robin problem, but I think this is not 'fair' in the sense
that one interface might accumulate more routes than the other, and there
does not seem to be a mechanism (other than periodically flushing the route
tables) for evening out the flows. It is pretty simple though and I will
use this as a first chop solution.
Another approach to the problem would be to do a round-robin on a
per-connection basis. Each new connection would go out of the 'next'
interface.
I don't know exactly how to do this though. Perhaps marking the 'NEW' state
packet and routing on the mark (even marks go to the left interface, odd
marks to the right,... mod N for more than 2 interfaces).
Of course, it would be nice to allocate connections on an available
bandwidth basis. Also do some QoS for ftp vs interactive (am looking at
the wondershaper..)
Also would be nice to periodically grab statistics so that I could
determine whether I need to get rid of an ISP (for non-competitive price/bw
stats). The stats could also be used to 'close the loop' around the routing
to ensure that the best bandwidth is being achieved.
Also would be nice to energize a dial-up connection if the other 2 die for
some reason.
Does such a beast exist? Is it possible to build with current
ip/tc/netfilter technology? I am running a near stock RH 7.2 at the
moment. Each ISP line is going through a separate (proprietary/black-box)
firewall/router and then into the RH7.2 box.
Thanks for your time.
BobG
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next reply other threads:[~2002-04-15 20:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-15 20:08 Bob Gustafson [this message]
2002-04-15 21:55 ` [LARTC] Per-connection routing for multiple uplinks/providers Arthur van Leeuwen
2002-04-16 6:01 ` Bob Gustafson
2002-04-16 6:56 ` Arthur van Leeuwen
2002-04-16 11:48 ` Patrick McHardy
2002-04-16 13:38 ` Mihai RUSU
2002-04-16 13:57 ` Patrick McHardy
2002-04-16 14:14 ` Mihai RUSU
2002-04-16 20:01 ` Bob Gustafson
2002-04-16 20:26 ` Don Cohen
2002-04-16 21:38 ` Bob Gustafson
2002-04-28 15:27 ` [LARTC] Per-connection routing for multiple uplinks/providers ?? mikee
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-101890143014670@msgid-missing \
--to=bobgus@mcs.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.