All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Multipath Multirouter - Can it be done?
Date: Thu, 11 Oct 2007 20:02:56 +0000	[thread overview]
Message-ID: <470E8170.3020801@riverviewtech.net> (raw)
In-Reply-To: <a11134e1c29db0b6f777ee11ab768d79@coairnet.com>

On 10/11/07 14:07, Tony Hagans wrote:
> Thanks for the input Grant,  we have kicked around the idea of BGP or 
> a similar method for the routing but the issue is that NAT takes 
> place at the box doing the multiwan.  We only have a few external IP 
> addresses and all of our connections are from different vendors so 
> they are spread across several different IP ranges.  My first though 
> was to create a tunnels between the machines at each location and put 
> the tunnel adapters in a routing table with a prio > the local 
> routing table.  This would allow data to:

You are welcome.

Just because you are doing NATing at the core egress points instead of 
the edge ingress points does not mean that you can not still use some 
sort of routing protocol.  Do NATing where you are but use some sort of 
routing protocol that will keep all your routers in sync with each 
other.  If you use some sort of routing protocol that includes 
connection state and possibly load, you could easily shift where traffic 
is routed out of your network based on load and / or availability.  Your 
customers would talk to the upstream router that you direct them to use, 
which will then send the traffic out the appropriate way.

> client --> main gateway --> routing table mpath to any gateway on the 
> network --> internet as available

Using some sort of routing protocol that includes load / cost of a 
particular connection, you could easily just let routers pick the best 
route to go out based on the routing protocol.  Your routers that have a 
single connection would just do standard NATing.  Your routers that have 
multiple connections would use the basic multipath routing described in 
the LARTC How-To.  Use your routing protocols to pick which rout to go out.

I would also make sure to educate each router be aware of the subnets 
that the provider has.  There is no reason to ever go out provider B to 
get to a server on provider A's network unless the link with provider A 
is down.

It sounds like you don't have a bunch of IPs, say one for each client, 
but could you get extra IPs from each provider, say one ip for each 
router in your network from each provider.  So if you had 5 providers, 
get 5 IPs from each, for a total of 25 IPs.  If you could do this, you 
could have each router be able to connect directly to the links from 
each provider and load balance out with multipath routing if you so 
chose.  Granted this would be dependent on your network structure and 
its capabilities.  One advantage of this is that you would have more IPs 
to hid services behind.  If one IP became black listed for some reason, 
you could shift traffic off of it and use another one with out much 
hassle at all.

> I have a feeling this would cause some very very bad problems with 
> return paths and I don't know what would happen if a tunnel were to 
> fail or something of that nature.  The system is basically many many 
> wireless repeaters, access points, and clients spread across about 60 
> square miles.  It crosses 3 LATAs and is within range of at least 10 
> different ISP's who all use different providers.  The idea was if we 
> could instead of bringing the traffic all back to where it goes now 
> be able to go wherever was closest/least busy/etc and hop on a 
> DSL/Cable/Wireless/whatever we can pick up for cheap bandwidth it 
> would take some of the traffic from individuals doing whatever they 
> do off the DS3 durring the day for businesses and schools to make use 
> of.

I think this is possible to do.  I think you will have better luck if 
you have traffic predominantly use the closest router and not try to 
load balance a given client across multiple providers but rather load 
balance by picking which provider a given client uses.  You could even 
use something as devious as VRRP and virtual routers to on the fly 
change which router was a given IP with out requiring clients to 
re-configure any thing.  Granted you run a chance of in progress 
sessions being messed up, but that is a problem you will have with just 
about any multipath setup where you are NATing at the core.

If you will provide more information on what your actual network 
topology is including if things are a layer 2 or layer 3 link and what 
subnets are where, I'll be glad to help.



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

      parent reply	other threads:[~2007-10-11 20:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11  3:44 [LARTC] Multipath Multirouter - Can it be done? Tony Hagans
2007-10-11  3:53 ` Alex Samad
2007-10-11 14:19 ` Grant Taylor
2007-10-11 19:07 ` Tony Hagans
2007-10-11 20:02 ` Grant Taylor [this message]

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=470E8170.3020801@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.