[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <003d01c79349$60da1870$228e4950$@biz>
Date: Thu, 10 May 2007 23:22:56 +0200
From: "Giampaolo Tomassoni" <Giampaolo@...assoni.biz>
To: <netdev@...r.kernel.org>
Subject: 2.6.20 and multipath routing
Hi there,
this is yet-another-question about multipath routing.
I would like to do load-balancing on traffic outgoing through two DSL lines.
I would prefer to increase the bandwidth of each connection instead of just
the total one, thereby I guess I'm looking for a packet-based multipath
routing solution.
Somewhere in the Net I found someone writing that I was needed to rebuild my
2.6.20 with CONFIG_IP_ROUTE_MULTIPATH_CACHED=y and some
CONFIG_IP_ROUTE_MULTIPATH_(RR|RANDOM|WRANDOM|DRR) in order to obtain this,
since with CONFIG_IP_ROUTE_MULTIPATH_CACHED=n I could only do
connection-oriented multipath routing.
Is this true? I did compile my 2.6.20 with multipath caching on and all the
multipath policies as modules, but I seem unable to obtain what I want.
My setup is the following:
- linux-2.6.20 from Gentoo (sys-kernel/gentoo-sources-2.6.20-r8)
- iproute2-2.6.20.20070313
- two ClIP lines over ADSL
- two ethernet cards
eth0 is my local lan (say, 192.168.0.100/24), eth1 is my DMZ with two
addresses (say, 1.1.1.6/29 and 1.2.1.6/29), atm0 is the ClIP interface (say,
1.1.2.1/24) to which my provider sends packet addressed to 1.1.1.0/29, while
atm1 (say, 1.2.2.1/24) is the one receiving packets for 1.2.1.0/29.
Isn't that easy? :)
Ok, let me summarize:
eth0: 192.168.0.100/24
eth1: 1.2.1.6/29 (first address) and 1.1.1.6/29
atm0: 1.1.2.1/24, point-to-point with 1.1.2.254, receives in behalf
of 1.1.1.0/29
atm1: 1.2.2.1/24, point-to-point with 1.2.2.254, receives in behalf
of 1.2.1.0/29
There are many services running in the router (smtp, http, https, pop3,
imap, ftp, domain) which have to be accessed from Internet. It is basically
much more an all-in-one box than just a router. I'm not actually
interested in traffic to and from my DMZ, nor I am that much interested in
having traffic from eth0 being dynamically MASQueraded with both the
addresses of my DMZ (a hard-coded one is fine). I would prefer to make
things
simple, so I decided that my outgoing address will always be 1.2.1.6, which
is
also the only address that "outside" knows to reach my services. The matter
here is that I have plenty of downlink bandwidth per ADSL line, while I
would
like to obtain more uplink bandwidth.
Thereby, after modprobing multipath_rr, I invoked this only, simple routing
command:
ip route add default src 1.2.1.6 mpath rr \
nexthop via 1.2.2.254 dev atm1 \
nexthop via 1.1.2.254 dev atm0
I see this way outgoing packets seem to get routed on a per-connection
basis: once a connection decided a path, that is kept until the connection
shuts down.
Now the questions:
1) Is there any way to obtain a per-packed balancing?
2) Would setting CONFIG_IP_ROUTE_MULTIPATH_CACHED=n help in this?
I didn't (yet) try this latter because I'm quite sure it wouldn't
help.
3) why do I need to pre-load multipath_rr?
4) when I do a "ip route list" I see:
1.2.1.0/29 dev eth1 proto kernel scope link src 1.2.1.6
1.1.1.0/29 dev eth1 proto kernel scope link src 1.1.1.6
192.168.0.0/24 dev eth0 proto kernel scope link src
192.168.0.100
1.2.2.0/24 dev atm1 proto kernel scope link src 1.2.2.1
1.1.2.0/24 dev atm0 proto kernel scope link src 1.1.2.1
127.0.0.0/8 dev lo scope link
default src 1.2.1.6
nexthop via 1.2.2.254 dev atm0 weight 1
nexthop via 1.1.2.254 dev atm1 weight 1
See? The mpath I choose is not mentioned in the default route. Is it
right? I see iproute2 code has code to show it, but it doesn't.
Many thanks,
-------------------------------------
Giampaolo Tomassoni - I.T. Consultant
Piazza VIII Aprile 1948, 4
I-53043 Chiusi (SI) - Italy
Tel/Ph: +39-0578-21100
MAI mandare un messaggio a:
NEVER send an e-mail to:
rainbowl@...assoni.biz
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists