Aggregating 2 ISP links (DSL)

Hi,

to increase total bandwith for a LAN, I try to aggregate two
DSL links. Each of the links has one single WAN IP, and a
NAT-routing modem attached to it. Both listen to the same
LAN as gateway. I have a linux box available to dedicate it
to the routing.

So far, I achieved partial success, using the "ip route"
command with the "nexthop" option:

ip route add default scope global \
nexthop via $DSL1_IP dev eth0 weight $DSL1_DN \
nexthop via $DSL2_IP dev eth0 weight $DSL2_DN

Then I set the linux box as default gateway on all desktops.
All traffic is sent to the linux box, and then redirected by
the balancing algorithm to either of the DSL modems. There
it is NAT'ed and sent out to the WAN.

However, this setup causes trouble on incoming connections.
Lets say I configure the SSH access on the first DSL modem
(NAT port forward to the linux box). The incoming connection
starts on an unknown WAN machine, passes through the first
DSL modem and arrives at the linux box. The reply packet
is handled by the load-balancing algorithm and a route is
created in the cache, forwarding it to either of the two DSL
modems. If by chance it happens to be the same first modem,
the connection succeeds. If the other one happens to be
chosen, the packet is forwarded to it, where it is NAT'ed
with a _different_ WAN IP and sent to the WAN SSH client.
Obviously it must be rejected there, because although it is
a correct reply packet, it originates from a different source
IP and port number, and cannot be matched to the outgoing
SSH connection.

Is there a way to avoid this to happen? I can think of
creating static routes for connections on the SSH port, and
outgoing WWW ports, etc. But is this really the way to go?

Marc

On 5 May 2005 09:32:40 -0700, (E-Mail Removed) wrote:

> Hi,
>
> to increase total bandwith for a LAN, I try to aggregate two
> DSL links. Each of the links has one single WAN IP, and a
> NAT-routing modem attached to it. Both listen to the same
> LAN as gateway. I have a linux box available to dedicate it
> to the routing.
>
> So far, I achieved partial success, using the "ip route"
> command with the "nexthop" option:
>
> ip route add default scope global \
> nexthop via $DSL1_IP dev eth0 weight $DSL1_DN \
> nexthop via $DSL2_IP dev eth0 weight $DSL2_DN
>
> Then I set the linux box as default gateway on all desktops.
> All traffic is sent to the linux box, and then redirected by
> the balancing algorithm to either of the DSL modems. There
> it is NAT'ed and sent out to the WAN.
>
> However, this setup causes trouble on incoming connections.
> Lets say I configure the SSH access on the first DSL modem
> (NAT port forward to the linux box). The incoming connection
> starts on an unknown WAN machine, passes through the first
> DSL modem and arrives at the linux box. The reply packet
> is handled by the load-balancing algorithm and a route is
> created in the cache, forwarding it to either of the two DSL
> modems. If by chance it happens to be the same first modem,
> the connection succeeds. If the other one happens to be
> chosen, the packet is forwarded to it, where it is NAT'ed
> with a _different_ WAN IP and sent to the WAN SSH client.
> Obviously it must be rejected there, because although it is
> a correct reply packet, it originates from a different source
> IP and port number, and cannot be matched to the outgoing
> SSH connection.
>
> Is there a way to avoid this to happen? I can think of
> creating static routes for connections on the SSH port, and
> outgoing WWW ports, etc. But is this really the way to go?
>
> Marc

man ip :-))
ip rule add dev ppp0 table 1
ip rule add dev ppp1 table 2
ip route add from (external 1) ...
ip route add from (externlal 2) ...
ip route add default equalize nexthop ....

check the ip man pages and if you can manage it
ask and i can send you a working config
regards
brane

> ip rule add dev ppp0 table 1
> ip rule add dev ppp1 table 2
> ip route add from (external 1) ...
> ip route add from (externlal 2) ...
> ip route add default equalize nexthop ....

Unfortunately this solution cannot be applied to my problem.
(I saw a similar one already, in one of the HOWTOs)

I dont have multiple interfaces/ppp-tunnels terminating in
the linux box. There are two separate DSL modems/routers with
NAT. Both are connected to the LAN, as is the linux box.

When a packet arrives from WAN, no matter "via" which DSL, it
always enters the linux box "from" eth0. Therefore the traffic
cannot be separated by "from".


I am no network expert. I dont know if the linux box can
see which DSL modem routed an incoming packet. I guess this
is the core question. If it cannot determine the router, my
problem has no (obvious) solution.


