All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] ADSL channel boding or Load balancing
Date: Thu, 11 Oct 2007 16:18:24 +0000	[thread overview]
Message-ID: <470E4CD0.7020505@riverviewtech.net> (raw)
In-Reply-To: <c2cd58b40710110817t19d6b45dpcff432934c367d22@mail.gmail.com>

On 10/11/07 10:17, the sew wrote:
> We currently using iproute2 for load balancing. However we need more 
> upload speed as we load balance over 3 dsl lines.

*nod*

> I've been looking for a way to combine the upload speed to more 
> faster. Found a site called www.upstreaminter.net where these guys 
> bond the adsl channels to improve uploads, Since downloading is 
> problem as its need to know the ip address of the downloader they use 
> VPN to their existing infrastruture to improve download speeds to a 
> single IP.  Im not interested in doing that though, Our company uses 
> alot of mail to our smarthost and the upload is only 256k on the 
> 4Mbit Line

Now you are entering some more complex and interesting territory.  The 
problem you have with traditional load balancing that the LARTC suggests 
for SOHO users is that you have multiple external IP addresses.  Thus 
any single stream is limited to the speed of the link that it is using.

If you are using multiple links from a single provider who is willing to 
work with you, you could do something like I did with the two 1.1 Mbps 
SDSL links that I have aggregated in to one 2.2 Mbps link.  I can 
easily, and routinely do, push and / or pull 1.9+ Mbps on a single ftp 
stream.  I have a small globally routable DMZ behind the two globally 
routable IPs for my SDSL links.  My ISP has a router here on my premise 
and is using OSPF to load balance across the SDSL links.  (A little 
ASCII drawing comes to mind.)

                :
                :        +--------+     +--------+
+-----+     +-----+     | SDSL 1 +-----+ SDSL 1 |     +------+
| LAN +-----| NAT +-----+ CPERTR |     | ISPRTR +-----+ INet |
+-----+     +-----+     | SDSL 2 +-----+ SDSL 2 |     +------+
                :        +--------+     +--------+
  Your domain   :   ISP domain
                :

To recap, the following interfaces all have globally routable IP addresses:
  - NAT outside
  - CPE Router inside
  - CPE Router SDSL 1 outside
  - CPE Router SDSL 2 outside
  - ISP Router SDSL 1 inside
  - ISP Router SDSL 2 inside
  - ISP Router INET outside

The only interfaces that have private IPs are the LAN and the NAT inside.

As such the CPE Router and ISP Router load balance across the two SDSL 
links.  The world sees my office as being from the NAT outside and does 
not give a darn about any thing in between.  We even have OSPF set up to 
realize if one of the SDSL links goes down to re-route across the 
remaining link.

> These guys talking about using USB modems , some researching says 
> your ISP must support MLPPP ,

I don't think the technology of the modem really matters all that much. 
  However you will require support from your provider, be it PPP 
Multi-Link, or load balancing like I'm doing, or something similar.

> Anyone with any expierencing bonding adsl modems with a standard 
> kernel and distro?

Not speciffically.  Though, given a scenario like mine, I don't see why 
it would matter as long as you can get Equal Cost Multi-Path to work 
correctly.  My provider required that their own equipment be used on 
customer premise because they were using OSPF an interior routing 
protocol to my premise.  So my ISP extended their premise to be located 
at my office so that the IRP stays with in their control.  Heh, it works 
and I get aggregated speeds and redundancy, so I'm not going to 
complain.  Seeing as how the CPE Router above is a Cisco 3640 I can't 
say any thing for sure about Linux, but it should be able to do the job 
just fine.

> Most nix's come with RP-PPPOE, will this work?

I don't know if RP-PPPoE will do PPP Multi-Linking or not.  Though I 
don't think that it is an aspect of RP-PPPoE, but rather the underlying 
PPP implementation on your system.  It is my understanding that RP-PPPoE 
just passes traffic from "over Ethernet" to your PPP daemon.  So it is 
probably really up to your PPP daemon.  Granted you will have to have 
your providers support to be able to do this too.

Another option you could look in to if you have access to a system with 
high speed (read OC-1 or better) internet access somewhere is tunnels. 
That is create an IP in IP or GRE tunnel from your external IP to a 
co-located system and then load balance across the tunnels and NAT at 
the co-located system.  Your router and the co-located system would need 
to know how to spread the bandwidth across the tunnels in to you.

                 :                            :
             +--------+     +--------+        :
+-----+     | ADSL 1 +-----+ ADSL 1 |     +------+     +------+
| LAN +-----+ CPENAT |     | ISPRTR +-----+ COLO |-----+ INet |
+-----+     | ADSL 2 +-----+ ADSL 2 |     +------+     +------+
             +--------+     +--------+        :
                 :                            :
   Your Domain   :         Shared Domain      :   Public Domain
                 :                            :

In this scenario, you would set up a tunnel from the CPE NAT Router ADSL 
1 outside to the COLO inside and from the CPE NAT Router ADSL 2 outside 
to the COLO inside.  You would add a route to the COLO box via the ISPs 
upstream gateway to each ADSL connection and use the COLO box as your 
default gateways.  I.e. the CPD NAT Router would have a routing table 
similar to this:

0.0.0.0/0	<Tunnel 1 internal IP>
0.0.0.0/0	<Tunnel 2 internal IP>
<COLO/32>	<ADSL 1 GW>
<COLO/32>	<ADSL 2 GW>

This way computers on your LAN will use the CPE NAT Router as their 
default gateway.  The CPE NAT Router will really have two default 
gateways, the far end of the tunnels.  The Co-Located box is what will 
really be doing the NATing for the LAN.  As far as subnets are 
concerned, this is what the network will look like.

                +--------+     +--------+
+--------+     | ...1.2 +-----| ...1.1 |     +------+
| ...0.x +-----+ ...0.1 |     | Global +-----+ INet |
+--------+     + ...2.2 +-----| ...2.1 |     +------+
                |--------+     +--------+

The CPE Router (that is not NATing) will use the Co-Located box tunnels 
as its two default gateways and know about the LAN and tunnel subnets. 
The CPE Router will have routes to the globally routable IP of the 
Co-Located box via the ISPs upstream gateways but not use the ISPs 
upstream gateways as default routes.

The Co-Located box will use the tunnels as multiple routes to get to the 
LAN subnet and know about the tunnels and LAN subnet.

I know that this type of set up is extremely convoluted but will work 
and it will work with out the support of the ISP(s).  Heck, you could 
even use multiple different ISPs each with different layer 1 technology. 
  Thus you would really have redundancy in case one of the links goes 
down.  You could even expand this modle to include a second different 
co-located box to allow for even more redundancy.  (I'm going to shut up 
now.)



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

  reply	other threads:[~2007-10-11 16:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11 15:17 [LARTC] ADSL channel boding or Load balancing the sew
2007-10-11 16:18 ` Grant Taylor [this message]
2007-10-11 16:21 ` Grant Taylor
2007-10-11 18:12 ` the sew
2007-10-11 18:42 ` Grant Taylor
2007-10-25  5:49 ` the sew
2007-10-25 14:38 ` Grant Taylor
2007-10-25 18:06 ` the sew
2007-10-26  2:11 ` Grant Taylor

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=470E4CD0.7020505@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.