Basically the linux box has to set up a correct route cache
entry upon arrival of an incoming connection. At the moment
it doesnt, and therefore chooses a (new) random route for the
reply. It may or may not work. And once a bad route was
chosen and stored in the route cache (!), retrying the failing
connection is bound to fail, too!

Replies must route through the correct DSL modem, because of
the NAT. Each DSL modem has its own WAN IP, and therefore
cannot be used as multipath routers. For the WAN host, a
packet routed "via" the wrong DSL gateway, appears to be
spurious and not related to the desired TCP socket (different
source IP:PORT).


Any other ideas? How can the gateway be determined that formed
part of the route, to add it to the cache?

Marc

On 9 May 2005 04:18:34 -0700, (E-Mail Removed) wrote:
>I dont have multiple interfaces/ppp-tunnels terminating in
>the linux box. There are two separate DSL modems/routers with
>NAT. Both are connected to the LAN, as is the linux box.

You cannot fix broken planning with software. Correct the hardware
setup.
--
buck

i've got multiple PPPoE connections to my ISP (Each 32kbps), but i'v
not been able to aggregate them. All the ppp connections are throug
eth0, the sample of ifconfig is,

root@6[~]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:08:A1:56:64:4A
inet addr:169.254.24.199 Bcast:169.254.255.255
Mask:255.255.0.0
inet6 addr: fe80::208:a1ff:fe67:649a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:973075 errors:0 dropped:0 overruns:0 frame:0
TX packets:40975 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88034130 (83.9 MiB) TX bytes:16033574 (15.2 MiB)
Interrupt:10 Base address:0xc00

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:327 errors:0 dropped:0 overruns:0 frame:0
TX packets:327 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:35720 (34.8 KiB) TX bytes:35720 (34.8 KiB)

ppp0 Link encap:Point-to-Point Protocol
inet addr:$INET IP" P-t-P:202.63.ABC.DE
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:24343 errors:0 dropped:0 overruns:0 frame:0
TX packets:31183 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:11156656 (10.6 MiB) TX bytes:12624624 (12.0 MiB)

ppp1 Link encap:Point-to-Point Protocol
inet addr:$INET IP" P-t-P:202.63.ABC.DE
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:3248 errors:0 dropped:0 overruns:0 frame:0
TX packets:2686 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:207668 (202.8 KiB) TX bytes:1183029 (1.1 MiB)

ppp2 Link encap:Point-to-Point Protocol
inet addr:$INET IP" P-t-P:202.63.ABC.DE
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:5181 errors:0 dropped:0 overruns:0 frame:0
TX packets:3669 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:2145012 (2.0 MiB) TX bytes:1114029 (1.0 MiB)

ppp3 Link encap:Point-to-Point Protocol
inet addr:"$INET IP" P-t-P:202.63.ABC.DE
Mask:255.255.255.255
POINTOPOINT NOARP MULTICAST MTU:1492 Metric:1
RX packets:541 errors:0 dropped:0 overruns:0 frame:0
TX packets:199 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:69280 (67.6 KiB) TX bytes:13937 (13.6 KiB)

when ever i use the ip route commands given below i get a vague erro
named "RTNETLINK answers: Invalid argument"

ip route add default scope global nexthop via 202.63.ABC.DE dev ppp
weight 1 nexthop via 202.63.ABC.DE dev ppp1 weight 1 ...... (for al
the connections)

or

ip route add default nexthop dev ppp0 via 202.63.ABC.DE weight
nexthop dev ppp1 via (........................... for all the pppN)

n many other combinations of ip route, all give the same error , o
Invalid Argument!!

all the provider's IP are teh same, and they are through the same LA
as well. an important point to note is that a friend of mine on hi
Slackware Linux machine (kernel 2.6)is able to aggregate hi
connections using the above discussed equal weight method. I am on
debian distro named Mepis, (2.6.10)..

i'd also tried using traffic control (tc) command, which although hav
executed, havent really made any difference to my connections, n th
speed of my downloads is still limited to the speed of just Singl
pppoe connection..
the tc commands used were,

tc qdisc add dev ppp0 root sfq perturb 10
tc qdisc add dev ppp1 root sfq perturb 10
tc qdisc add dev ppp2 root sfq perturb 10

i m a total newbie to linux so, please excuse any mistakes on th
terminologies.

--
neofyt
-----------------------------------------------------------------------
neofyte's Profile: http://usenetlinux.com/member.php?userid=124
View this thread: http://usenetlinux.com/showthread.php?t=40776